# Enabling Soft-Launched Features for Specific Teams

During a soft launch campaign, new features are gated behind PostHog feature flags
and enabled on a per-team basis. This guide describes the process for enabling a
feature flag for a specific team on FlowFuse Cloud.

## Process

### 1. Change Request

A change request is created in the **CloudProject** repository. The request must include:

- The **internal team ID** of the team that needs the feature enabled
- The **feature** that needs enabling

### 2. Identify the Feature Flag Key

The developer or admin handling the request should know which PostHog feature flag
key gates the requested feature. If unsure, ask in the **Slack engineering channel**.

### 3. Update the Feature Flag in PostHog

1. Log into **PostHog** on the **production project**
2. In the left-hand menu, navigate to **Features > Feature Flags**
3. Find the relevant feature flag key in the list and open it for editing

### 4. Add a Release Condition

Under **Release conditions**, add a new condition set for the team:

1. Click to add a new condition set
2. Give the condition set a **description** — use the team or customer name for
   readability (see [Organizing Condition Sets](https://flowfuse.com/#organizing-condition-sets) below)
3. Add a filter: &#x2A;*`team-id`** — **equals*&#x2A; — &#x2A;*`<given-team-id>`**
4. Set the **rollout percentage** to &#x2A;*100%**
5. **Save** the feature flag

### 5. Verify and Close

- Verify that the feature flag change is reflected on **production/cloud** — confirm
  the team now has access to the feature
- Once verified, close the change request in the CloudProject repository

## Organizing Condition Sets

When adding release conditions, prefer **one condition set per customer**. If a
customer has multiple teams, group them under the same condition set. This approach
keeps things readable because each condition set can have a description identifying
the customer, avoiding the need to track and correlate raw team IDs.

If the feature flag already has existing condition sets, follow the pattern that was
established when the flag was first created. Use your judgement on the best approach
— the goal is to keep the list of conditions manageable and easy to audit.


# Kubernetes Hardening

This guide walks you through the best ways to secure a Kubernetes cluster running FlowFuse. Locking down your cluster shrinks your attack surface and keeps things contained if a single component gets compromised.
These tips work best when implemented together, so roll out as many of them as your environment allows.

::div{.ff-callout.ff-callout--note}
Note

  :::div{.ff-callout__content}
  These are general hardening recommendations. Adapt them to your organisation's security policies and your cluster's specific configuration.
  :::
::

## Network Policies

By default, Kubernetes allows unrestricted network traffic between all pods, across all namespaces. Any pod can reach any other pod on any port. This flat network model means that a single compromised pod, for example a vulnerable instance, can be used to reach and attack every other workload in the cluster.

Network Policies let you enforce the principle of least privilege at the network layer: a pod should only be able to talk to the workloads it genuinely needs. Restricting traffic contains lateral movement, so a breach in one component cannot trivially spread to others.

::div{.ff-callout.ff-callout--warning}
Warning

  :::div{.ff-callout__content}
  **Do not treat the policies below as a copy-and-paste solution.** They are illustrative examples, tied to the assumptions of the environment they were written for - namespace names, the ingress controller, the CNI, service ports, which components are deployed, and where operators live. Applied blindly they will either break platform traffic or leave gaps you believe are closed. Network Policies are one of the easiest things in Kubernetes to get subtly wrong: a rule that *looks* correct can silently drop traffic (wrong port direction, Service vs pod port, a missing return path) or silently allow it (an unenforced CNI, an overly broad selector). Implement them deliberately, with a working understanding of how traffic actually flows in your cluster - pod-to-pod, cross-namespace, ingress, egress, and DNS. Roll out one policy at a time, start in a non-production environment, verify each addition against real traffic (and check the affected pods' logs and Service endpoints), and confirm your CNI actually enforces policies before relying on them for security.
  :::
::

### FlowFuse and Network Policies

FlowFuse runs the platform (namespace of your choice, selected during Helm chart installation) and the hosted Node-RED instances (configured with the `forge.projectNamespace` Helm chart value) in separate namespaces. If you enforce Network Policies, you must explicitly allow the traffic FlowFuse needs - otherwise the instances cannot reach the platform. See [I use Kubernetes Network Policies, how can I configure them?](https://flowfuse.com/docs/install/kubernetes#i-use-kubernetes-network-policies-how-can-i-configure-them) for the required policy.

::div{.ff-callout.ff-callout--note}
Note

  :::div{.ff-callout__content}
  The following examples assume the default namespaces `flowfuse`, as a core application namespace, and `projects` for Hosted Instances namespace. If you have configured different namespaces, replace them accordingly.
  :::
::

The two namespaces have very different trust levels, so they are hardened differently:

- **`flowfuse`** runs trusted first-party components (core app, MQTT broker, private registry, local database). Here we restrict **inbound** traffic only — deny all ingress, then allow the connections the platform needs. Egress is left open so the platform can reach external services (licensing, npm registry, SMTP, etc.) without maintaining a brittle allow-list.
- **`projects`** runs Node-RED instances executing **user-supplied flows** - untrusted code. Here we lock down **both ingress and egress** to contain a malicious or compromised flow: it should reach only the platform services it legitimately needs, and nothing else.

### Core platform namespace (`flowfuse`)

**1. Deny all inbound traffic.** Egress is intentionally not restricted here.

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: flowfuse
spec:
  podSelector: {}
  policyTypes:
    - Ingress
```

**2. Allow inbound from the ingress controller** so users can reach the application (namespace usually `traefik`):

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-traefik
  namespace: flowfuse
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: traefik
```

**3. Allow inbound from the Hosted Instances** so Node-RED instances can reach the MQTT broker, core app and the private registry:

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-projects
  namespace: flowfuse
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: projects
```

**4. Allow traffic between the platform's own components** in this namespace - the core app connecting to the database, broker and registry, plus broker clustering. As these are all trusted first-party components, we allow intra-namespace traffic:

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-intra-namespace
  namespace: flowfuse
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: flowfuse
```

::div{.ff-callout.ff-callout--note}
Note

  :::div{.ff-callout__content}
  The Helm chart also ships a `flowforge-database-policy` that permits the core app → database connection when using the embedded database. The `allow-intra-namespace` rule above is a superset of it; keep both if you prefer defence in depth.
  :::
::

**5. Allow inbound from the EMQX operator** - The MQTT broker cluster is managed by the EMQX operator, which usually runs in its own namespace (`emqx-operator` by default) and polls the broker's management API (port `18083`) to set a pod *readiness gate*. If this is blocked, the check times out, the readiness gate never turns true, the broker pods are marked `NotReady`, their Service endpoints go empty, and every broker client fails to connect with a `503` error response. This rule is required for the operator to manage the broker cluster correctly:

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-emqx-operator
  namespace: flowfuse
spec:
  podSelector:
    matchLabels:
      apps.emqx.io/instance: emqx
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: emqx-operator
      ports:
        - protocol: TCP
          port: 18083
```

::div{.ff-callout.ff-callout--note}
Note

  :::div{.ff-callout__content}
  The same pattern applies to any other operator, admission webhook, or metrics controller that must reach pods in this namespace: allow ingress from its namespace, or its readiness/reconcile checks will silently break your Services. If a Service unexpectedly loses its endpoints after applying policies, check the managing controller's logs for connection timeouts.
  :::
::

### Hosted Instances namespace (`projects`)

This namespace runs untrusted user flows, so we deny **both** directions by default and add back only what an instance legitimately needs.

**1. Deny all inbound and outbound traffic:**

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: projects
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
```

**Instance isolation comes for free here.** With no rule permitting `projects` → `projects` traffic, Node-RED instances cannot reach another in either direction. A separate "deny pod-to-pod" policy is not needed since a compromised instance already cannot talk to its neighbours.

**2. Allow DNS resolution** (cluster DNS, usually in `kube-system`):

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: projects
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
```

**3. Allow traffic with the ingress controller**:

- **Ingress:** users reach the Node-RED editor and dashboards
- **Egress:** allow a Hosted Instance to reach the core app and private npm registry through the ingress controller

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-traefik
  namespace: projects
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: traefik
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: traefik
```

**4. Allow inbound from the platform** so the core app can manage and health-check instances:

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-flowfuse
  namespace: projects
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: flowfuse
```

**5. Allow outbound to the platform services** - the MQTT broker, core app and private npm registry. Instances **should not** connect to the database directly, so it is deliberately not allowed:

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-flowfuse
  namespace: projects
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: flowfuse
      ports:
        - protocol: TCP
          port: 1883   # MQTT broker
        - protocol: TCP
          port: 1884   # MQTT over WebSocket
        - protocol: TCP
          port: 3000   # core app pod port
        - protocol: TCP
          port: 4873   # private npm registry
```

**6. (Optional) Allow outbound to the public internet.** Thanks to the `default-deny-all` policy, instances **do not have** access to the Internet. If your flows need to call external APIs, add the rule below. It allows outbound to the internet while excluding private ranges:

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-external
  namespace: projects
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 10.0.0.0/8         # RFC1918 private range
              - 172.16.0.0/12      # RFC1918 private range
              - 192.168.0.0/16     # RFC1918 private range
              - 169.254.0.0/16     # link-local: blocks the cloud metadata endpoint (169.254.169.254) and node-local DNS
              - 100.64.0.0/10      # CGNAT range used internally by some managed clusters (GKE, EKS) 
              
      ports:
        - protocol: TCP
          port: 443
        - protocol: TCP
          port: 80
```

The `except` list is what makes this rule safe: it blocks instances from reaching internal networks even while internet access is open. Note the `169.254.0.0/16` entry in particular as it blocks the cloud metadata endpoint (`169.254.169.254`), which would otherwise let a compromised flow retrieve the node's cloud IAM credentials. `100.64.0.0/10` covers the CGNAT range that some managed Kubernetes providers use internally. Include it if your cluster does. Note that excluding `169.254.0.0/16` also blocks node-local DNS cache, which runs on a link-local address. If your cluster uses it, add an egress rule allowing UDP/TCP `53` to that address (commonly `169.254.20.10`) so DNS keeps resolving.

## TLS for Ingress

Without TLS, all traffic between users and the platform, including login credentials, session cookies, API tokens and flow data, travels in plaintext. Anyone able to observe the network path (a compromised router, a shared Wi-Fi network, a malicious intermediary) can read or tamper with it. Enabling TLS encrypts this traffic and lets clients verify they are talking to the genuine platform, protecting against eavesdropping and man-in-the-middle attacks. Serving the platform over HTTPS is a baseline requirement for any production deployment.

FlowFuse supports TLS termination either at a cloud Load Balancer or at the Kubernetes Ingress Controller (via [Cert-Manager](https://cert-manager.io/docs/){rel="&#x22;nofollow&#x22;"}). Full configuration steps are in the installation guide:

- [I would like to secure the platform with HTTPS, how can I do that?](https://flowfuse.com/docs/install/kubernetes#i-would-like-to-secure-the-platform-with-https-how-can-i-do-that)

## Database Hardening

FlowFuse stores all its data in a PostgreSQL database. The database is a critical component of the platform, and if it is compromised, an attacker can read or modify all data. The following recommendations reduce the risk of compromise and limit the impact if it does happen.

### Use a dedicated, least-privilege database user

The FlowFuse application should connect using a dedicated database user that owns only its own database — never the PostgreSQL superuser (`postgres`). If the application's credentials are leaked, a scoped user limits the blast radius to the FlowFuse database rather than the entire database server.

Create a dedicated user and database, for example:

```sql
CREATE USER flowfuse WITH PASSWORD 'a-strong-generated-password';
CREATE DATABASE flowforge OWNER flowfuse;
```

Then configure FlowFuse to connect with these credentials. See [How to use external database server?](https://flowfuse.com/docs/install/kubernetes/#how-to-use-external-database-server%3F){rel="&#x22;nofollow&#x22;"} for how to configure the connection in `customization.yml`.

Additional recommendations:

- **Use a strong, randomly generated password**
- **Require TLS for database connections** so credentials and data are encrypted in transit between the platform and the database
- **Restrict network access** to the database so only the FlowFuse platform can reach it (see [Network Policies](https://flowfuse.com/#network-policies), or your cloud provider's firewall / security group rules for managed databases)

### Backups

Regular backups protect against data loss from accidental deletion, corruption, or a failed upgrade. A hardened deployment is not complete without a tested backup strategy.

- **External / managed database:** use your database provider's backup and point-in-time-recovery features
- **Embedded database:** if you use the Helm chart's internal PostgreSQL (`forge.localPostgresql: true`), you can schedule backups with a Kubernetes CronJob running `pg_dump`. A ready-to-use `CronJob` + `PersistentVolumeClaim` example is provided in the installation guide: [How to backup embedded database?](https://flowfuse.com/docs/install/kubernetes/#how-to-backup-embedded-database%3F){rel="&#x22;nofollow&#x22;"}

::div{.ff-callout.ff-callout--warning}
Warning

  :::div{.ff-callout__content}
  **Test your restores.** A backup is only useful if it can be restored. Periodically verify that you can restore from a backup into a clean database.
  :::
::

## RBAC (Role-Based Access Control)

Kubernetes RBAC controls *who* (users, groups, service accounts) can perform *what* actions (verbs like `get`, `list`, `create`, `delete`) on *which* resources. RBAC is the primary mechanism for enforcing least privilege inside the cluster.

The core objects are:

- **Role / ClusterRole** - a set of permissions. A `Role` is namespace-scoped; a `ClusterRole` applies cluster-wide.
- **RoleBinding / ClusterRoleBinding** - grants a Role or ClusterRole to a subject (user, group or service account).

### Least-privilege principles

- **Grant the minimum.** Give each user and service account only the permissions they actually need, scoped to the narrowest namespace and resource set that works. Avoid broad wildcards (`verbs: ["*"]`, `resources: ["*"]`)
- **Never grant `cluster-admin` casually.** Reserve it for a small number of trusted administrators, day-to-day operations rarely need it
- **Prefer namespaced `Role`s over `ClusterRole`s** unless a permission genuinely must span the whole cluster
- **Audit regularly.** Review bindings periodically and remove access that is no longer needed. Command like `kubectl auth can-i --list` may help you inspect effective permissions

### Example: a read-only namespaced Role

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: flowfuse
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: flowfuse
subjects:
  - kind: User
    name: user@example.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

This grants the user `user@example.com` read-only access to pods and their logs in the `flowfuse` namespace - and nothing else.

## Other High-Level Best Practices

The following practices further reduce the attack surface of your cluster:

- **Keep Kubernetes and node images patched.** Run a supported Kubernetes version and apply security updates to the control plane, nodes, and container images promptly
- **Manage secrets properly.** Store credentials in Kubernetes Secrets (ideally with encryption at rest enabled, or an external secrets manager such as HashiCorp Vault or a cloud KMS). Never commit secrets to version control
- **Apply Pod Security Standards.** Enforce the `restricted` [Pod Security Standard](https://kubernetes.io/docs/concepts/security/pod-security-standards/){rel="&#x22;nofollow&#x22;"} where possible: run containers as non-root, drop unnecessary Linux capabilities, use a read-only root filesystem, and disallow privilege escalation
- **Set resource requests and limits.** CPU and memory limits prevent a single workload — such as a runaway flow — from starving others and provide a defence against resource-exhaustion denial-of-service
- **Enable audit logging.** Kubernetes audit logs record who did what and when, which is essential for detecting and investigating incidents
- **Limit access to the cluster API and nodes.** Restrict the API server to trusted networks, avoid exposing the Kubelet, and disable SSH access to nodes where you can
- **Scan images for vulnerabilities.** Use image scanning in your CI pipeline and admission control to block images with known critical vulnerabilities
- **Use namespaces for isolation.** Separating workloads into namespaces makes RBAC and Network Policies easier to reason about and enforce


# Administering FlowFuse

## Getting started

- [Understanding the FlowFuse Architecture](https://flowfuse.com/docs/contribute/architecture)
- [Install/Upgrade](https://flowfuse.com/docs/install) - requirements, deployment models, installation methods and upgrading
- [`flowforge.yml` configuration](https://flowfuse.com/docs/install/configuration) - base platform configuration, done before you run.
- [First Run Setup](https://flowfuse.com/docs/install/first-run) - create your admin user
- [FlowFuse Concepts](https://flowfuse.com/docs/user/concepts)
- [Usage Telemetry](https://flowfuse.com/docs/admin/telemetry)
- [Single-Sign On](https://flowfuse.com/docs/admin/sso/)
- [Licensing](https://flowfuse.com/pricing/){rel="&#x22;nofollow&#x22;"}
- [User management](https://flowfuse.com/docs/admin/user-management)
- [Platform Monitoring](https://flowfuse.com/docs/admin/monitoring)
- [Soft Launch Enablement](https://flowfuse.com/docs/admin/feature-flags)

## Administering FlowFuse

### Accessing the Admin Settings

The Admin Settings can be accessed from the main menu:

![](https://flowfuse.com/docs/admin/images/admin-menu-option.png){width="300"}

### Admin Settings

The Admin Settings view lets you manage the platform and its users. The
following settings are available:

- **Allow new users to register on the login screen** (default: `false`) :br With this option enabled, the platform login page allows visitors to register
  with the platform. :br This option is only available if email sending has been enabled.
- **Create a personal team for users when they register** (default: `false`) :br With this option enabled, the platform will automatically create a Team
  for the user. This allows them to start creating Node-RED instances straight away. :br By default, this doesn't happen, which means the user must either manually
  create the Team (if that option is enabled), or be invited to an existing
  Team. :br When enabled, a choice of what type of team should be created for the user
  is shown.
- **Allow users to reset their password on the login screen** (default: \`false) :br With this option enabled, a 'forgot your password' link is shown on the login
  screen, and provides a workflow where a user can reset their password via a
  link emailed to them. :br This option is only available if email sending has been enabled.
- **Allow users to create teams** (default: `false`) :br This option allows users to create new Teams on the platform. By default,
  it is not enabled which means all Teams must be created by an Admin.
- **Allow users to invite external users to teams** (default: `false`) :br This option allows users to invite people to join a Team who are not currently
  registered users of the platform. It sends an email with an invitation to
  sign-up to the platform and join the Team. :br By default, this is not enabled - users must be added by an Admin. :br This option is only available if email sending has been enabled.

### Managing Users

The Users page of Admin Settings can be used to manage the user on the platform.

It can be used to:

- Add new users to the platform. :br With the 0.1.0 release, the admin sets the new user's password and it is left
  to the admin to share the login details with the user outside of the platform.
- Edit a user's details. :br This includes making them an admin - giving them full access to the platform.

It also provides a list of all pending user invitations, showing who invited whom to which team.

### Managing Teams

With the 0.1.0 release, the Teams page just lists the teams on the platform.

Further team management options will come in later releases.

### Managing Team Types

The Team Types page can be used to manage the Team Types on the platform.

They determine what features of the platform are available to teams of a given type,
including what Instance Types are available and any limits that should be applied.

#### Team Type Features

- **Team Library**:br Enables Team Level sharing of flow fragments and examples. More details [here](https://flowfuse.com/docs/user/shared-library)
- **Project Nodes**:br Enables the FlowFuse Project Nodes which allows Instances within a Team to pass messages between them. More details [here](https://flowfuse.com/docs/user/projectnodes)
- **Custom NPM Catalogs**:br Allows .npmrc entries to be passed to Hosted and Remote Instances and also custom Node-RED Catalog URLs to be injected. This allows Node-RED nodes to be loaded from 3rd party registries (e.g. npm proxy instances). More details [here](https://flowfuse.com/docs/user/instance-settings#palette)
- **NPM Packages**:br Allows a Team to upload and then access their own private Node-RED nodes (or other NodeJS module packages). This can include Subflows packaged using the FlowFuse Subflow Packaging Sidebar (Requires Team Library Feature to be enabled). More details [here](https://flowfuse.com/docs/user/custom-npm-packages)
- **Certified Nodes**:br Allows the Team access to [FlowFuse Certified nodes](https://flowfuse.com/certified-nodes/){rel="&#x22;nofollow&#x22;"} (Requires security token from FlowFuse, only available to Enterprise license holders)
- **FlowFuse Exclusive Nodes**:br Allows the Team access to [FlowFuse Exclusive nodes](https://flowfuse.com/node-red/flowfuse/){rel="&#x22;nofollow&#x22;"} (Requires security token from FlowFuse, only available to Enterprise license holders)
- **Email Alerts**:br Allows Teams to enable email alerts when an Hosted Instance crashes or is approaching the CPU/Memory limits set for it's Stack (requires email to be enabled). More details [here](https://flowfuse.com/docs/user/instance-settings#alerts)
- **Protected Instances**:br Allows Hosted Instances to be marked as Protected. This disables Editor access and requires all flows to be updated via a Pipeline. More details [here](https://flowfuse.com/docs/user/devops-pipelines#protected-instances)
- **Git Integration**:br This allows a GitHub project to be used as the source or output of a Pipeline. More details [here](https://flowfuse.com/docs/user/devops-pipelines#git-repository-stage)
- **API/Debug Length Limits**:br Lets a Team change the size of the max payload a Hosted Instance can accept and also the size messages sent to the Debug Sidebar will be truncated to. More details [here](https://flowfuse.com/docs/user/instance-settings#editor)
- **Static Assets**:br Allows Hosted Instances to share static files stored in the Instance Persistent Storage space via HTTP. More details [here](https://flowfuse.com/docs/user/static-asset-service)
- **Instance Resources**:br Enables CPU and Memory historical charts for Hosted and Remote Instances.
- **Application Level RBAC**:br Allows Team level Roles to be applied at an Application level inside the Team.
- **Team-based Endpoint Security**:br Allows HTTP endpoints provided by a Hosted or Remote Instance to require a FlowFuse account and membership to the allow access. Also applies to Node-RED Dashboards hosted on the instances. More details [here](https://flowfuse.com/docs/user/http-access-tokens)
- **Device Groups**:br Allows Remote Instances to be placed in groups which can be used as the source or target of a Pipeline stage. More details [here](https://flowfuse.com/docs/user/device-groups)
- **Device Auto Snapshot**:br Creates a snapshot on every deploy when the Remote Instance is in Developer Mode. These snapshots keep a rolling set of last 10 deploys. More details [here](https://flowfuse.com/docs/user/snapshots)
- **Instance Auto Snapshot**:br Creates a snapshot on every deploy from a Hosted Instance. These snapshots keep a rolling set of the last 10 deploys. More details [here](https://flowfuse.com/docs/user/snapshots)
- **Custom Hostnames**:br Allows Hosted instances to be accessed on a second hostname with an arbitrary domain (Kubernetes only, requires specific configuration). More details [here](https://flowfuse.com/docs/user/custom-hostnames)
- **High Availability**:br Allows for 2 copies of Node-RED to be running for a single Hosted Node-RED instance to provide Load Balanced higher throughput and fail over protection (Kubernetes only). More details [here](https://flowfuse.com/docs/user/high-availability)
- **Bill of Materials / Dependencies**:br Provides a Team level view of what Node-RED nodes are installed and what versions are being used and which have newer versions available. More details [here](https://flowfuse.com/docs/user/bill-of-materials)
- **Version History Timeline**:br Enables a graphical representation of Snapshot creation to allow a clearer picture of when they are created. More details [here](https://flowfuse.com/docs/user/snapshots#timeline-view)
- **Team Broker**:br Provides a Team scoped MQTT broker and Asynchronous API documentation generation. More details [here](https://flowfuse.com/docs/user/teambroker)
- **Tables**:br Provides a Team scoped shared SQL Relational Database (Requires specific configuration). More details [here](https://flowfuse.com/docs/user/ff-tables)
- **AI Features**:br Global toggle for all AI functionality within the team. When disabled, all AI features below are unavailable regardless of their individual settings. Requires `ai.enabled: true` in the platform configuration.
- **Expert Assistant**:br Enables the FlowFuse Expert chat assistant for the team. Provides AI-powered support for building and debugging Node-RED flows. Enabled by default (opt-out). Requires the AI Features flag to be enabled. More details [here](https://flowfuse.com/docs/user/expert/)
- **Expert Insights**:br Enables the Insights mode of FlowFuse Expert, allowing users to query live operational data from Node-RED instances via MCP. Enabled by default (opt-out). Requires the AI Features flag to be enabled. More details [here](https://flowfuse.com/docs/user/expert/chat/)
- **Assistant Inline Code Completion**:br Allows LLM assistance when writing Function nodes. Requires the AI Features flag to be enabled and assistant service configuration. More details [here](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/)
- **Generated Snapshot Descriptions**:br Enables AI-generated descriptions of Snapshots. Requires the AI Features flag to be enabled and assistant service configuration. More details [here](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/)

### Managing Instance Types

The Instance Types page can be used to manage the Instance Types on the platform.

When billing is enabled, an instance type can be associated with a particular
Stripe Product/Price - allowing each type to have a different monthly price
associated with it.

The Instance Types page shows what types are currently active, how many stacks
each type has been assigned to it, and how many instances have been created of that
type.

Whenever a new Instance Type is created, it will need to be manually enabled for
the individual [Team Types](https://flowfuse.com/#managing-team-types) before they will be available
for teams to use.

Instance Types also control the default Stack (and in turn, the default Node-RED versions) that Instances will run with if there are multiple available Stacks associated with an Instance Type.

### Managing Stacks

> Admin Settings > Stacks

The Stacks page can be used to manage the Stacks on the platform. It can be used
to create and edit the stacks on the platform.

For Deployment specific information about working with stacks, refer to the
documentation of your chosen deployment model:

- [Local Stacks](https://flowfuse.com/docs/contribute/local/stacks)
- [Docker Stacks](https://flowfuse.com/docs/install/docker/stacks)
- [Kubernetes Stacks](https://flowfuse.com/docs/install/kubernetes/stacks)

#### Create Stack

##### Upgrading Stacks

You can create a new version of an existing stack via the
drop-down menu in the stack table. This allows the platform to notify users
that an update is available for their instance, allowing them to upgrade the stack
at their convenience.

![Screenshot of FlowFuse showing where admins can create new stacks](https://flowfuse.com/docs/admin/images/admin-stacks-create-new-version.png){dataZoomable=""}*Screenshot of FlowFuse showing where admins can create new stacks*

Node-RED instances that use the old stack will offer the new stack as a one-click upgrade option.

##### Create New Stack

Alternatively, click 'Create stack' to create an entirely new stack.

![Screenshot of FlowFuse showing the "Create Stack" dialog](https://flowfuse.com/docs/admin/images/admin-stack-create.png){dataZoomable=""}*Screenshot of FlowFuse showing the "Create Stack" dialog*

When prompted for the Node-RED version, the value here depends on the setup you're running:

- **Local**: Provide the exact stack name (Node-RED version) that was installed. For example,
  if you ran the script with `latest` and it resulted in `3.1.9` being installed, you should enter `3.1.9`.
  This must match the directory name created in your `stacks` directory. If you changed the
  directory name for any reason, make sure to use that name.
- **Docker**: Support the container image name ([docs](https://flowfuse.com/docs/install/docker/stacks))
- **k8s**: Support the container image name ([docs](https://flowfuse.com/docs/install/kubernetes/stacks))

#### Updating Stacks

It is *not* possible to edit a stack that is being used by Instances.

### Managing Templates

With [templates](https://flowfuse.com/docs/user/concepts/#template) administrators
can apply Node-RED configuration options as default.
For these options, the administrator can lock the selected value so users cannot change
them, or keep them editable by end-users.

If you edit a template that is being used by an Application Instance, those changes will get
applied the next time the instance is restarted.

#### Disallow using nodes

On FlowFuse Cloud, but recommended on self-managed installs on Docker and Kubernetes,
where certain nodes will not work so are excluded from being used by the template.

When adding `31-tcpin.js,32-udp.js,10-file.js,23-watch.js,90-exec.js` to the `Exclude node by filename` section of a template and locking this value users are prevented from using these.


# Platform Monitoring

FlowFuse provides an API end-point that can be used to monitor statistical
information about the platform.

The end-point is accessible to any logged-in Admin user at the url (replace `example.com`
with the domain of your FlowFuse instance)

- `https://example.com/api/v1/admin/stats`

By default, it returns a JSON object containing key statistics such as the number
of users, instances, and other information.

If the `accept` header of the http request includes `application/openmetrics-text`
then the response is formatted as OpenMetrics text. This can be directly consumed
by tools such as Prometheus.

## Enabling token-based access

In Admin Settings there is an option to allow token-based access to platform statistics.

When enabled, the platform will generate an access token that can be used to access
the end-point without having a full Admin login. This is useful when configuring
tools such as Prometheus to monitor the platform.

1. Under Admin Settings -> General, check the 'allow token-based access' option
2. A dialog is shown containing the token. This is the *only* time the token
   will be shown - make sure you record its value.

The token should be provided as a bearer token in any http request to the end-point;

```bash
TOKEN=your_generated_token
curl -H 'Authorization: Bearer $TOKEN' https://example.com/api/v1/admin/stats
```

## Configure Prometheus to scrape the Platform statistics endpoint

To configure Prometheus to scrape the FlowFuse Platform statistics endpoint, you need to add a new scrape job to your Prometheus configuration file (usually `prometheus.yml`).
Since the statistics endpoint is secured, you will need to provide the access token in the scrape configuration (see the previous paragraph on enabling token-based access).

Once you have the token, you can add a new scrape job to your Prometheus configuration (replace `<generated_token>` and `<flowfuse_platform_url>` with yor FlowFuse Platform-sepcific values):

```yaml
scrape_configs:
   - job_name: flowfuse_platform_stats
     metrics_path: /api/v1/admin/stats
     scheme: https
     authorization:
        type: Bearer
        credentials: "<generated_token>"
     scrape_protocols: ["OpenMetricsText1.0.0"]
     static_configs:
     - targets: ["<flowfuse_platform_url>"]
```


# Observability

Observability is the ability to understand the internal state and behaviour of a system by analysing its outputs, without needing to know its internal workings. For a self-hosted FlowFuse platform running on Kubernetes, this means having a holistic view of the platform and the cluster it runs on - their health, performance, and any potential issues - so you can detect and diagnose problems before they affect your users.

This page describes the kinds of tools you can use and what each is for, so you can plan an observability stack that fits your environment. It does not prescribe a specific deployment; the tools named below are common open-source choices, but the concepts apply equally to managed or commercial alternatives.

## The three pillars

Observability is usually described in terms of three complementary signals:

- **Metrics** - numeric measurements sampled over time (request rates, memory usage, pod counts). Good for dashboards, trends, and alerting thresholds.
- **Logs** - timestamped records of discrete events emitted by the platform and by the workloads running on the cluster. Good for understanding *why* something happened.
- **Dashboards & visualization** - a unified place to explore metrics and logs together, spot correlations, and share views across a team.

A complete setup collects all three and ties them together, so an alert on a metric can be investigated against the corresponding logs.

## Tools

### Prometheus

[Prometheus](https://prometheus.io/){rel="&#x22;nofollow&#x22;"} collects and stores time-series metrics by scraping HTTP endpoints at regular intervals. For a self-hosted FlowFuse platform there are two useful sources of metrics:

- **Kubernetes cluster metrics** - cluster-level metrics such as CPU and memory usage, pod status, and node health, typically gathered via [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics){rel="&#x22;nofollow&#x22;"} and [node-exporter](https://github.com/prometheus/node_exporter){rel="&#x22;nofollow&#x22;"}.
- **Hosted Instances metrics** - every Hosted Instance is a pod running on the Kubernetes cluster. It produces metrics that are exposed by cAdvisor at the `/metrics` endpoint, which Prometheus can scrape. This includes CPU, memory and networking usage.
- **Platform metrics** - FlowFuse core deployment exposes a `/metrics` endpoint that Prometheus can scrape. This includes resources performance statistics, request rates, and error counts, etc.

### Loki

[Loki](https://grafana.com/oss/loki/){rel="&#x22;nofollow&#x22;"} is a log aggregation system designed to pair with Prometheus. It collects, stores, and lets you query logs from the platform and from the pods running on your cluster, so you can analyse logs alongside metrics using the same labels.

### Grafana

[Grafana](https://grafana.com/oss/grafana/){rel="&#x22;nofollow&#x22;"} is an open-source platform for building and sharing dashboards. It provides a single interface over your observability data:

- **Data source integration** - connect Prometheus, Loki, and other sources to visualize metrics and logs in one place.
- **Customizable dashboards** - build tailored views for platform health, resource usage, and workload behaviour.
- **Alerting** - define alerting rules against your metrics and logs to be notified of problems proactively.

## Quick start

The fastest way to get started is the **LGTM stack** - Loki (logs), Grafana (dashboards), Tempo (traces), and Mimir/Prometheus (metrics) - is to either use Grafana Cloud or deploy it self-hosted:

- **Grafana Cloud (hosted)** - sign up for [Grafana Cloud](https://grafana.com/products/cloud/){rel="&#x22;nofollow&#x22;"} and install the [Kubernetes Monitoring](https://grafana.com/docs/grafana-cloud/monitor-infrastructure/kubernetes-monitoring/){rel="&#x22;nofollow&#x22;"} integration. It deploys collectors (Grafana Alloy) into your cluster that ship metrics and logs to Grafana's managed backend. Point one scrape target at the FlowFuse Platform metrics endpoint and you have platform plus cluster visibility with minimal setup.
- **Self-hosted LGTM** - run the stack inside your own cluster using the [`kube-prometheus-stack`](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack){rel="&#x22;nofollow&#x22;"} (Prometheus + Grafana + Alertmanager) and [`loki`](https://github.com/grafana/loki/tree/main/production/helm/loki){rel="&#x22;nofollow&#x22;"} Helm charts. You keep full control of your data and retention, at the cost of maintaining the stack yourself.

Start with Grafana Cloud if you want results quickly and are comfortable sending telemetry off-cluster; choose self-hosted LGTM if data residency or cost at scale matters. The concepts in the rest of this page apply to either.

### Initial Grafana dashboards

Rather than building Grafana dashboards from scratch, import a few proven community dashboards to get cluster visibility on day one. In Grafana, use **Dashboards → New → Import** and enter the dashboard ID:

- **[Node Exporter Full](https://grafana.com/grafana/dashboards/1860){rel="&#x22;nofollow&#x22;"}** (ID `1860`) - per-node CPU, memory, disk, and network from node-exporter.
- **[Kubernetes / Views / Global](https://grafana.com/grafana/dashboards/15757){rel="&#x22;nofollow&#x22;"}** (ID `15757`) - cluster-wide health and resource usage across nodes, namespaces, and workloads.
- **[Kubernetes / Views / Pods](https://grafana.com/grafana/dashboards/15760){rel="&#x22;nofollow&#x22;"}** (ID `15760`) - per-pod CPU, memory, and network, useful for inspecting individual Hosted Instances.

> If you deployed the `kube-prometheus-stack` Helm chart, a full set of `Kubernetes / Compute Resources / *` dashboards is installed automatically - check the dashboard list before importing duplicates.

Once the cluster basics are in place, build a FlowFuse-specific dashboard from the platform metrics described under [Prometheus](https://flowfuse.com/#prometheus) above.

## Next steps

- [Platform Monitoring](https://flowfuse.com/docs/admin/monitoring) - details of the FlowFuse statistics endpoint used by Prometheus.
- [Installing FlowFuse on Kubernetes](https://flowfuse.com/docs/install/kubernetes/) - deploying and configuring the platform on a cluster.


# Configuring Single Sign-On

*This feature is only available on self-hosted Enterprise licensed instances of FlowFuse.*

FlowFuse allows users to sign in through their SAML identity provider, such
as Google Workspace, or using LDAP against a directory service provider.

The platform can be configured with multiple SSO configurations and uses the
user's email domain to identify which provider should be used.

Since FlowFuse 2.7, the SSO configuration can be configured to automatically
registers when they first sign in.

Otherwise, a user will have to first register on the platform, providing a temporary
password in order to create an account. They will then be able to log in via their SSO provider.

By default, admin users can still log in with their original FlowFuse username and password, which ensures they are not locked out if there is a problem with the SSO configuration.

## SAML SSO

SAML based SSO allows the FlowFuse platform to authenticate users against their
identity provider such as Google Workspace.

Once enabled for a particular email domain, regular users on that domain will be
directed to the Identity Provider in order to log in. They will no longer be able
to log in with their local password, nor will they be able to change their email
address in User Settings.

- [Configuring SAML SSO](https://flowfuse.com/docs/admin/sso/saml)

## LDAP SSO

LDAP based SSO allows the FlowFuse platform to authenticate users against a directory
service provider, such as OpenLDAP.

When logging in, the users credentials are passed to the service provider to verify.

- [Configuring LDAP SSO](https://flowfuse.com/docs/admin/sso/ldap)


# Configuring LDAP based Single Sign-On

*This feature is only available on self-hosted Enterprise licensed instances of FlowFuse.*

The SSO Configurations are managed by the platform Administrator under the
`Admin Settings > Settings > SSO` section.

The user must already exist on the FlowFuse platform before they can sign in via SSO.

### Create a SSO Configuration

1. Click 'Create SSO Configuration' to create a new config :br![](https://flowfuse.com/docs/admin/sso/images/create-sso-config-ldap.png)
2. Give the configuration a name to help identify it, and provide the email domain
   name this configuration should apply to. Ensure the LDAP option is selected - this
   cannot be changed after the configuration is created.
3. Click 'Create configuration' :br At this point, the configuration has been created and metadata generated for the
   configuration, but it is not active.

### Configuration LDAP

The following fields are provided for configuring LDAP. You will need to refer to
your LDAP service provider details for the correct values to enter:

![](https://flowfuse.com/docs/admin/sso/images/edit-sso-config-ldap.png)

- `Server` - the address of the LDAP server, including port number.
- `Username` - the bind DN to use to connect to the server. The user must have
  permission to lookup users in the directory.
- `Password` - the password to connect to the server with.
- `Base DN` - the base object under which user searches are performed.
- `User Search Filter` - the filter used to search for a user. See below for more details.
- `Enable TLS`- whether to use TLS for the LDAP connection
  - `Verify Server Certificate` - when TLS is enabled, whether to perform strict certification
    validation.

You can save the configuration at any time by clicking the `Update configuration`
button. The configuration will only be enabled when you tick the `active` checkbox
and save the changes.

### Session Length Overrides

Each SSO configuration can override the platform default Max Session life an Max Session Idle time.

These are Controlled by the "Custom Session Expiry (hours)" and "Custom Session Idle Time (hours)" respectively.

![Settings for Custom Session lifetime](https://flowfuse.com/docs/admin/sso/images/edit-sso-custom-session.png)*Settings for Custom Session lifetime*

#### User Search Filter

The search filter is used when checking if a user exists within the directory, using
the standard LDAP query notation. The default search filter is `(uid=${username})`.

The platform will replace `${username}` and `${email}` with the user's details when
they attempt to login.

## Creating new users

With FlowFuse 2.7, the SSO Configuration now includes an option to automatically
register users who sign in via the configuration.

This option is not enabled by default, but can be enabled but selecting the `Allow Provisioning of New Users on first login`
option in the SOO configuration.

When creating the user, the platform will use information provided by the LDAP provider
to create the username. The user will be directed to their settings page where they
can modify their user details to their preferred values.

## Managing Team Membership with LDAP Groups

LDAP implementations can also be used to group users

To enable this option, select the `Manage roles using group assertions` in the SSO configuration.

The following configuration options should then be set:

- `Group DN` - this is the base DN to be used to search for group membership.
- `Team Scope`- this determines what teams can be managed using this configuration. There are two options:
  - `Apply to all teams` - this will allow the SAML groups to manage all teams on the platform. This is
    suitable for a self-hosted installation of FlowFuse with a single SSO configuration for all users on
    the platform.
  - `Apply to selected teams` - this will restrict what teams can be managed to the provided list. This
    is suitable for shared-tenancy platforms with multiple SSO configurations for different groups of users,
    such as FlowFuse Cloud.
    When this option is selected, an additional option is available - `Allow users to be in other teams`. This
    will allow users who sign-in via this SSO configuration to be members of teams not in the list above.
    Their membership of those teams will not be managed by the SSO groups.
    If that option is disabled, then the user will be removed from any teams not in the list above.

### LDAP Groups configuration

A user's team membership is managed by what groups they are in. When the user logs in, the LDAP provider
will be queried for a list of groups they are a member of. This can be either as a `member` or `uniqueMember` of a `groupOfNames` or `groupOfUniqueNames` respectively.

The group name is used to identify a team, using its slug property, and the user's role in the team.
The name must take the form `ff-<team>-<role>`. For example, the group `ff-development-owner` will
container the owners of the team `development`.

The valid roles for a user in a team are:

- `owner`
- `member`
- `viewer`
- `dashboard`

*Note*: this uses the team slug property to identify the team. This has been chosen to simplify managing
the groups in the LDAP Provider - rather than using the team's id. However, a team's slug can be changed
by a team owner. Doing so will break the link between the group and the team membership - so should only
be done with care.

An optional prefix and suffix can be include in the group name to support LDAP providers that have existing naming policies. The SSO configuration can be configured with the lengths of these values so they will be stripped off before the group name is validated.

For example, if an organisation requires all groups to begin with `acme-org-`, a prefix length of `9` can be set and the group `acme-org-ff-development-owner` will be handled as `ff-development-owner`.

### Application Level Groups

In addition to being able to add Users to Teams using groups, Role overrides for specific Applications within those groups can also be controlled.

The User must have a membership of the Team the Application belongs to for an Application override to take effect. If the User is not a member of that Team, the override is ignored.

Groups for Application overrides use a similar pattern to Team Groups and use the same prefix and suffix length modifiers. They take the form `ff-<team>[<application>]-<role>`, where `<application>` can be the Application name or id and `<role>` must be one of the valid roles listed above, but can also be `none` to remove access from an Application within the Team. Any unrecognised role is ignored.

For example, given a Team called `development` and an Application called `test`, owner-level access to the Team would be granted by membership of a group named `ff-development-owner`, and an override to `viewer` for the Application `test` would be granted by `ff-development[test]-viewer`.

If multiple groups grant different roles for the same Application, the highest role is applied.

Application overrides applied this way are managed by the SSO provider: they cannot be edited in the FlowFuse UI, and if the corresponding group is removed the override is cleared the next time the User logs in.

## Managing Admin users

The SSO Configuration can be configured to manage the admin users of the platform by enabling the
`Manage Admin roles using group assertions` option. Once enabled, the name of a group can be provided
that will be used to identify whether a user is an admin or not.

\*&#x2A;Note:* the platform will refuse to remove the admin flag from a user if they are the only admin
on the platform. It is *strongly* recommended to have an admin user on the system that is not
managed via SSO to ensure continued access in case of any issues with the SSO provider.

## Providers

The following is the node-exhaustive list of the providers that are known to work with FlowFuse LDAP SSO.

- [OpenLDAP](https://www.openldap.org/){rel="&#x22;nofollow&#x22;"}


# Configuring SAML based Single Sign-On

*This feature is only available on FlowFuse Cloud and self-hosted Enterprise licensed instances of FlowFuse.*

The SSO Configurations are managed by the platform Administrator under the
`Admin Settings > Settings > SSO` section.

To fully configure SAML SSO, you will need to generate a configuration in FlowFuse,
provide some of the generated values to your Identity Provider, and copy back some
values they provide.

## Configuring SSO on FlowFuse Cloud

Configuring SSO on FlowFuse Cloud requires co-ordinating tasks between the customer and
FlowFuse Cloud administrators.

**All changes must be made via a [Production Change Request](https://github.com/FlowFuse/CloudProject/issues/new?assignees=&labels=change-request&projects=&template=change-request.yml&title=Change%3A+){rel="&#x22;nofollow&#x22;"} in the CloudProject repository - even if you are actioning it directly.**

When a customer requests SSO to be setup for their users, we require the following information:

1. Confirm the customer's entitlement for SSO enablement. It is only available to *Enterprise* tier customers.
2. The email domain that will be covered by the configuration. Note that each SSO configuration can only be applied to a single domain. If a customer has multiple domains, each one will require its own SSO configuration. [Issue #5011](https://github.com/FlowFuse/flowfuse/issues/5011){rel="&#x22;nofollow&#x22;"} has been raised to make this more flexible in the future.
3. Whether it is SAML or LDAP based SSO
4. What Identify Provider they are using for their SSO.

Once this information has been provided, create a Change Request issue in the CloudProject repository recording this information.

We can then create a draft SSO configuration in the Admin/Settings/SSO section. The configuration should not be marked as active yet.

From the draft configuration, the values of `ACS URL` and `Entity ID / Issuer` can be given to the customer. These values will be required by their Identify Provider. Refer to the provider-specific documentation for how those values get applied.

In return, the customer then needs to provide:

1. `Identity Provider Single Sign-On URL`
2. `Identity Provider Issuer ID / URL`
3. `X.509 Certificate Public Key`

Again, refer to the provider-specific documentation for where to find these values as each provider has its own terminology.

These values should be applied to the draft SSO configuration in FlowFuse Cloud. The configuration can then be marked as active.

It is recommended to do this final step whilst on a call with the customer so they can test the setup in real time.

### Common Issues

Aside from navigating the mismatched terminology between services providers, the most common issue we hit is where a login attempt fails and 'Invalid Document Signature' is shown in FlowFuse logs. This is because we expect both the SAML Assertions and Responses to be signed by the public certificate. The default configuration for many providers is to only sign the assertions - check the provider-specific documentation for the appropriate option to enable to address this.

## Configuring SSO

The following instructions give more details information on how to setup SSO.

### Create a SSO Configuration

1. Click 'Create SSO Configuration' to create a new config :br![](https://flowfuse.com/docs/admin/sso/images/create-sso-config.png)
2. Give the configuration a name to help identify it, and provide the email domain
   name this configuration should apply to. Ensure the SAML option is selected - this
   cannot be changed after the configuration is created.
3. Click 'Create configuration' :br At this point, the configuration has been created and metadata generated for the
   configuration, but it is not active. :br![](https://flowfuse.com/docs/admin/sso/images/edit-sso-config.png)
4. Copy the `ACS URL` and `Entity ID / Issuer` values as you will need to configure
   your Identity Provider with these values.

You can save the configuration at any time by clicking the `Update configuration`
button. The configuration will only be enabled when you tick the `active` checkbox
and save the changes.

### Configure your Identify Provider

Every Identity Provider uses slightly different terminology and varies what
information they require and what they provide. This can make it a tricky task
to complete.

We provide specific guides for the providers we have verified below.

If you have a working configuration for a provider not listed here, please do
share the details so we can add them to the list.

The general points are:

1. Your Identity Provider will supply you with some of the following values that
   should be entered into your FlowFuse SAML SSO Configuration:
   - `Single Sign-On URL` - also referred to as 'SAML Endpoint', 'Login URL' or 'IdP SSO URL'.
   - `Issuer ID / URL`
   - `X.509 Certification Public Key` - the public key of a certificate used to sign
     SAML requests.
2. Configure the `NameID` SAML option to be `EmailAddress` and have it return the email
   of the user logging in. This is how FlowFuse will verify they are a known user
   on the platform.

### Session Length Overrides

Each SSO configuration can override the platform default Max Session life an Max Session Idle time.

These are Controlled by the "Custom Session Expiry (hours)" and "Custom Session Idle Time (hours)" respectively.

![Settings for Custom Session lifetime](https://flowfuse.com/docs/admin/sso/images/edit-sso-custom-session.png)*Settings for Custom Session lifetime*

### Enable your SAML SSO Configuration

Once you have setup both sides of the configuration you can enable it for use
by ticking the `active` checkbox and clicking `Update configuration`.

## Creating new users

With FlowFuse 2.7, the SSO Configuration now includes an option to automatically
register users who sign in via the configuration.

This option is not enabled by default, but can be enabled but selecting the `Allow Provisioning of New Users on first login`
option in the SOO configuration.

When creating the user, the platform will use information provided by the SAML provider
to create the username. The user will be directed to their settings page where they
can modify their user details to their preferred values.

\## Managing Team Membership with SAML Groups

Some SAML providers allow user group information to be shared as part of the sign-in process.
When properly configured, this can be used to manage what FlowFuse teams a user has access to.

To enable this option, select the `Manage roles using group assertions` in the SSO configuration.

The following configuration options should then be set:

- `Group Assertion Name` - this is used to identify the group membership information in the response
  sent by the Identity Provider. It defaults to `ff-roles` but can be customised if the Identify Provider
  requires it.
- `Team Scope`- this determines what teams can be managed using this configuration. There are two options:
  - `Apply to all teams` - this will allow the SAML groups to manage all teams on the platform. This is
    suitable for a self-hosted installation of FlowFuse with a single SSO configuration for all users on
    the platform.
  - `Apply to selected teams` - this will restrict what teams can be managed to the provided list. This
    is suitable for shared-tenancy platforms with multiple SSO configurations for different groups of users,
    such as FlowFuse Cloud.
    When this option is selected, an additional option is available - `Allow users to be in other teams`. This
    will allow users who sign-in via this SSO configuration to be members of teams not in the list above.
    Their membership of those teams will not be managed by the SSO groups.
    If that option is disabled, then the user will be removed from any teams not in the list above.

### SAML Groups configuration

A user's team membership is managed by what groups they are in. When the user logs in, the SAML provider
must be configured to provide a list of groups they are a member of as a SAML assertion.

The group name is used to identify a team, using its slug property, and the user's role in the team.
The name must take the form `ff-<team>-<role>`. For example, the group `ff-development-owner` will
container the owners of the team `development`.

The valid roles for a user in a team are:

- `owner`
- `member`
- `viewer`
- `dashboard`

*Note*: this uses the team slug property to identify the team. This has been chosen to simplify managing
the groups in the SAML Provider - rather than using the team's id. However, a team's slug can be changed
by a team owner. Doing so will break the link between the group and the team membership - so should only
be done with care.

An optional prefix and suffix can be include in the group name to support SAML providers that have existing naming policies. The SSO configuration can be configured with the lengths of these values so they will be stripped off before the group name is validated.

For example, if an organisation requires all groups to begin with `acme-org-`, a prefix length of `9` can be set and the group `acme-org-ff-development-owner` will be handled as `ff-development-owner`.

### Application Level Groups

In addition to being able to add Users to Teams using groups, Role overrides for specific Applications within those groups can also be controlled.

The User must have a membership of the Team the Application belongs to for an Application override to take effect. If the User is not a member of that Team, the override is ignored.

Groups for Application overrides use a similar pattern to Team Groups and use the same prefix and suffix length modifiers. They take the form `ff-<team>[<application>]-<role>`, where `<application>` can be the Application name or id and `<role>` must be one of the valid roles listed above, but can also be `none` to remove access from an Application within the Team. Any unrecognised role is ignored.

For example, given a Team called `development` and an Application called `test`, owner-level access to the Team would be granted by membership of a group named `ff-development-owner`, and an override to `viewer` for the Application `test` would be granted by `ff-development[test]-viewer`.

If multiple groups grant different roles for the same Application, the highest role is applied.

Application overrides applied this way are managed by the SSO provider: they cannot be edited in the FlowFuse UI, and if the corresponding group is removed the override is cleared the next time the User logs in.

## Managing Admin users

The SSO Configuration can be configured to manage the admin users of the platform by enabling the
`Manage Admin roles using group assertions` option. Once enabled, the name of a group can be provided
that will be used to identify whether a user is an admin or not.

\*&#x2A;Note:* the platform will refuse to remove the admin flag from a user if they are the only admin
on the platform. It is *strongly* recommended to have an admin user on the system that is not
managed via SSO to ensure continued access in case of any issues with the SSO provider.

## Direct SSO Login

For Self Hosted users there is an option in the Admin Settings to enable buttons on the login page for each active SAML SSO provider.

These buttons will redirect to the SSO provider rather than requiring users to enter and email address in the username field to select the correct provider.

## Forcing All Users to Use SSO

For self-hosted installations that need to ensure no user can bypass SSO, there is an option in **Admin Settings > Settings > SSO > Force all logins for non-admin users via a single SAML SSO provider**.

![SSO settings page showing the option to force all non-admin users to log in via a single SAML SSO provider](https://flowfuse.com/docs/admin/sso/images/force-sso.png)*SSO settings page showing the option to force all non-admin users to log in via a single SAML SSO provider*

When this option is enabled:

- All users are redirected to the configured SSO provider at login, regardless of their email domain
- The email and password login form is no longer presented as a fallback option
- Admin users can bypass SSO by accessing `/admin` routes

This is intended for organisations running a single identity provider across the entire platform, where per-domain SSO configuration is not sufficient to cover all users.

## Providers

The following is a non-exhaustive list of the providers that are known to work
with FlowFuse SAML SSO.

- [Microsoft Entra](https://flowfuse.com/#microsoft-entra)
- [Google Workspace](https://flowfuse.com/#google-workspace)
- [OneLogin](https://flowfuse.com/#onelogin)
- [Okta](https://flowfuse.com/#okta)
- [Keycloak](https://flowfuse.com/#keycloak)

### Microsoft Entra

Microsoft provide a guide for creating a custom SAML Application [here](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal){rel="&#x22;nofollow&#x22;"}.

The following tables map the Entra terminology to the FlowFuse settings.

| FlowFuse Setting                       | Entra Setting                                |
| -------------------------------------- | -------------------------------------------- |
| `ACS URL`                              | `Reply URL (Assertion Consumer Service URL)` |
| `Identity Provider Issuer ID / URL`    | `Microsoft Entra Identifier`                 |
| `Identity Provider Single Sign-On URL` | `Login URL`                                  |
| `X.509 Certificate Public Key`         | `Certificate (Base64)`                       |

Follow these steps to properly configure SAML SSO for Microsoft Entra:

1. In FlowFuse:
   1. Create a draft SSO configuration in FlowFuse with the appropriate email domain
2. In Entra:
   1. Create a SAML application - use the guide linked above for more information
   2. Copy the following values from the FlowFuse SSO configuration into the corresponding Entra configuration:
      1. Set `Reply URL` to the value of `ACS URL`
      2. Set `Identifier (Entity ID)` to the value of `Entity ID/Issuer`
   3. Within the `SAML Signing Certificate` configuration, the `Signing Option` must be set to `Sign SAML response and assertion`.
   4. The `Unique User Identifier (Name ID)` claim must be configured to return the value of the `user.mail` source attribute.
   5. Download the `Federation Metadata XML` file from the `SAML Certificates` section of the Entra application.
3. In FlowFuse:
   1. From the metadata XML file, copy the follow properties into the FlowFuse SSO configuration:
      1. Set `Identity Provider Single Sign-On URL` to the value of the `Location` attribute of the `<SingleSignOnService>` tag. This should look like `https://login.microsoftonline.com/<app-id>/saml2`.
      2. Set `Identity Provider Issuer ID / URL` to the value of the `entityID` attribute of the `<EntityDescriptor>` tag. This should look like `https://sts.windows.net/<app-id>/`
      3. Set `X.509 Certificate Public Key` to the value of the `<ds:X509Certificate>` tag. This does *not* need to have the `-----BEGIN CERTIFICATE-----/-----END CERTIFICATE-----` wrapper.

#### Group Membership Configuration

By default, when enabled, Entra will share group assertions under the name `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` and provides the groups as a list of object ids.

Either the `Group Assertion Name` should be set to this name, or Entra configured to use a custom
assertion name that matches the FlowFuse SSO Configuration value.

Entra must also be configured to return group names rather than object ids.

### Google Workspace

Google provide a guide for creating a custom SAML Application [here](https://support.google.com/a/answer/6087519?hl=en){rel="&#x22;nofollow&#x22;"}.

Google Workspace only supports HTTPS-based SSO URLs. You cannot use it when developing
locally using `http://localhost:3000`.

The following table maps the Google Workspace terminology to the FlowFuse settings.

| FlowFuse Setting                       | Google Workspace Setting |
| -------------------------------------- | ------------------------ |
| `Identity Provider Single Sign-On URL` | `SSO URL`                |
| `Identity Provider Issuer ID / URL`    | `Entity ID`              |
| `X.509 Certificate Public Key`         | `Certificate`            |

Within the `Service provider details` configuration, the `Signed response` option must be enabled.

### OneLogin

Follow [this guide](https://onelogin.service-now.com/support?id=kb_article&sys_id=93f95543db109700d5505eea4b96198f){rel="&#x22;nofollow&#x22;"}
to create a `OneLogin SAML Test Connector`.

| FlowFuse Setting                       | OneLogin Setting           |
| -------------------------------------- | -------------------------- |
| `Identity Provider Single Sign-On URL` | `SAML 2.0 Endpoint (HTTP)` |
| `Identity Provider Issuer ID / URL`    | `Issuer URL`               |
| `X.509 Certificate Public Key`         | `X.509 Certificate`        |

### Okta

Within your Okta Admin dashboard, browse the App Integration catalog and add a new
instance of the `SAML Service Provider` integration.

On the Sign-On Options section, ensure SAML 2.0 is selected. Below that section
you will see a notice saying:

> SAML 2.0 in not configured until you complete the setup instructions.

Click the 'View setup instructions' button to open the page in a new window.

Follow the instructions on that - copying the `Identity Provider Issuer`,
`Identity Provider HTTP POST URL` and `Identity Provider Certificate` values
into the FlowFuse SSO configuration.

Back on the Okta SAML Application configuration page, under the `Advanced Sign-on Settings`
section enter the `Assertion Consumer Service URL` and `Service Provider Entity Id`
from the FlowFuse SSO configuration.

Under `Credential Details` section, change the Application username format to `Email`.

#### Group Membership Configuration

To configure Okta to return Group assertions, edit the Settings of the SAML Service Provider's
SAML 2.0 configuration. Expand the 'Attributes' section and add a `Group Attribute Statement`.

The name must match the `Group Assertion Name` in the FlowFuse SSO configuration (default: `ff-roles`).
You can optionally add a filter of `ff-` so that it only returns groups used by FlowFuse.

### Keycloak

Within your Keycloak Admin Console, create a new Client with the following settings:

Under the General Settings:

- Set `Client type` to `SAML`
- Set the `Client ID` to the `Entity ID / Issuer` value from the FlowFuse SSO configuration.

Under the Login Settings:

- Set `Valid redirect URIs` to the `ACS URL` value from the FlowFuse SSO configuration.

Once created and you are shown the full client configuration, make the following additional changes:

- Set `Name ID format` to `email`
- Under the 'Keys' tab, turn off `Client signature required`

Save the changes.

Next, select the 'Download adapter config' option under the 'Action' dropdown menu. Select the
'Mod Auth Mellon files' format and click Download.

This will download a zip file. Extract the zip and open the `idp-metadata.xml` file in a text editor.

The final task is to copy some of the contents of the XML file into the FlowFuse SSO configuration.

- Copy the value of the `entityID` attribute into the `Identity Provider Issuer ID / URL` property
- Find one of the `md:SingleSignOnService` tags and copy the value of its `Location` attribute into the `Identity Provider Single Sign-On URL` property
- Copy the contents of the `ds:X509Certificate` tag into the `X.509 Certificate Public Key` property

#### Group Membership Configuration

In Keycloak and the Realm setup with FlowFuse as a client:

- Create a new "Client Scope"
- Give it a name and ensure the "Protocol" is `SAML`
- After saving the scope, select the "Mappers" tab
- "Add mapper" and pick "By configuration"
- Select "Group list" from the options
- Give it a name and set "Group attribute name" to `ff-roles` (this must match the value configured in FlowFuse, default 'ff-roles')
- Enable 'Single Group Attribute'
- Ensure that "Full group path" is unchecked
- Save and return to the "Clients" list and select your FlowFuse Client created earlier
- Under "Client scopes", use the "Add client scope" button to add the new scope


# Usage Telemetry

The platform shares anonymous usage information with us at FlowFuse. This helps
us understand how the platform is being used, what areas need improvement
and how we should prioritise future work.

Ultimately, it helps us produce a better platform for all its users.

We do not collect:

- Any personally identifiable information. We do store a secure hash of the sending IP address - but the plain value is never stored
- Any specific details of the flows running on the platform.

## Core Telemetry

### Configuring Telemetry

By default, usage telemetry is enabled on the platform. The administrator can
opt-out of sharing information as part of the initial setup, or through the Admin
Settings section of the platform UI.

It is also possible to disable in the `flowforge.yml` configuration file. This
overrides whatever option is set in the Admin Settings UI.

**IMPORTANT: Licensed installations cannot disable telemetry**

```yaml
telemetry:
  enabled: false
```

### Collected Data

The following pieces of information are included in the telemetry sent back to us:

```json
{
  "instanceId": "5db51f99-c6fb-4340-9c19-78adce58cc1b",
  "os": { "type": "Darwin", "release": "20.5.0", "arch": "x64" },
  "env": { "nodejs": "v16.19.1", "flowforge": "1.0.0" },
  "platform": {
    "counts": {
      "users": 6,
      "teams": 5,
      "projects": 4,
      "devices": 9,
      "projectSnapshots": 16,
      "projectTemplates": 7,
      "projectStacks": 2,
      "libraryEntries": 0,
      "sharedLibraryEntries": 2
    },
    "config": {
      "driver": "localfs",
      "broker": {
        "enabled": true
      },
      "fileStore": {
        "enabled": true
      },
      "email": {
        "enabled": false
      }
    },
    "license": {
      "id": "4c105579-782b-4d53-af62-cf7fa69f6b43",
      "type": "DEV"
    }
  }
}
```

| Property                            | Description                                                                                  |
| ----------------------------------- | -------------------------------------------------------------------------------------------- |
| `instanceId`                        | A unique identifier for the FlowFuse instance.                                               |
| `os`                                | Information about the operating system                                                       |
| `env`                               | Node.js and FlowFuse versions                                                                |
| `platform.counts`                   | A snapshot of the number of users, teams, projects (instances), etc, in use on the platform. |
| `platform.config.driver`            | Which backend driver is being used                                                           |
| `platform.config.broker.enabled`    | A flag indicating whether the the internal comms broker is enabled                           |
| `platform.config.fileStore.enabled` | A flag indicating whether the file store is enabled                                          |
| `platform.config.email.enabled`     | A flag indicating whether email is enabled                                                   |
| `platform.license.id`               | The ID of the license loaded                                                                 |
| `platform.license.type`             | The type of the license                                                                      |

When the data is collected, we also store the timestamp the data was received and
a **hash** of the sending IP address - we do not store the plain value.

### Schedule

For the core tracking, the platform will send the telemetry data:

- 30 seconds after the platform starts up (but only if the platform has already been initialised)
- Once every 24 hours at a time randomly picked when the platform starts

The data is sent via an HTTP Post to `https://ping.flowforge.com`.

## Frontend Telemetry

The FlowFuse UI can be configured to track usage to help understand how users are navigating the pages.

It supports integration with two different services:

- [PostHog](https://posthog.com/){rel="&#x22;nofollow&#x22;"&#x7D; &#x2A;(recommended)*: You will require your own API key to pass into the `yml`, which will begin the logging of user interactions.
- [Sentry](https://sentry.io/){rel="&#x22;nofollow&#x22;"&#x7D; &#x2A;(recommended)*: You will need to specify your Sentry DSN for the frontend and back-end
- [Plausible](https://plausible.io/){rel="&#x22;nofollow&#x22;"&#x7D;: &#x2A;(deprecated since 0.9 and will be removed in the future)*: You can setup your own account, and pass the relevant domain to the `yml` in the telemetry configuration. As this option is deprecated, details of how to configure are no longer provided.

### Configuring Telemetry

| Option                                        | Description                                                                                                                                                                                                                                                                                              |
| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `telemetry.enabled`                           | Enables the anonymous usage telemetry of the platform. Default: `true`                                                                                                                                                                                                                                   |
| `telemetry.backend.sentry.dsn`                | The API key provided to you from your own sentry account. Default: `null`                                                                                                                                                                                                                                |
| `telemetry.frontend.posthog.apikey`           | The API key provided to you from your own PostHog account. Default: `null`                                                                                                                                                                                                                               |
| `telemetry.frontend.posthog.capture_pageview` | FlowFuse is designed as to provide custom posthog `$pageview` events that provide more detail on navigation than the default, and suit a single page application better. As such, we recommend setting this to false in order to prevent duplicate `pageleave`/`pageview` events firing. Default: `true` |
| `telemetry.frontend.sentry.dsn`               | The API key provided to you from your own sentry account. Default: `null`                                                                                                                                                                                                                                |
| `telemetry.frontend.sentry.production_mode`   | Should this instance be treated as production (lower session count recorded). Default: `false`                                                                                                                                                                                                           |

```yaml
telemetry:
  enabled: true
  frontend:
    posthog:
      apikey: <api-key>
      capture_pageview: false
    sentry:
      dsn: <dsn-key>
      production_mode: true
  backend:
    sentry:
      dsn: <dsn-key>
    prometheus:
      enabled: true
```

Sentry reads the environment variable `SENTRY_ENV`, falling back to `NODE_ENV` to set the environment for both frontend and backend.

#### Telemetry During Build

Configure .env with the auth token, org, and project name for the frontend project.

```yaml
# Used for BUILD time sentry reporting
SENTRY_AUTH_TOKEN=
SENTRY_ORG=
SENTRY_PROJECT=
```


# User management

## User registration

Depending on where FlowFuse is installed, users should or should not be allowed
to sign up for the service. User registration can be configured in the admin panel.
Go to "Admin Settings" > "Settings" and select or deselect "Allow new users to register on the login screen".

## Creating new users

To add new users to the platform go to "Admin Settings" > "Users" and click the
"New User" button. Fill out the form, and provide the new user with their password.

To require users to change their password the next time they log in, use the "Expire Password" option
on the "Edit User" dialog.

## Deleting a user

Users can only be removed if they are not the sole owners of any teams.

As such they must either delete their teams first or ensure their teams have
alternative owners. They can either do this themselves or an Admin do it for them.

They can then be removed via the "Edit User" dialog in the Admin view.


# FlowFuse Platform API

The platform provides a REST API that makes it possible to create integrations and
custom workflows.

The API comes with an OpenAPI 3.0 Specification that can be viewed [here](https://app.flowfuse.com/api/){rel="&#x22;nofollow&#x22;"},
or on any FlowFuse instance on the path `/api/`.

### Accessing the API

To make use of the API you will need a valid Access Token. Tokens can be generated
for a user under the Security section of the User Settings page.

![Tokens Settings Page](https://flowfuse.com/docs/api/images/tokens.png)

Tokens can be set to have a limited life or unlimited and can be revoked
by deleting the token from the list. Tokens with an expiry date will be deleted once they reach that date.

Be aware that the token value will only be displayed once, at creation time,
there is no way to recover the token after this point.

Currently, all routes require a valid token to be included in the request.

The tokens are passed using the `Authorization` header as a `Bearer` token.

For example, the following will get a list of the token owner's teams:

```text
curl -H "Authorization: Bearer ffpat_d4vZlLhCN8muyFUi6UsquLj47H2aTDkDpvxBUf5Ea" \
     https://app.flowforge.com/api/v1/user/teams
```

When sending data to the API, requests must set the `Content-Type` header to `application/json`.

For example, the following will update the name of the team with an id of `mNYLkklLAG`:

```text
curl -X PUT \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer ffpat_d4vZlLhCN8muyFUi6UsquLj47H2aTDkDpvxBUf5Ea" \
     -d '{"name": "My Development Team"}' \
     https://app.flowforge.com/api/v1/teams/mNYLkklLAG
```


# Billing

## Payment Methods

We will accept payments via credit or debit card only using Stripe as our payment
provider. All payments are processed in US Dollars.

## Team Billing

Each team has its own billing subscription that includes charges for the Node-RED
instances and Devices owned by the team.

## Billing Cycle

If you've signed up to FlowFuse Cloud without a yearly contract agreed upon with our sales team, your FlowFuse teams are billed monthly on the anniversary of the team creation. You will receive one bill for each team.

Hosted and Remote Instances which are added beyond the included amount are pro-rated charges on the current billing cycle and invoiced
at the end of the cycle.

## Removing Instances

When an instance is deleted your account will receive pro-rated credit for the time remaining in the billing cycle.

## Suspended Instances

Suspended Node-RED instances have no running editor, nor a runtime. You are not charged for suspended instances.

When an instance is suspended your account will receive pro-rated credit for the time remaining in the billing cycle. When an
instance is restarted it will be charged for the remaining time in the billing cycle.

## Managing Billing Details

Click on "Billing" followed by "Stripe Customer Portal" to get a summary of the team's current subscription. You'll be redirected to
a Stripe customer portal where you can update customer details as: The credit card on file and the billing information.

## Failed Payments

If your payment fails for any reason you will receive a notification to the billing email address, you may need to login and update the card on file.
Stripe will retry the payment several times over a number of days. If the card repeatedly fails your Node-RED instances will be suspended and a banner will be displayed at the top of the page for all users. An admin will need to update your card details to be able to create new instances or restart them.

## Cancelling your subscription

To cancel your subscription you can either delete or suspend your team; both options are available under the Team Settings page.

Deleting the team will remove all of the team's instances and devices - they cannot be recovered after being deleted.

Suspending the team will stop all of your team's instances and devices and cancel your subscription so no further charges are made. You will not be able to do anything more with the team whilst it is suspended. You can unsuspend the team in the future by setting up a new payment subscription.

When deleting the team, if you have outstanding credit you can request a refund via a [support ticket](https://flowfuse.com/support/), include the Team ID in your email.


# FlowFuse Cloud

FlowFuse Cloud is a hosted service allowing users to sign-up and start creating Node-RED instances without having to install and manage their own instance of FlowFuse.
The [Concepts](https://flowfuse.com/docs/user/concepts) remain the same, but we run the platform for you.

## 30-day Free Trial

When users sign-up to FlowFuse Cloud they get a 30-day free trial of the platform.
This is a great way to start using FlowFuse and discover a lot of the value it provides.

Users can end their trial by heading to the Billing page of their team and
setting up their payment information. This includes the option to pick which
plan you want to upgrade the team to.

Otherwise, at the end of the 30-day trial period, any instances created in the team
will be suspended. This means they will no longer be running and the
editor will not be accessible. Users will need to add their Billing details at which
point they will be able to restart their suspended Node-RED instances.

We will email users about their trial when it is nearing the end to ensure
they know what is happening.

## Billing

Customers are billed at the team level for each Node-RED instance they create. This is a recurring monthly charge.
See the [Billing](https://flowfuse.com/docs/cloud/billing) page for more detailed answers about billing.

## Support

Premium customers can get support by [filing a ticket](https://flowfuse.com/support). We offer
support for the FlowFuse application and your account, any issues relating to
Node-RED such as your flows or a 3rd party node should be raised in the
[community forum](https://community.FlowFuse.com){rel="&#x22;nofollow&#x22;"}.

### Requesting a new verification email

When a user signs up for FlowFuse Cloud an email will be sent to verify it.
If this email doesn't get delivered one can be resend by signing in to FlowFuse
and click the button to resend it.

## Team Types

FlowFuse Cloud offers a Trial and an Enterprise Team Type, aimed at different sorts of users

### Enterprise

Enterprise includes:

- HA for Instances
- SSO
- Better Support SLA
- MQTT Broker

Includes 10 instances and 20 MQTT Clients in the base price

### Changing Team Type

You can change Team Type by selecting the "Team Settings" option from the left hand
menu, then clicking on the "Change Team Type" button

![Change Team Type](https://flowfuse.com/docs/cloud/images/change-team-type.png)

From here you will be presented with a choice of Team Types. You will not be able
to downgrade to a lower Team Type if you already have more resources than allowed at
that level. Please Suspend or Delete any no longer required Instances or Devices.

![Available Team Types](https://flowfuse.com/docs/cloud/images/availble-team-types.png)

## Node-RED on FlowFuse Cloud

FlowFuse currently offers Node-RED 4.x, 3.x and 2.x to customers. When creating a
new instance a [stack](https://flowfuse.com/docs/user/concepts#stack) is chosen, which later
can be [upgraded to a later version](https://flowfuse.com/docs/user/changestack).

Each Node-RED can install custom modules as advertised in the [Flow Library](https://flows.nodered.org){rel="&#x22;nofollow&#x22;"}.

Note that some modules have dependencies on system libraries or other components that are not available within the FlowFuse
container images we use. Those modules cannot be used within FlowFuse Cloud. If you have a particular requirement, please
do [contact us](https://flowfuse.com/contact-us/){rel="&#x22;nofollow&#x22;"} so we can discuss what options may be available.

## Cloud Instance Sizes

The different sizes of Cloud Instances relate to how much memory and CPU is made
available to them.

Memory tends to be the main limiting factor for a Node-RED instance. The following
table shows what is currently allocated by instance size.

| Size   | Memory (RAM) |
| ------ | ------------ |
| Small  | 256MB        |
| Medium | 768MB        |
| Large  | 3840MB       |

Medium and Large instance types require the Enterprise tier.

## Use of the File System

FlowFuse Cloud hosted instances have access to a persistent file-system that will
retain the files stored on it across restarts of the instance.

A quota limit is applied to how much data can be stored, based on the Team type.
Enterprise teams have a file storage quota of 100GB per instance.

Files can be manually uploaded to an instance using the [Static Asset Service](https://flowfuse.com/blog/2024/08/flowfuse-2-8-release/#static-assets-service){rel="&#x22;nofollow&#x22;"}.

## Node-RED Context

Node-RED Context can be used to store small pieces of application state within the
runtime. By default, this is stored in memory only.

FlowFuse Cloud provides an optional context store that can be used to persist
the data.

The amount of data that can be stored in context is determined by the Team type.
Enterprise teams have a context store quota of 1GB per instance.

## Network Connections

### HTTP(S) & Websockets

Node-RED exposes an HTTPS interface on port 443 with each instance having its own hostname (`example.flowfuse.cloud`). Plain HTTP requests to port 80 will receive a redirect to HTTPS on port 443.
You MUST connect using the hostname not the IP address to reach your Node-RED instance.
Websocket connections over SSL (`wss:`) are also supported.

The payload size per request is limited to 5MB, which is the Node-RED default.
When a request exceeds this limit, the whole request is rejected with a `413 Payload Too Large` error.

### TCP and UDP

The default TCP and UDP nodes have been removed from the Node-RED palette. This is
because it is not possible to route these sorts of connections to the container running
Node-RED inside the FlowFuse Cloud platform.

### MQTT

MQTT Connections to an external broker using the standard MQTT nodes will work fine as the connection is initiated by Node-RED.

FlowFuse provides an MQTT broker for Enterprise Node-RED instances. See the following section.

Also the Project Nodes can be used to easily pass messages between Node-RED instances running in the
platform.

#### Enterprise Team Broker

Enterprise teams come with their own MQTT broker. You can provision clients from the broker tab in the left hand menu.

Enterprise level Teams can register up to 20 clients as part of their plan. The ability to purchase additional packs of clients will come in a near future release.

The broker is available on `broker.flowfuse.cloud` and supports the following connection types:

- MQTT on port `1883`
- MQTT over TLS on port `8883`
- MQTT over secure WebSockets on port `443`

When creating clients you can specify a username, but it will prepended to the the Team's id e.g. `alice` will become `alice@32E4NEO5pY`.
Clients must also use the username as the MQTT Client ID in order to connect.

![Create Broker Client](https://flowfuse.com/docs/cloud/images/create-broker-client.png)

e.g.

```text
mosquitto_sub -u "alice@32E4NEO5pY" -i "alice@32E4NEO5pY" -P "password" -h broker.flowfuse.cloud -t "#"
```

Or in Node-RED as follows

![Node-RED MQTT Client Connection](https://flowfuse.com/docs/cloud/images/node-red-mqtt-connection.png)

![Node-RED MQTT Client Security](https://flowfuse.com/docs/cloud/images/node-red-mqtt-security.png)

### IP Addresses

Outbound connections from FlowFuse will always come from the IP address `63.33.85.112`.

This can make access to a remote database or corporate network possible where those systems are protected by IP address filtering firewalls.

All incoming connections MUST use the hostname and not an IP address.

## Data Security

FlowFuse Cloud is hosted on Amazon Web Services. The following statements apply to data handling within the platform:

- The underlying database use the industry standard AES-256 encryption algorithm to encrypt the stored data.
- Persistent storage offered to Node-RED instances uses AES-256 encryption algorithm to encrypt data and metadata at rest.
- The network load balancer uses the latest recommended AWS Network Security policy. This enforces TLS1.2 as a minimum.

## Single-Sign On

FlowFuse supports configuring both SAML and LDAP based Single Sign-On for particular email domains.

This can be configured on request for FlowFuse Cloud by submitting a support request
via our [Contact Us](https://flowfuse.com/contact-us/){rel="&#x22;nofollow&#x22;"} page.

For SAML providers, you must have the ability to configure a SAML endpoint on your Identity Provider,
and have the authority to configure SSO for your email domain.

We have currently validated our SSO support with the following Identity Providers:

- Microsoft Entra
- Google Workspace
- OneLogin
- Keycloak

If you are using a different Identity Provider, please still get in touch, and we
can evaluate what will be required to enable it.

## Custom Hostnames

FlowFuse Cloud can support custom hostnames for instances in Enterprise teams.

This allows you to point your own subdomain, such as `dashboard.example.com` at
one of your instances.

See [Custom Hostnames](https://flowfuse.com/docs/user/custom-hostnames) for more information.

## Removing your account

Before you can delete your account, teams you own must either be deleted or have at least 1 other owner.
Once this is done, you can remove your account by going to the "User Settings" page and clicking the "Delete Account" button.

See also: [cancelling your subscription](https://flowfuse.com/docs/cloud/billing#cancelling-your-subscription).


# Adding Template Settings

Within FlowFuse, each Node-RED instance is created from a Template. The Template defines
a set of preconfigured options for the instance. This includes runtime settings -
values that you would normally expect to set in your Node-RED settings.js file.

The Template also defines which of those options can be customised by individual instances.

This guide explains how to add a new Node-RED runtime option to the Template object
so that it can be customised and passed through to the underlying Node-RED settings.js file.

This is reasonably straightforward for simple boolean/string/numeric types.
For other types (objects/arrays) it gets more complicated and we don't currently
have good examples to follow.

For the 'simple' cases, the steps are:

1. Update the Frontend
   1. Pick a name for the setting, add it to the list of known settings and any
      validation logic that is needed
   2. Add it to the appropriate Template section
2. Update the runtime
   1. Add it to the known list of settings and any additional validation logic
3. Update the Launcher
   1. Update the template used to generate settings.js with the new property

## 1. Updating the Frontend

There are a set of views in the frontend used to present and edit templates. They
get used in two different ways:

1. When creating/editing a template.
   All options are available and there is a dropdown that lets the user set the
   policy on the setting (which controls whether an instance is allowed to override
   the setting)
2. When editing instance settings.
   All options are shown, but only lets the user modify those that the template
   policy allows to be changed.

This reuse of the views saves a lot of code duplication, at the cost of some
complication in implementing it.

### 1.1 - Pick a name for the setting

The name should try to match its corresponding property in the Node-RED settings.js
file. Some thought should be made as to organisation of the properties.

1. Edit `frontend/src/pages/admin/Template/utils.js`
2. Add the new property name to the `templateFields` and `defaultTemplateValues` objects.
   Notice the names are flat strings with `_` used as a hierarchy separator... that
   will make more sense if you're looking at the file.
3. If the value needs any sort of validation, add it to `templateValidators` in the
   same file.

### 1.2 - Add it to the appropriate Template section

Currently there are:

- Editor
- Palette
- Environment - a special case that is unlikely to get other options added

These each lives in their own file under `frontend/src/pages/admin/Template/sections/`.

Pick an existing setting that most closely matches the setting you want to add
(ie checkbox or text input), and copy its entry to the appropriate place.

Make sure you update *all* of the references of the copied property name to your
new property name.

## 2. Updating the Runtime

### 2.1 - Adding it to the known list

1. Edit `forge/db/controllers/ProjectTemplate.js` to add the new property to the
   list of known settings.
2. In that same file, update the `validateSettings` function with any additional
   validation or data cleansing needed.

## 3. Update nr-launcher

In the `flowforge-nr-launcher` repo...

1. Edit `lib/runtimeSettings.js` to include the new setting in the generate settings.js
   file. Note that you must handle the case where the new setting is not present -
   either by applying a sensible default, or omitting the value.


# HTTP API of the FlowFuse platform

## API documentation

All public API routes should include a `schema` as part of their definition. This
serves a number of purposes:

- It will be included in the auto-generated OpenAPI 3.0 spec
- Fastify will validate requests include any required properties
- Fastify will ensure the response object matches the defined schema

Some general guidance:

- Ensure the routes have an appropriate tag set - this determines where in the
  Swagger UI it gets displayed.
- Ensure the tag is listed in `forge/routes/api-docs.js` so it appears in the right place
- We define view schemas under `forge/db/views/*` alongside the code that generates the view.
  Keep the naming consistent with other views.
- Learn from the existing schemas - be consistent in style.

References:

- [Fastify Validation and Serialization](https://fastify.dev/docs/latest/Reference/Validation-and-Serialization){rel="&#x22;nofollow&#x22;"}
- [OpenAPI 3.0 spec](https://swagger.io/specification/){rel="&#x22;nofollow&#x22;"}

## Object Ids

Most database models have a primary key of an auto-incrementing integer stored in
the `id` column.

These ids are internal properties of the models and should *not* be exposed via the
API. This is because they can be guessed and leak information about how many instances
of any particular model exist.

All model instances have an auto-generated `hashid` property that is an encoded version
of the `id` property. This property should be used on the API but aliased as the
`id` property.

Each database model has a pair of helper functions to encode and decode hashids
to/from the true `id` value:

```js
const encodedHashid = app.db.models.User.encodeHashid(123);
const objectId = app.db.models.User.decodeHashid("edjEbo2K1w")
```

## API Path design

### Admin routes

All admin-only routes exist under:

```txt
/api/v1/admin/...
```

### Logged-in user routes

All routes relating to the logged-in user exist under:

```txt
/api/v1/user/...
```

### Object collection routes

API routes that are related to objects in collections follow the pattern:

```txt
/api/v1/<plural-noun>/<instance-id>/...
```

## Implementing routes

All API routes exist under `forge/routes/api` in the repository, grouped into
files based on the entity/functionality the api is related to.

All requests will have already been validated to ensure they are being made with
a valid session for a logged in user, or an access token.

If there is a valid session, `request.session.User` will be the requesting user.

### Opening a route to anonymous users

In rare cases, a route needs to be accessible to anonymous users. To by-pass
the built-in preHandler, you can set `allowAnonymous` on the routes `config` object:

```js
app.get('/', { config: { allowAnonymous: true } }, async (request, reply) => {
     ...
})
```

### Team routes

Routes under `forge/routes/api/team.js` that relate to a specific team,
must use `:teamId` as the placeholder in the route. A request preHandler will
use that to ensure the requesting user has permission to access the instance.

The following properties will then be available on the `request`:

- `request.team` - the team
- `request.teamMembership` - the requesting user's role on the team

### Project routes

**Note:** In FlowForge 1.5 we started to replace the Project concept with that of Application
and Instance. No changes have been made to the underlying APIs - that will be evaluated
as part of 1.6.

Routes under `forge/routes/api/project.js` that relate to a specific instance,
must use `:projectId` as the placeholder in the route. A request preHandler will
use that to ensure the requesting user has permission to access the instance.

The following properties will then be available on the `request`:

- `request.project` - the instance (previously called "project")
- `request.teamMembership` - the requesting user's role on the team that owns the instance

### User/role permissions

Permissions are defined in `forge/routes/auth/permissions.js`.

Each permission specifies the role a user must have to have that permission.

If a route requires a particular permission, it can use `app.needsPermission` to
generate a preHandler function that will ensure any requesting user has that
permission.

For example, to add a user to a team, the requesting user needs to have
`"team:user:add"`:

```js
app.post('/', { preHandler: app.needsPermission("team:user:add") }, async (request, reply) => {
    // This is defined under forge/routes/api/teamMembers.js - and is mounted
    // under the path `/api/v1/teams/:teamId/members/`
    // Due to the team route preHandler, this means `request.teamMembership`
    // will be defined and will be used by the `needsPermission` handler
});
```

## Error formats

If a route needs to return an error it should respond with a payload in the format:

```js
{
    code: 'error_code',
    error: 'Human-readable message'
}
```

The `code` property should be a well-defined string that can be used to programmatically
identify the error without relying on the human-readable message.

There is a set of predefined codes that should be used where appropriate:

- `unauthorized`
- `invalid_request`
- `unexpected_error`

If the error is related to an invalid option/parameter/object selection, then the code
should be:

- `invalid_<name of property>`

For example: `invalid_project_name`.

## Pagination & Search

All routes that return collections of things must use pagination to allow for
future growth, and provide a way to search the collection.

### Pagination

We use a cursor-based approach to our pagination. A cursor is a pointer to an entity
in the collection and provides the starting point for what should be returned.

- End-points accept `cursor` and `limit` parameters
- If `cursor` is not provided, it returns from the beginning of the collection.
  For some end-points, this will mean returning the most recent entries -
  the `/api/v1/projects/:id/logs` for example.
- Each end-point should have a sensible default for the `limit` parameter

The response object for paginated end-points should have the format:

```js
{
    "meta": {
        "next_cursor": "16416724188790000",
    },
    "<object-type>": [ ],
    "count": 123
}
```

The `meta` property contains information to help the client navigate the collection.

- `next_cursor` - if set, provides the cursor to use to get the next page of results
- `previous_cursor` - if set, provides the cursor to use to get the previous page of results. Note
  that not all end-points need to be navigable in both directions so may never return
  `previous_cursor`.

The `<object-type>` property should be called the appropriate plural form of what is being returned,
such as `projects`.

The `count` property is optional and indicates the total number of objects in the collection.
End-points *should* include it if the number is known and is of material use. It is *not*
returned by end-points used to query logs etc as the total count is a constantly changing
value.

#### Cursor design

A cursor should be able to point directly at an entity in the collection. It could
be the entity hashid, or a timestamp if it is a time-series collection such as the
logs.

The cursor should *not* be the internal `id` of the entity in the collection - as we
do not expose those ids on the api, use the `hashid` value as the external `id`.

If an end-point supports navigating the collection in reverse (by returning `previous_cursor`),
the cursor should be prefixed with `-` to indicate the query should be in the opposite
direction to the collection's natural order.

### Search & Filtering

Search is done as simple case-insensitive text-based queries against string columns
in the database model. This is a crude but effective way to implement search but
may need a more comprehensive approach in the future.

The search value is provided via the `query` query parameter.

```text
/api/v1/example?query=something
```

Filtering can be used to limit the results based on the values of specific columns.

The Filter value is provided via additional query parameters.

```text
/api/v1/example?eventName=foo
```

### Implementing pagination & search

Two utility functions are provided to help implement pagination and search.

#### `app.getPaginationOptions`

This returns an object of pagination options for a given request, with any default
values automatically applied:

```js
const paginationOptions = app.getPaginationOptions(request, {limit: 1000})

// paginationOptions.limit = how many results to return
// paginationOptions.cursor = starting cursor
// paginationOptions.query = search string to use
// paginationOptions.* = any remaining query parameters
```

#### `buildPaginationSearchClause`

This takes the pagination options along with model-specific configuration options
to build a suitable `where` clause that can be passed to the database model's `getAll`
function.

```text
const where = buildPaginationSearchClause(params, whereClause, searchColumns, filterMap)
```

- `params` - the pagination object returned by `app.getPaginationOptions` for a given request
- `whereClause` - (optional) an object containing any additional query clauses that should be applied
- `searchColumns` - (optional) an array of fully-qualified column names that should be searched when `query=<xyz>` is included in query
- `filterMap` - (option) a map of filter name to fully-qualified column name that are valid filter parameters

With the filtering option, if a particular filter parameter is specified more than
once in the query string, the generated query will apply an Or between the values.

For example, lets consider the imaginary `Thing` model has a `name`, `description` and `type`.
The following will mean:

- any `query=<xyz>` parameter will be searched for in the `name` and `description` columns
- any `type=<abc>` parameter will filter on the `type` column.

```js
const { buildPaginationSearchClause } = require('../utils')

...

getAll: async (pagination = {}, where = {}) => {
    // Ensure a sensible default limit for this particular type of thing
    const limit = parseInt(pagination.limit) || 1000

    // Decode the cursor from hashid to database id
    if (pagination.cursor) {
        pagination.cursor = M.Thing.decodeHashid(pagination.cursor)
    }

    // Build the full where query using the buildPaginationSearchClause utility.
    // We pass in the list of columns that should be searched against
    where = buildPaginationSearchClause(
        pagination,
        where,
        ['Thing.name', 'Thing.description'],
        {
            type: 'Thing.type'
        }
    )

    // Run the query
    const { count, rows } = await this.findAndCountAll({
        where,
        order: [['id', 'ASC']],
        limit
    })

    // Return the results with the additional metadata
    return {
        meta: {
            next_cursor: rows.length === limit ? rows[rows.length - 1].hashid : undefined
        },
        count,
        things: rows
    }
}
```


# FlowFuse Architecture

A FlowFuse install is made up of 2 main components

- The Management Application
- The Node-RED instances

These can be deployed in one of 2 ways

- On a single machine :br![LocalFS Architecture](https://flowfuse.com/docs/contribute/images/ff-localfs.png)
- Using a Container Orchestration platform (Kubernetes/Docker Compose) :br![Container Architecture](https://flowfuse.com/docs/contribute/images/ff-containers.png)

## FlowFuse Management Application

This provides the interface for managing the objects in the platform. It also
provides a collection of APIs to support the Node-RED instances once started.

A key component is the Container API driver, this is the part that actually creates/destroys
Node-RED instances and keeps track of what should be running and restarts if needed.

### Container Drivers

Node-RED instances are started by the FlowFuse Management Application via one of the following Container Drivers. Documentation for the Container Driver API will be available in the [API](https://flowfuse.com/docs/api) section.

#### Localfs

This driver runs Node-RED as separate processes on the same machine as the FlowFuse Management Application. Each instance gets its own `userDir` and a dedicated TCP/IP port to listen to.

State is stored in a local SQLite database

There is no automatic Ingres automation provided by this driver.

#### Kubernetes

This driver runs Node-RED in separate containers and each instance is accessed by a dedicated hostname via an HTTP Ingres proxy.

The state is stored in a provided PostgreSQL database.

Node-RED containers are segregated into their own namespace (currently hardcoded to `flowforge`)

The driver uses the [@kubernetes/client-node](https://www.npmjs.com/package/@kubernetes/client-node){rel="&#x22;nofollow&#x22;"} to interact with the cluster.

The driver will create the required Service and Ingres Kubernetes resources to expose each instance via whatever Ingress Controller the underlying Kubernetes cluster provides.

#### Docker-Compose

This driver runs Node-RED in separate containers and each instance is accessed by a dedicated hostname via an HTTP Ingres proxy.

The state is stored in a provided PostgreSQL database.

The driver uses the [dockerode](https://www.npmjs.com/package/dockerode){rel="&#x22;nofollow&#x22;"} to interact with the cluster.

The driver will add the required Environment variables to each Node-RED container to work with the [jwilder/nginx-proxy](https://hub.docker.com/r/jwilder/nginx-proxy){rel="&#x22;nofollow&#x22;"} NGINX proxy.

## FlowFuse Instances

A FlowFuse Node-RED Instance is made up of 2 processes

- The FlowFuse Launcher
- A Node-RED instance

![Project Architecture](https://flowfuse.com/docs/contribute/images/ff-project-arch.png)

### FlowFuse Launcher

This is a small application that handles downloading the Instance specific settings, building a `settings.js` from those settings and then starting the Node-RED instance.

The launcher presents an HTTP API (it defaults to the Node-RED port + 1000) that allows the FlowFuse Management Application to start/stop/restart the Node-RED instance as well as query its current state and retrieve the console logs.

The launcher can be found [here](https://github.com/FlowFuse/nr-launcher){rel="&#x22;nofollow&#x22;"}

Within the launcher are some custom plugins that are loaded by Node-RED:

#### nr-storage

This plugin is used to save flows, settings, sessions, and library entries back to the FlowFuse Management Application.

#### nr-auth

This plugin is used to authenticate users trying to access the Node-RED Editor, it refers back to the FlowFuse Management Application to ensure only members of the team that owns the instance can log in.

This plugin uses the Node-RED [Authentication API](https://nodered.org/docs/user-guide/runtime/securing-node-red#custom-user-authentication){rel="&#x22;nofollow&#x22;"}

#### nr-audit-logger

This plugin sends Node-RED Audit events (e.g. user log in and flow deployment events) back to the to the FlowFuse Management Application to allow a reliable audit of what actions have taken place in the instance.

This plugin uses the Node-RED [Logging API](https://nodered.org/docs/user-guide/runtime/logging){rel="&#x22;nofollow&#x22;"}

## Component Overview

```mermaid
erDiagram
    USER ||--o{ NGINX : Requests
    NGINX {
        Protocol HTTP-TLS
        Port default-443
    }
    FORGE-APP {
        Protocol HTTP-TLS
        Port default-3000
    }
    POSTGRESQL {
        Protocol tcp-tls
        Port default-5432
    }
    MOSQUITTO {
        Protocol HTTP-TLS-WSS-MQTT
        Port default-1883
        Port websocket-1884
    }
    FLOWFORGE-FILE-SERVER {
        Protocol HTTP-TLS
        Port default-3001
    }
    NGINX }o--o| NODE-RED : routes
    NGINX }o--o{ FORGE-APP: routes
    NGINX ||--|| MOSQUITTO: mqtt-ws
    FORGE-APP ||--|{ POSTGRESQL: query
    FORGE-APP ||--|| NODE-RED: "flow update"
    NODE-RED }o--o{ FLOWFORGE-FILE-SERVER: "Blob store"
    FLOWFORGE-FILE-SERVER ||--|| FORGE-APP: "Authenticate"
    NODE-RED {
        Protocol HTTP-TLS
        Port default-1880
    }
    NODE-RED }o--|| MOSQUITTO: mqtt
    FORGE-APP }o--|| MOSQUITTO: mqtt
    NODE-RED-DEVICES {
        Port default-1880
        Protocol User-Defined
    }
    NODE-RED-DEVICES }o--|| NGINX: mqtt-ws
    USER ||--|| NODE-RED-DEVICES: Requests
```


# Creating Debug Stack Containers

Sometimes we want to be able to run some debug code within a stack running in our
staging test environment.

For example, changes to the `nr-launcher` component or any of the other components
that run within the stack.

This guide shows a simple way to do that without having to rebuild the container
from scratch each time.

This will require:

1. Docker
2. A container registry you can push images to. For example, a free DockerHub account where you can push images

### Creating a debug container

Pick an existing container image to use as your starting point. For example, `flowfuse/node-red:2.5.0-4.0.x`
contains `nr-launcher@2.5.0` and the latest Node-RED 4.x release.

**Note**: our staging environments requires `arm64` based containers. The following instructions work for
Macs (with M1/M2) - additional steps may be needed for other OS; please contribute them if you know them.

Use the following command to open a shell into the container:

```text
docker run -it --entrypoint /bin/bash flowfuse/node-red:2.5.0-4.0.x
```

The prompt will then look like this:

```text
e8dcd669ea4c:/usr/src/flowforge-nr-launcher$
```

Take a note of the `e8dcd669ea4c` - this is the id of the container instance you have created.

The following directories are probably of interest:

- `/usr/src/flowforge-nr-launcher` - contains the `nr-launcher` code and its dependencies
- `/usr/src/node-red` - contains the `node-red` code

Using `vi`, you can edit the files to make the changes you want and when you're done, exit the shell.

Having made the changes, use `docker commit` to create a new container image. The command requires
the id of the container you've just edited and the tag for the container. It also needs to restore
the `entrypoint` configuration back to the default.

```text
docker commit \
  --change='ENTRYPOINT ["./node_modules/.bin/flowfuse-node-red", "-p", "2880", "-n", "/usr/src/node-red"]' \
  e8dcd669ea4c \
  knolleary/ff-debug:debug-1
```

Finally, you can push the new container to your container registry.

```text
docker push knolleary/ff-debug:debug-1
```

### Using the container in FlowFuse

Debug containers should *only* be used in pre-staging/staging environments. Do *not* add to production.

Once pushed, you can create a custom stack in the FlowFuse admin section and give it the location
of your container.

### Iterating

If you find you want to add some more debug, repeat the process, however use your existing image
as the starting point:

```text
docker run -it --entrypoint /bin/bash knolleary/ff-debug:debug-1
```

Be sure to increment the number in the image name (`debug-2`) when you commit and push the new container.

### Tidying up

Remember to delete your instances/stacks once you're done, as well as all of the local
docker images and containers that have been created along the way.


# Database Migrations

Any changes made to the database models must include migrations
that can modify the database state from one state to another.

Whilst we use Sequelize as our ORM layer, we do not use the migration tooling
it provides - we have our own.

## Creating migrations

### Filename

A migration is provided as JavaScript in the directory `forge/db/migrations`.
Its file name must follow the pattern:

```text
YYYYMMDD-nn-description.js
```

- `YYYYMMDD` - the date the migration is added
- `nn` - a two digit number
- `description` - a name for the migration

For example `20220204-01-add-billing.js`.

This ensures the migrations have a natural order to be applied. The `nn` part of
the name allows multiple migrations to be added on the same day but is kept in the
right order.

### Structure

The migration code should use the following layout:

```js
module.exports = {
    up: async (context) => {
        // Apply the migration
    },
    down: async (context) => {
        // Remove the migration
    }
}
```

The `up` function applies to the migration. This can be to create new tables, add columns
to existing ones - whatever is needed.

The `down` function reverses the migration. It should restore the database back to
how it was prior to the migration.

The `context` argument is an instance of [Sequelize.QueryInterface](https://sequelize.org/docs/v6/other-topics/query-interface/){rel="&#x22;nofollow&#x22;"} that can be used to perform
operations on the database.

## Applying migrations

Migrations are applied automatically at the start of the FlowFuse application. Down
migrations are not yet supported.

## Considerations when writing migrations

Whilst migrations give us the ability to make changes to the database, they must
be used with great care. A failing migration will prevent the platform from starting
and may require manual intervention. Everything should be done to avoid that from
happening.

Certain types of migration need particular guidance and care over.

### Adding constraints

If a migration is adding a new constraint to an existing table, you need to consider
very carefully what impact that could have on an existing system with real data.

For example, adding a new 'unique' constraint where you cannot guarantee that
constraint hasn't already been broken. What strategy will you use to guard against
that or to help recover from it? What additional testing is needed for the migration
to verify its behavior in those situations?

The preferred method to add a new unique constraint is by adding a new index to the
database. This is because SQLite doesn't provide a way to alter columns that doesn't
involve dropping the whole table and triggering any cascade triggers.


# Working with Feature Flags

When adding features to the platform it is sometimes a requirement to be able to
restrict the feature to licensed platforms, and furthermore to certain types of team
on the platform.

Most typically this will be a feature that should only be available to the `Enterprise` tier on FlowFuse Cloud.

This is a quick guide for how to add a feature flag - both at the platform-wide
level and against individual `TeamTypes`.

Feature flag names should use `camelCase`.

### Add a platform-wide feature flag

All licensable features should set a platform-wide feature flag to indicate
the feature is available.

```text
app.config.features.register('featureFlagName', true)
```

[Here](https://github.com/FlowFuse/flowfuse/blob/0335c9056019ff9987d97f3ad3f18675de1c2422/forge/ee/lib/ha/index.js#L6){rel="&#x22;nofollow&#x22;"} is
an example of how the HA feature sets its platform-wide flag.

### Add a team type feature flag

The feature flag is set by an admin user via [`TeamTypeEditDialog.vue`](https://github.com/FlowFuse/flowfuse/blob/0335c9056019ff9987d97f3ad3f18675de1c2422/frontend/src/pages/admin/TeamTypes/dialogs/TeamTypeEditDialog.vue){rel="&#x22;nofollow&#x22;"}.

1. Add an entry to the existing list of feature flags [here](https://github.com/FlowFuse/flowfuse/blob/0335c9056019ff9987d97f3ad3f18675de1c2422/frontend/src/pages/admin/TeamTypes/dialogs/TeamTypeEditDialog.vue#L73-L85){rel="&#x22;nofollow&#x22;"}.
2. Add a check to ensure the right default value is applied [here](https://github.com/FlowFuse/flowfuse/blob/0335c9056019ff9987d97f3ad3f18675de1c2422/frontend/src/pages/admin/TeamTypes/dialogs/TeamTypeEditDialog.vue#L172-L174){rel="&#x22;nofollow&#x22;"}. Any new feature should default to `false` so it can then be selectively enabled.

### Using the feature flags - runtime side

Platform-wide feature flags can be checked using:

```text
const isFeatureEnabledOnPlatform = app.config.features.enabled('featureFlagName')

```

`TeamType` feature flags can be checked using the `getFeatureProperty` function
of the `TeamType` model:

```text
// myTeamType is an instance of `TeamType`
const isFeatureEnabledForTeamType = myTeamType.getFeatureProperty('featureFlagName', false)
```

The first arg is the name of the feature flag, the second arg is the default value
if the feature flag is otherwise unset. As mentioned above, any new feature should
default to `false`.

[Here](https://github.com/FlowFuse/flowfuse/blob/0335c9056019ff9987d97f3ad3f18675de1c2422/forge/ee/routes/sharedLibrary/index.js#L22){rel="&#x22;nofollow&#x22;"} is an example of this in action.

### Using the feature flag - frontend

In the frontend, platform-wide feature flags can be checked against
the `features` property of the `account` store.

TeamType feature flags can be checked against `team.type.properties.features.featureFlagName`.

[Here](https://github.com/FlowFuse/flowfuse/blob/0335c9056019ff9987d97f3ad3f18675de1c2422/frontend/src/pages/application/DeviceGroups.vue#L135-L146){rel="&#x22;nofollow&#x22;"} is an example of how we combine these two things:

```text
    computed: {
        ...mapState('account', ['features']),
        featureEnabledForTeam () {
            return !!this.team.type.properties.features?.deviceGroups
        },
        featureEnabledForPlatform () {
            return this.features.deviceGroups
        },
        featureEnabled () {
            return this.featureEnabledForTeam && this.featureEnabledForPlatform
        }
    },
```

This allows the UI to distinguish between a feature being unavailable because the platform
is not licensed for it, and a feature being unavailable for the current team type.

This allows different messages to be displayed with the most appropriate call to action.

The `EmptyState` component has support for this - see [here](https://github.com/FlowFuse/flowfuse/blob/0335c9056019ff9987d97f3ad3f18675de1c2422/frontend/src/pages/application/DeviceGroups.vue#L29){rel="&#x22;nofollow&#x22;"}
for how that is applied.

### Using the FEATURE\_CONFIGS composable

The recommended approach for frontend feature checks is to use the `FEATURE_CONFIGS` array
in `frontend/src/composables/FeatureChecks.ts`. Each entry defines a feature with platform
and/or team level checks, and the `buildFeatureChecks` function produces computed properties
that are available via the `featuresCheck` getter on the `account-settings` store.

Features can be **opt-in** (disabled by default, must be explicitly enabled per team type) or
**opt-out** (enabled by default, must be explicitly disabled). Opt-out features use `optOut: true`
in their config entry.

Features can also declare dependencies on other features using `dependsOn`, `dependsOnPlatform`,
and `dependsOnTeam`. For example, all AI sub-features depend on the `ai` flag:

```text
{ output: 'isExpertAssistantFeatureEnabled', platformKey: 'expertAssistant', teamKey: 'expertAssistant', optOut: true, dependsOnPlatform: 'ai', dependsOnTeam: 'ai', dependsOnTeamOptOut: true }
```

See the JSDoc on the `FEATURE_CONFIGS` array in `FeatureChecks.ts` for full documentation
of all available options.


# Contributing to FlowFuse

This guide will help you get setup to contribute to the FlowFuse project.

The core of the FlowFuse platform is available under the Apache-2.0 license and
we welcome contributions from the community.

### Software Requirements

This guide assumes you have a working development environment including:

- Node.js 18/20
- Platform build tools
  - Linux: `apt-get install build-essential`
  - MacOS: `xcode-select --install`
  - Windows: installed as part of the official node.js installer
    - ☑️ Automatically install the necessary tools must be checked
- Git

### Project Repositories

There are a number of repositories under the [FlowFuse GitHub organisation](https://github.com/FlowFuse){rel="&#x22;nofollow&#x22;"}
that make up the platform.

| Repository                                                                               | Description                                                                                                                                                                                                 |
| ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [FlowFuse](https://github.com/FlowFuse/flowfuse){rel="&#x22;nofollow&#x22;"}             | This is the core of the platform.                                                                                                                                                                           |
| [installer](https://github.com/FlowFuse/installer){rel="&#x22;nofollow&#x22;"}           | The installer for the platform                                                                                                                                                                              |
| [driver-localfs](https://github.com/FlowFuse/driver-localfs){rel="&#x22;nofollow&#x22;"} | The LocalFS driver. This deploys instances to the local system.                                                                                                                                             |
| [driver-docker](https://github.com/FlowFuse/driver-docker){rel="&#x22;nofollow&#x22;"}   | The Docker driver. This deploys instances as containers in a Docker-managed environment.                                                                                                                    |
| [driver-k8s](https://github.com/FlowFuse/driver-k8s){rel="&#x22;nofollow&#x22;"}         | The Kubernetes driver. This deploys instances as containers in a Kubernetes-managed environment.                                                                                                            |
| [nr-launcher](https://github.com/FlowFuse/nr-launcher){rel="&#x22;nofollow&#x22;"}       | The launcher application is used to start and monitor an individual instance of Node-RED in the FlowFuse platform. This includes a number of Node-RED plugins used to integrate with the FlowFuse platform. |

### Setting Up A Development Environment

With the project split across multiple repositories, setting up a development
environment manually takes quite a lot of steps to ensure everything is checked
out and configured properly.

To make it easier, you can use the [FlowFuse Development Environment](https://github.com/FlowFuse/dev-env){rel="&#x22;nofollow&#x22;"} project to get set up.

The following steps will get your development environment setup in no time:

```bash
git clone https://github.com/FlowFuse/dev-env.git
cd dev-env
npm install
npm run init
```

This clones all of the main project repositories, installs their dependencies and builds
the repositories that need it.

All of the repositories are cloned under the `packages` directory:

```txt
dev-env
└── packages
    ├── device-agent
    ├── docker-compose
    ├── driver-docker
    ├── driver-k8s
    ├── driver-localfs
    ├── file-server
    ├── flowfuse
    ├── helm
    ├── installer
    ├── nr-file-nodes
    ├── nr-launcher
    └── nr-project-nodes
```

More details on using the FlowForge Development Environment are available in its
[documentation](https://github.com/FlowFuse/dev-env){rel="&#x22;nofollow&#x22;"}.

### FlowFuse Code Structure

The `FlowFuse/flowfuse` repository is the core of the platform and where you'll
likely want to begin.

```txt
.
├── bin
├── config               - build config files
├── docs
├── etc                  - FlowFuse platform configuration files
├── forge                - Platform core code
│   ├── config
│   ├── containers
│   ├── db
│   ├── ee
│   ├── lib
│   ├── licensing
│   ├── monitor
│   ├── postoffice
│   ├── routes
│   └── settings
├── frontend             - Frontend code
│   ├── dist             - build output - created by `npm run build`
│   ├── public           - static assets
│   └── src              - vue src
│       ├── api
│       ├── components
│       ├── pages
│       ├── routes
│       └── store
├── test                 - tests for FlowFuse
└── var                  - where the database and localfs project directories are created
```

## Development Setup

1. [Create a Stack](https://flowfuse.com/#create-a-stack)
2. [Running FlowFuse](https://flowfuse.com/#running-flowfuse)
3. [Configuring FlowFuse](https://flowfuse.com/#configuring-flowfuse)
4. [Mocking email](https://flowfuse.com/#mocking-email)
5. [Testing](https://flowfuse.com/#testing)
6. [VSCode Tips](https://flowfuse.com/#vscode-tips)
7. [Team Broker](https://flowfuse.com/docs/contribute/team-broker)

### Create a Stack

You will need to setup the version(s) of Node-RED you want to use in your stacks.

From the `flowfuse` directory run

```bash
npm run install-stack --vers=3.1.9
```

Where `3.1.9` is the version of Node-RED you want to use in the stack.

#### Working with Local Nodes

If you want to test local, in-development nodes in FlowFuse, you can create a dedicated stack for this purpose.

```bash
npm run install-stack --vers=3.1.9
```

Navigate to the stacks directory:

```bash
cd /var/stacks
```

Rename the directory to something more appropriate:

```bash
mv "3.1.9" "3.1.9-local"
```

Install your local repository directly into the stack:

```bash
cd 3.1.9-local
npm install /path/to/your/nodes-repo
```

With your stack created from the terminal, you can now add it via the FlowFuse Admin UI - see [Managing Stacks](https://flowfuse.com/docs/admin/introduction/#create-new-stack).

### Running FlowFuse

A number of `npm` tasks are defined in the `package.json` file of this repository.
To get started from the `flowfuse` directory use:

```bash
npm run serve
```

This does a couple of things in parallel:

- Starts the core FlowFuse application and watches the source code for any
  changes - triggering a restart if needed.
- Builds the frontend application using WebPack and watches for any changes - triggering a rebuild as needed.

When running like this, the `NODE_ENV` environment variable gets set to `development`.

*Note*: if you have not used the [FlowFuse Development Environment](https://flowfuse.com/#setting-up-a-development-environment), then you will need to run `npm run build`
to build the platform before you can use `npm run serve`.

### Configuring FlowFuse

When running in development mode, the core app will use `etc/flowforge.yml` for its configuration.
As you may want to have a local configuration that you don't want to commit back to git,
you can create a file called `etc/flowforge.local.yml` and it will use that instead.
That filename is set to be ignored by git so it won't be accidentally committed.

### Mocking email

If you are developing locally and need to enable external email sending, you can either:

- Setup a local test SMTP server. For example, the Nodemailer project provides a
  useful app that does the job: <https://github.com/nodemailer/nodemailer-app/releases>{rel="&#x22;nofollow&#x22;"}
- Alternatively, set the `email.debug` option to `true` in your configuration file
  and the app will print all emails to its log.

### Configuring billing

If you need to develop features covered by the Billing EE feature, you will need
to configure the platform with a set of valid Stripe API keys and an EE license.

The *development-only* EE licence is provided in `flowfuse/forge/licensing/index.js`. This
licence is not valid for production usage.

For FlowForge Inc. employees the configuration is provided in 1Password as 'Stripe Testing Configuration'.

```yaml
license: ***

billing:
  stripe:
    key: ***
    wh_secret: ***
    team_price: ***
    team_product: ***
    project_price: ***
    project_product: ***
    device_price: ***
    device_product: ***
    deviceCost: 10
    new_customer_free_credit: 1000
    teams:
      starter:
        price: ***
        product: ***
        userCost: 0
```

You will also need to install the [Stripe CLI](https://stripe.com/docs/cli/){rel="&#x22;nofollow&#x22;"} to handle webhook callbacks properly. Install the CLI following their documentation, then
run the following command, with the API key using the value of `billing.stripe.key` from
above.

```bash
stripe listen --forward-to localhost:3000/ee/billing/callback --api-key ***
```

Note that due to the way Stripe works, you will receive events for *all* activity
in the configured Stripe account. That means if someone else is actively developing
with billing enabled on the same account, you will see their events arrive.

#### Free Trials

Free trials are implemented as a Stripe Credit that is applied when a FlowFuse user
creates their first team and completes billing sign up.

To enable trials, set the `billing.stripe.new_customer_free_credit` value to a credit amount in cents.
For a totally free trial, this amount should match the cost of the Stripe product for the project type to be trialed to be trialed.

The Stripe webhook forwarder must be running as the credit is handled as part of the webhook handling.

### Testing

Our testing philosophy follows the principle of:

> Write tests. Not too many. Mostly integration [1](https://flowfuse.com/#user-content-fn-1){#user-content-fnref-1 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""}

We create both unit tests and system level tests. The former is suitable for
well-contained components that need to provide a stable api and behavior to
the rest of the code base. The latter is for testing the external behavior
of the platform as a whole with as little internal mocking as possible.

We use code coverage reporting as *one* aspect of assessing our testing coverage.
We do not treat 100% coverage as an imperative goal - that can often lead to
busy work writing tests that don't provide any real value in understanding the
overall quality of the system.

Unit tests should provide sufficient coverage to give us confidence that a
component's behavior does not unexpectedly change.

#### Running tests

To run the tests for the project, you can use the following npm tasks:

- `npm run test` - runs the whole test suite, covering code linting, unit and systems tests.
- `npm run lint` - runs the linting tests
- `npm run test:unit` - runs the unit tests
- `npm run test:system` - runs the system tests
- `npm run test:docs` - checks the validity of links in the documentation

##### Testing against PostgreSQL

By default, the tests use an in-memory SQLite database to test against. This is
the most self-contained way of testing the platform. But it is also necessary to
test against PostgreSQL. To enable the use of PostgreSQL in the tests:

1. Ensure you have an instance of PostgreSQL running locally. For example, via docker:
   ```bash
      docker run -it -p 5432:5432 --name ff-postgres -e POSTGRES_PASSWORD=secret postgres:14
   ```
2. Enable PostgreSQL mode by setting the following environment variable:
   ```bash
      export FF_TEST_DB_POSTGRES=true
   ```
   :brThe database connection can be set using the following env vars (default values shown)
   ```bash
      export FF_TEST_DB_POSTGRES_HOST=localhost
      export FF_TEST_DB_POSTGRES_PORT=5432
      export FF_TEST_DB_POSTGRES_USER=postgres
      export FF_TEST_DB_POSTGRES_PASSWORD=secret
      export FF_TEST_DB_POSTGRES_DATABASE=flowforge_test
   ```

#### Reporting code coverage

The `test:*` tasks have corresponding code coverage tasks. These tasks run the
tests using `nyc` to generate code coverage information.

- `npm run cover` - runs the whole test suite (excluding linting) with code
  coverage enabled and generates a report (via the `cover:report` task)
- `npm run cover:unit` - runs the unit tests with code coverage enabled. It
  does *not* generate the report.
- `npm run cover:system` - runs the system tests with code coverage enabled. It
  does *not* generate the report.
- `npm run cover:report` - generates a report of the code coverage. This is
  printed to the console and generates a browsable HTML copy under `coverage/index.html`

### VSCode Tips

To step debug in VSCode

1. Open `launch.json` config and enter the JavaScript below
2. Choose `Start-Watch` from the "Run and Debug" menu
3. Press ▶️ or :kbd[F5] to start debugging

There are 2 other "Run and Debug" entries in the menu...

- "Attach by Process ID" - this will allow you to attach to a launched driver
- "Debug Current Test" - this will enable you to step debug a test (starts debugging the currently open test file)

####

```json
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "command": "npm run start-watch",
            "name": "Start-Watch",
            "request": "launch",
            "type": "node-terminal",
            "env": {
                "NODE_ENV": "development"
            }
        },
        {
            "name": "Attach by Process ID",
            "processId": "${command:PickProcess}",
            "request": "attach",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "type": "node"
        },
        {
            "type": "node",
            "request": "launch",
            "name": "Debug Current Test",
            "program": "${workspaceFolder}/node_modules/mocha/bin/_mocha",
            "args": [
              "--no-warnings",
              "-u",
              "bdd",// set to bdd, not tdd
              "--timeout",
              "999999",
              "--colors",
              "${file}"
            ],
            "env": {
                "NODE_ENV": "development"
            },
            "internalConsoleOptions": "openOnSessionStart"
        }
    ]
}
```

## Footnotes

1. <https://kentcdodds.com/blog/write-tests>{rel="&#x22;nofollow&#x22;"} [↩](https://flowfuse.com/#user-content-fnref-1){.data-footnote-backref ariaLabel="Back to reference 1" dataFootnoteBackref=""}


# Local Install

This guide is for setting up FlowFuse on a single machine, ideal for smaller deployments, evaluations, or for contributors who want to gain a basic understanding of the FlowFuse platform and its features.

**Note: Local installation does not support HTTPS**

## Prerequisites

### Operating System

The install script has been tested against the following operating systems:

- Raspbian/Raspberry Pi OS versions Buster/Bullseye [1](https://flowfuse.com/#user-content-fn-1){#user-content-fnref-1 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""}
- Debian Buster/Bullseye
- Fedora 35
- Ubuntu 20.04
- CentOS 8/RHEL 8/Amazon Linux 2
- MacOS Big Sur & Monterey on Intel & Apple M processors
- Windows 10 & 11

### Node.js

FlowFuse requires &#x2A;**Node.js v20***.

#### Linux

The install script will check to see if it can find a suitable version of Node.js.
If not, it will offer to install it for you.

It will also ensure you have the appropriate build tools installed that are often
needed by Node.js modules to build native components.

#### Windows/MacOS

If the install script cannot find a suitable version of Node.js, it will exit.

You will need to manually install it before proceeding. Information about
how to do this can be found on the Node.js website here: <https://nodejs.org/en/download>{rel="&#x22;nofollow&#x22;"}

You will also need to install the appropriate build tools.

- **Windows**: the standard Node.js installer will offer to do that for you.
- **MacOS**: you will need the `XCode Command Line Tools`to be installed.
  This can be done by running the following command:
  ```bash
  xcode-select --install
  ```

## Installing FlowFuse

1. Create a directory to be the base of your FlowFuse install. For example: `/opt/flowforge` or `c:\flowforge`:br For Linux/MacOS:
   ```bash
   sudo mkdir /opt/flowforge
   sudo chown $USER /opt/flowforge
   ```
   :brFor Windows:
   ```bash
   mkdir c:\flowforge
   ```
2. Download the latest [Installer zip file](https://github.com/FlowFuse/installer/releases/latest/download/flowforge-installer.zip){rel="&#x22;nofollow&#x22;"} into a temporary location.
3. Unzip the downloaded zip file and copy its contents to
   the FlowForge directory
   ### For Linux/MacOS:
   :br&#x2A;Assumes `/tmp/` is the directory where you downloaded `flowforge-installer.zip`*
   ```bash
   cd /tmp/
   unzip flowforge-installer.zip
   cp -R flowforge-installer/* /opt/flowforge
   ```
   ### For Windows:
   :br&#x2A;Assumes `c:\temp` is the directory where you downloaded `flowforge-installer.zip`*
   ```bash
   cd c:\temp
   tar -xf flowforge-installer.zip
   xcopy /E /I flowforge-installer c:\flowforge
   ```
4. Run the installer and follow the prompts :br For Linux/MacOS:
   ```bash
   cd /opt/flowforge
   ./install.sh
   ```
   :brFor Windows:
   ```bash
   cd c:\flowforge
   install.bat
   ```

### Installing as a service (optional)

On Linux, the installer will ask if you want to run FlowFuse as a service.
This will mean it starts automatically whenever you restart your device.

If you select this option, it will ask if you want to run the service as the
current user, or create a new `flowforge` user. If you choose to create the
user, it will also change the ownership of the FlowFuse directory to that user.

## Configuring FlowFuse

The default FlowFuse configuration is provided in the file `flowforge.yml`

- Linux/MacOS: `/opt/flowforge/etc/flowforge.yml`
- Windows: `c:\flowforge\etc\flowforge.yml`

The default configuration file already contains everything you need to get started with FlowFuse.

It will allow you to access FlowFuse and the Node-RED instances you create, from the same server running the platform.
If you want to allow access from other devices on the network, you must edit the configuration file and
change the `host` setting to `0.0.0.0` and change `base_url` to contain the IP address of the server.

NOTE: We do not support changing the `host` and `base_url` values once you have created an instance.
For more information on all of the options available, see the [configuration guide](https://flowfuse.com/docs/install/configuration).

## Running FlowFuse

To run it manually, you can use:

- Linux/MacOS:
  ```bash
  /opt/flowforge/bin/flowforge.sh
  ```
- Windows:
  ```bash
  c:\flowforge\bin\flowforge.bat
  ```

Or to run as a service:

- Linux
  ```bash
  service flowforge start
  ```

## First Run Setup

Once FlowFuse is started, you will be ready to perform the first run setup.

Follow [this guide](https://flowfuse.com/docs/install/first-run) to continue.

## Setting up Mosquitto (optional)

The platform depends on the [Mosquitto MQTT Broker](https://mosquitto.org/){rel="&#x22;nofollow&#x22;"} to
provide real-time messaging between devices and the platform.

This is currently an *optional* component - the platform will work without the
broker, but some features will not be available (e.g Access to Remote Instance Editor
and Remote Instance logs requires the MQTT Broker).

We do **not** support sharing a broker with other non-FlowFuse applications. If you
already have mosquitto installed and running, you will need to run a second instance
dedicated to FlowFuse.

You can either follow the manual install steps, which involve building the authentication
plugin from scratch, or make use of the [Docker install](https://flowfuse.com/#docker-install).

### Manual install

**Note**: if you are running on Windows, you will need to follow the [Docker install](https://flowfuse.com/#docker-install)
instructions below due to a limitation of the authentication plugin we use.

Follow the appropriate [install instructions](https://mosquitto.org/download/){rel="&#x22;nofollow&#x22;"} for
your operating system.

Once installed, you can download pre-built binaries for Linux platforms from
[here](https://github.com/iegomez/mosquitto-go-auth/releases/latest){rel="&#x22;nofollow&#x22;"} and then jump
to step 4 below.

On MacOS you will need to build and install the authentication plugin.

1. Clone the plugin repository
   ```bash
   git clone https://github.com/iegomez/mosquitto-go-auth.git
   ```
2. Follow the instructions on [building the plugin](https://github.com/iegomez/mosquitto-go-auth#building-the-plugin){rel="&#x22;nofollow&#x22;"}
3. This should result in a file called `go-auth.so` being generated
4. Run mosquitto with the configuration file found in the `broker` directory :br You will need to customise the values to match your local configuration:
   - `auth_plugin` - set to the path of the `go-auth.so` file built in the previous step
   - `listener 1883/1884` - if you already have mosquitto running locally, you'll need to
     change these ports to something else.
   - `auth_opt_http_host` / `auth_opt_http_port` - if you plan to run the platform
     on a different port, change these settings to match.
   ```bash
   mosquitto -c broker/mosquitto.conf
   ```

### Docker Install

Instead of installing and building mosquitto and the authentication plugin from source,
you can use a pre-built docker image that provides everything needed.

1. First pull the latest version of the pre-built container
   ```bash
   docker pull iegomez/mosquitto-go-auth
   ```
2. A default mosquitto.conf file can be found in the `broker` directory. :br You will need to customise the values to match your local configuration:
   - `auth_opt_http_host` value to match the IP address of either the docker0 interface or the external IP address of the machine running the FlowFuse platform
   - `auth_opt_http_port` if you have changed the port the FlowFuse platform is running on
   - `auth_plugin` should be changed to `auth_plugin /mosquitto/go-auth.so`
3. Start the container with the following command
   ```bash
   docker run -d -v /opt/flowforge/broker/mosquitto.conf:/etc/mosquitto/mosquitto.conf -p 1883:1883 -p 1884:1884 --name flowforge-broker iegomez/mosquitto-go-auth
   ```
   :brThis will map the `1883`/`1884` ports to the host machine so they can be accessed outside of the container. If you already have an MQTT broker running on port 1883, then you'll need to modify the `-p` options to use a different set of ports. For example: `-p 9883:1883 -p 9884:1884`.

## File Server

By default the FlowFuse File Server component is disabled as it is a licensed feature. If you provide a license you can start the File Server with the following command:

```bash
sudo service flowforge-file start
```

You can then uncomment the following section in the `/opt/flowforge/etc/flowforge.yml` file

```yaml
#################################################
# File Server config                            #
#################################################

fileStore:
  url: http://localhost:3001

```

## Upgrade

If upgrading from 1.x.y to 2.x.y then you may need to upgrade from NodeJS v16 to NodeJS v18.
Please ensure you do this before the following steps.

To upgrade to the latest release you can follow these steps. Replace `x.y.z` with the
version you are upgrading to.

1. Stop FlowFuse `sudo service flowfuse stop` [2](https://flowfuse.com/#user-content-fn-2){#user-content-fnref-2 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""}
2. Change into the `app`directory
   - `cd /opt/flowforge/app` (Linux/MacOS)
   - `cd c:\flowforge\app` (Windows)
3. NPM install the desired version
   - `sudo -u flowforge npm install @flowfuse/flowfuse@x.y.z` (Linux/MacOS) [3](https://flowfuse.com/#user-content-fn-3){#user-content-fnref-3 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""}
   - `npm install @flowfuse/flowfuse@x.y.z` (Windows)
4. Check the release notes for any additional steps needed to upgrade the particular version
5. Restart FlowFuse `sudo service flowfuse start` [2](https://flowfuse.com/#user-content-fn-2){#user-content-fnref-2-2 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""}

If you are running as your normal user you can drop the `sudo -u flowfuse` and just run `npm install @flowfuse/flowfuse@x.y.z`

## Uninstall

To uninstall, stop all the running processes and then delete the `/opt/flowfuse` or `c:\flowfuse\` directory.

## Footnotes

1. Arm6 devices, such as the original Raspberry Pi Zero and Zero W are not supported. [↩](https://flowfuse.com/#user-content-fnref-1){.data-footnote-backref ariaLabel="Back to reference 1" dataFootnoteBackref=""}
2. Assumes you are running FlowFuse as a Linux service. [↩](https://flowfuse.com/#user-content-fnref-2){.data-footnote-backref ariaLabel="Back to reference 2" dataFootnoteBackref=""} [↩2](https://flowfuse.com/#user-content-fnref-2-2){.data-footnote-backref ariaLabel="Back to reference 2-2" dataFootnoteBackref=""}
3. Assumes you are running FlowFuse as the `flowfuse` user as created by the installer [↩](https://flowfuse.com/#user-content-fnref-3){.data-footnote-backref ariaLabel="Back to reference 3" dataFootnoteBackref=""}


# Local Stacks

A Stack defines a set of platform configuration options that will get
applied to each Node-RED instance when it is created.

For the Local deployment model, this covers two things:

- `memory` - the value to apply (in MB) to the Node.js `max-old-space-size` option.
  This defines the point where Node.js will start freeing unused memory. It is
  not a hard limit - Node-RED's memory usage will not be capped - but this
  is useful when running on a memory constrained device such as a Raspberry Pi. Recommended minimum `256`.
- `nodered` - the version number of Node-RED to use. This should match the value used in the steps following.

The FlowFuse installer will create a default stack using the latest stable
release of Node-RED.

The stacks are stored under `/opt/flowforge/var/stacks` or `c:\flowforge\var\stacks` on Windows.

### Creating a Stack

When a new version of Node-RED is released, it can be added to your FlowFuse
platform by creating a new stack.

For a local install there are two steps required:

1. Install a new Node-RED version :br In the FlowFuse Home directory, run the provided install script. You
   must provide the full Node-RED version number, eg `3.0.2`, or use `latest` to install the most recent stable version. :br Linux/Mac:
   ```bash
   cd /opt/flowforge
   ./bin/ff-install-stack.sh 3.0.2
   ```
   :brWindows
   ```bash
   cd c:\flowforge
   bin\ff-install-stack.bat 3.0.2
   ```
2. Add the Stack into the FlowFuse Admin UI - see [Managing Stacks](https://flowfuse.com/docs/admin/introduction/#managing-stacks).

### Development Only

If you are developing FlowFuse having checked it out from GitHub then you can run
the following command in the repository root to install a stack:

```bash
npm run install-stack --vers=3.0.2
```


# Team Broker configuration

The FlowFuse Team Broker makes use of an EMQX instance.

## Requirement

- Docker

## Configuration files

Create a directory where the configuration for your broker will live. Create the following three files, with their respective content, in that directory:

cluster.hocon

```text
authentication = [
  {
    backend = http
    body {
      clientId = "${clientid}"
      password = "${password}"
      username = "${username}"
    }
    connect_timeout = "15s"
    enable = true
    enable_pipelining = 100
    headers {
      content-type = "application/json"
    }
    mechanism = password_based
    method = post
    pool_size = 8
    request_timeout = "5s"
    ssl {
      ciphers = []
      depth = 10
      enable = false
      hibernate_after = "5s"
      log_level = notice
      reuse_sessions = true
      secure_renegotiate = true
      verify = verify_peer
      versions = [
        "tlsv1.3",
        "tlsv1.2"
      ]
    }
    url = "http://host.docker.internal:3000/api/comms/v2/auth"
  },
  {
    backend = built_in_database
    bootstrap_file = "${EMQX_ETC_DIR}/auth-built-in-db-bootstrap.csv"
    bootstrap_type = plain
    enable = true
    mechanism = password_based
    password_hash_algorithm {name = plain, salt_position = disable}
    user_id_type = username
  }
]
authorization {
  cache {
    enable = true
    excludes = []
    max_size = 32
    ttl = "1m"
  }
  deny_action = ignore
  no_match = allow
  sources = [
    {
      body {
        action = "${action}"
        topic = "${topic}"
        username = "${username}"
      }
      connect_timeout = "15s"
      enable = true
      enable_pipelining = 100
      headers {
        content-type = "application/json"
      }
      method = post
      pool_size = 8
      request_timeout = "30s"
      ssl {
        ciphers = []
        depth = 10
        enable = false
        hibernate_after = "5s"
        log_level = notice
        reuse_sessions = true
        secure_renegotiate = true
        verify = verify_peer
        versions = [
          "tlsv1.3",
          "tlsv1.2"
        ]
      }
      type = http
      url = "http://host.docker.internal:3000/api/comms/v2/acls"
    },
    {   
      enable = false
      path = "data/authz/acl.conf"
      type = file
    }
  ]
}
listeners {
  tcp {
    default {
      acceptors = 16
      access_rules = [
        "allow all"
      ]
      bind = "0.0.0.0:1883"
      enable = true
      enable_authn = true
      max_conn_rate = infinity
      max_connections = infinity
      mountpoint = "${client_attrs.team}"
      proxy_protocol = false
      proxy_protocol_timeout = "3s"
      tcp_options {
        active_n = 100
        backlog = 1024
        buffer = "4KB"
        high_watermark = "1MB"
        keepalive = none
        nodelay = true
        reuseaddr = true
        send_timeout = "15s"
        send_timeout_close = true
      }
      zone = default
    }
  }
  ws {
    default {
      acceptors = 16
      access_rules = [
        "allow all"
      ]
      bind = "0.0.0.0:8083"
      enable = true
      enable_authn = true
      max_conn_rate = infinity
      max_connections = infinity
      mountpoint = "${client_attrs.team}"
      proxy_protocol = false
      proxy_protocol_timeout = "3s"
      tcp_options {
        active_n = 100
        backlog = 1024
        buffer = "4KB"
        high_watermark = "1MB"
        keepalive = none
        nodelay = true
        reuseaddr = true
        send_timeout = "15s"
        send_timeout_close = true
      }
      websocket {
        allow_origin_absence = true
        check_origin_enable = false
        check_origins = "http://localhost:18083, http://127.0.0.1:18083"
        compress = false
        deflate_opts {
          client_context_takeover = takeover
          client_max_window_bits = 15
          mem_level = 8
          server_context_takeover = takeover
          server_max_window_bits = 15
          strategy = default
        }
        fail_if_no_subprotocol = true
        idle_timeout = "7200s"
        max_frame_size = infinity
        mqtt_path = "/"
        mqtt_piggyback = multiple
        proxy_address_header = "x-forwarded-for"
        proxy_port_header = "x-forwarded-port"
        supported_subprotocols = "mqtt, mqtt-v3, mqtt-v3.1.1, mqtt-v5"
        validate_utf8 = true
      }
      zone = default
    }
  }
}
dashboard {
  default_password = topSecret
}
api_key {
  bootstrap_file = "/mounted/config/api-keys"
}
```

acl.conf

```text
{allow, {username, {re, "^dashboard$"}}, subscribe, ["$SYS/#"]}.

{allow, {ipaddr, "127.0.0.1"}, all, ["$SYS/#", "#"]}.

{deny, all, subscribe, ["$SYS/#"]}.

{allow, all}.
```

api-keys

```text
flowforge:verySecret:administrator
```

## Starting

The following docker command should be run in the directory the configuration files were stored.

```text
docker run -d --rm \
  -v $(pwd)/cluster.hocon:/opt/emqx/data/configs/cluster.hocon \
  -v $(pwd)/api-keys:/mounted/config/api-keys \
  -v $(pwd)/acl.conf:/opt/emqx/data/authz/acl.conf \
  --add-host=host.docker.internal:host-gateway \
  -p 1883:1883 -p 8083:8083 -p 18083:18083 --name emqx emqx/emqx:5.8.0
```

## Configuring FlowFuse

Make sure the `broker` section of the `flowfuse.yml` is updated as follows

```text
broker:
  url: mqtt://[::1]:1883
  public_url: ws://<ip-of-dev-computer>:8083
  teamBroker:
    enabled: true
```

## Access to the EQMX Dashboard

You can log into the EMQX Dashboard at `http://locahost:18083`

Username: `admin`
Password: `topSecret`


# Enabling the device editor

```mermaid
sequenceDiagram
    User->>FrontEnd: Clicks 'open editor' against device
    FrontEnd->>+Forge: PUT /api/v1/devices/:id/editor { tunnel: 'enable' }
    Forge->Forge: Generates <token>
    Forge--)Device: Publishes command to establish connection with <token>
    Device--)Forge: WS Connect /api/v1/devices/:id/editor/comms/:token
    
    Forge->>-FrontEnd: Returns session identifier
    FrontEnd->>FrontEnd: Opens /device/<id>/editor/
    FrontEnd-->+Forge: Sends requests to /device/<id>/editor/**
    Forge--)+Device: Request proxied over WebSocket
    Device-->>Editor: Performs request on local Node-RED
    Editor-->>Device: Returns response
    Device-->>-Forge: Streams response back
    Forge-->>-FrontEnd: Streams response back
    User->>FrontEnd: User navigates away
    FrontEnd-->Forge: Node-RED WebSocket closes
    Note over Forge: if no active WebSockets for this device
    Forge--)Device: Close WebSocket
```


# Workflows

A collection of sequence diagrams for key parts of the FlowFuse platform

- [Login](https://flowfuse.com/docs/contribute/workflows/login)
- [User Sign Up](https://flowfuse.com/docs/contribute/workflows/signup)
- [Password Reset](https://flowfuse.com/docs/contribute/workflows/password-reset)
- [Invite External User](https://flowfuse.com/docs/contribute/workflows/invite-external-user)
- [Team Create](https://flowfuse.com/docs/contribute/workflows/team-create)
- [Project Create](https://flowfuse.com/docs/contribute/workflows/project-create)
- [Project States](https://flowfuse.com/docs/contribute/workflows/project-states)


# Invite External User Flow

```mermaid
sequenceDiagram
    autonumber
    participant UserEmail
    participant InvitedUser
    participant TeamOwner
    participant UI
    participant Runtime
    participant DB
    Note over TeamOwner: TeamOwner wants to invite an external user to a team
    TeamOwner->>UI: Opens Add Team Members dialog
    TeamOwner->>UI: Enters User email, clicks okay
    UI->>+Runtime: POST /api/v1/teams/:teamId/invitations
    Runtime->>DB: Create Invitation
    Runtime->>UserEmail: Send email containing link to /account/create?email={email}`
    Runtime->>DB: Update audit log
    Runtime-->>-UI: { status: 'okay' }
    Note over TeamOwner: TeamOwner role complete
    UserEmail-->>InvitedUser: Email received
    InvitedUser->>+UI: Opens /account/create?email={email}
    UI->>UI: Prefills email field of sign-up page
    InvitedUser->>UI: Enters details on sign-up page
    InvitedUser->>UI: Clicks Sign-up
    UI->>+Runtime: POST /account/register
    Runtime->>Runtime: Checks an invite exists for this email
    Note over InvitedUser,Runtime: Standard sign-up flow continues
```

- See also [User Sign Up](https://flowfuse.com/docs/contribute/workflows/signup)


# User Login Flows

This represents the login flow as of FlowFuse 1.2, that incorporates optional
SSO

```mermaid
sequenceDiagram
participant U as User
participant B as Browser
participant RT as ForgeApp
participant DB as Database
participant IDP as IdentifyProvider
U->>B: Enters username/email on sign-up page
U->>B: Clicks login
B->>RT: POST /account/login (username=XYZ)
RT->DB: Checks username/email against list of SSO registered domains
alt Email not SSO enabled
    RT->>B: 403:{ code: 'password_required' }
    B->>U: Shows password box
    U->>B: Enters password
    U->>B: Clicks login
    B->>RT: POST /account/login (username/password)
    RT->>DB: Validates username/password
    RT->>B: 200:{}
end

alt Email SSO enabled
    alt Username provided or Password provided
        RT->>B: 403:{ code:'sso_required', error:'Please login with your email' }
        B->>U: Prompts user to enter email not username
    end
    alt Email provided
        RT->>B: 403:{ code:'sso_required', redirect:'/account/login?u=<base64 encoded email>' }
        B->>RT: GET /account/login?u=<base64 encoded email>
        RT->>RT: passport.authenticate
        RT->>IDP: SAML exchange
        IDP->>IDP: User authentication
        IDP->>RT: POST <TBD>
        RT->>DB: Verify Email against users
        alt Valid User
            RT->>DB: create session
            RT->>B: redirect to /
            else Unknown User
            RT->>B: redirect to /
        end
    end
end
```


# Reset Password Flow

```mermaid
sequenceDiagram
    autonumber
    participant UserEmail
    participant User
    participant UI
    participant Runtime
    participant DB
    User->>UI: Access the login page
    UI->>UI: Displays 'forgot pw' if `user:reset-password`=true
    User->>UI: Clicks 'forgot password'
    User->>UI: Enters their email address, clicks submit
    UI->>+Runtime: POST /account/forgot_password { email: <email> }
    Runtime->>DB: Get user
    DB->>Runtime: User
    Runtime->>DB: Generate AccessToken { scope: 'password:reset' }
    Runtime->>UserEmail: Send email containing reset link
    Runtime-->>-UI: { status: 'okay' }

    UserEmail-->>User: Email received
    User->>UI: Opens /account/change-password/{token}
    User->>UI: Enters new details, clicks submit
    UI->>+Runtime: POST /account/reset_password/:token { password }
    Runtime->>DB: Validate {token} is a valid password reset token
    Runtime->>DB: Get the user associated with token
    Runtime->>DB: Change users password
    Runtime->>DB: Delete the token
    Runtime->>-UI: {status: 'okay' }
    UI->UI: Prompt user to login

```


# Sequence For Project Creation

```mermaid
sequenceDiagram
autonumber
participant User
participant Ui
participant Runtime
participant ContainerDriver
participant DB
participant Stripe

User->>Ui: Clicks Create Project
User->>Ui: Enters Project Name
Ui->>Runtime: POST /projects
alt billing enabled
  Runtime->DB: Team has Subscription
  DB->>Runtime: Subscription
  alt Valid Subscription
    Runtime->>Stripe: Add Project to Subscription
    Runtime->>ContainerDriver: create()
    Runtime->>ContainerDriver: start()
    Runtime->>Ui: { status: "okay" }
    Ui->>Ui: Show Project Overview
    alt success
      Stripe->>Runtime: POST /ee/billing/callback
    else failure
      Stripe->>Runtime: POST /ee/billing/callback
      Runtime->>ContainerDriver: stop()
      Runtime->>ContainerDriver: disable()
      Runtime->>User: email message
    end
  else no Subscription
    Runtime->>Ui: Failed to create project, no Billing info
  end
else no billing
  Runtime->>Ui: { status: "okay" }
  Ui->>Ui: Show Project Overview
end
```


# States

- **Starting (first time)** The nr-laucher process is starting up. On container based systems this is done by creating a container
- **Loading** nr-launcher pulling instance settings
- **Installing** Once the nr-launcher process has started and downloaded the Instance settings it will npm install any nodes in the settings -> palette section.
- **Starting (second time)** Once any nodes are installed the Node-RED process will be started, this state ends once the process can will respond to HTTP request
- **Running** The normal state for an Instance
- **Restarting** If the "Restart" action is triggered the nr-launcher will restart just the NR process inside the container. It will pull the latest settings data from the Forge app. A restart will also be triggered if the NR process fails to respond to 3 HTTP health checks in a row. Health checks run ever 7 seconds by default.
- **Suspending** driver has been asked to suspend the Instance
- **Suspended** When an instance is Suspended the Node-RED process is stopped and the nr-launcher shutdown, the container is then shutdown and removed on container based platforms
- **Safe** Node-RED can be started in Safe Mode, this starts the Editor but does not run the flows. This is to allow a user to edit the flow to fix a problem. The flows are started when the flows are deployed. This is triggered if the NR process restarts more than 5 times with a run time of less than 30 seconds between each restart.
- **Stopped** If the NR process continues to crash while in Safe Mode then it will be placed in to a Stopped state. The nr-launcher is still running but the NR process is not.

# 2.3.0

```mermaid
stateDiagram-v2
direction TB
InstanceCreated: Instance Created
state "nr-launcher" as nrLauncher {
  direction TB
  LoadingSettings
  NPM
  NodeRED
  Safe: Safe Mode
  Stopped

  LoadingSettings --> NPM: loading
  NPM --> NPM: installing
  NPM --> NodeRED: starting
  NodeRED --> NodeRED: restarting
  NodeRED --> NodeRED: running
  NodeRED --> Safe: safe
  Safe --> Stopped: crashed
}
InstanceDeleted: Instance Deleted
InstanceSuspended: Instance Suspended

[*] --> InstanceCreated
InstanceCreated --> nrLauncher : starting
nrLauncher --> InstanceDeleted
nrLauncher --> InstanceSuspended: suspending
InstanceSuspended --> nrLauncher: starting
InstanceSuspended --> InstanceSuspended: suspended
InstanceDeleted --> [*]
```


# User Sign Up Flow

```mermaid
sequenceDiagram
    autonumber
    participant UE as UserEmail
    participant US as User
    participant UI
    participant RT as Runtime
    participant DB
    US->>UI: Enters details on sign-up page
    US->>UI: Clicks Sign-up
    UI->>+RT: POST /account/register
    RT->>DB: Create User
    RT->>RT: Generate Email Verification Token
    par Runtime to UserEmail
        RT->>UE: Send email containing verification code
    and Runtime to UI
        RT-->>-UI: { status: 'okay' } and session created
    end

    UI->>UI: Show 'Check your email' page
    UE-->>US: Email received
    US->>+UI: Enters verification code
    US->>UI: Click "Continue" button
    UI->>+RT: POST /account/verify/token { token }
    RT->>RT: Checks {token} is for the logged in user
    RT->>DB: User.email_verified=true
    loop for each pending invite
        RT->>DB: Add user to team
        RT->>DB: Delete invite
        RT->>DB: Update audit log
    end
    RT-->>-US: Redirect '/'
```


# Sequence For Team Creation

```mermaid
sequenceDiagram
autonumber
participant User
participant Ui
participant Runtime
participant ContainerDriver
participant DB
participant Stripe

User->>Ui: Clicks Create Team
User->>Ui: Enters Team Name
alt billing enabled
Ui->>Runtime: POST /api/v1/teams
Runtime->>DB: Create Team
Runtime->>Stripe: checkout.create.session
Stripe->>Runtime: Session ID
Runtime->>Ui: { billingURL: "https://stripe..." }
Ui->>Stripe: Redirect
User->>Stripe: Enters Credit Card info
alt complete
Stripe->>Ui: Redirect to Ui
Ui->>Ui: Show Team Overview
Stripe->>Runtime: POST /ee/billing/callback
Runtime->>DB: Create Subscription
else abort
Stripe->>Ui: Message 
Ui->>Runtime: DELETE /api/v1/teams/{id}
end
else: no billing
Ui->>Runtime: POST /teams
Runtime->>DB: Create Team
Runtime->>Ui: { status: "okay"}
Ui->>Ui: Show Team Overview
end
```


# Node-RED Safe Mode

When a Node-RED instance is unresponsive, for example due to an infinite loop,
it can be put into Safe Mode.

1. Edit the instance's [Environment Variables](https://flowfuse.com/docs/user/envvar)
2. Add a variable called `NODE_RED_ENABLE_SAFE_MODE` to `true`.
3. Save the changes then suspend/restart the instance.

When starting up in Safe Mode, Node-RED will provide access to the editor without
starting the flows. You can log in to the editor, make any necessary changes
and then deploy to restart the flows.

Once recovered you should delete the `NODE_RED_ENABLE_SAFE_MODE` environment variable
to prevent it entering Safe Mode the next time it is restarted.


# Deploying Flows to the Device Agent

Before you're able to deploy your flows to your Remote Instance,
you will have needed to have completed these steps:

1. [Install the Device Agent on the Device](https://flowfuse.com/docs/device-agent/install/overview) - installs Node-RED and other requirements in order to communicate with FlowFuse.
2. [Register the Remote Instance with FlowFuse](https://flowfuse.com/docs/device-agent/register) - this step will have provided you with a `device.yml` file to move to your Remote Instance.
3. [Run the Device Agent](https://flowfuse.com/docs/device-agent/running) - starts the Device Agent on the Remote Instance.

## Deploying a Node-RED Snapshot to the Remote Instance From a Hosted Instance

To deploy a Node-RED Snapshot to the Remote Instance:

1. [Create a snapshot](https://flowfuse.com/docs/user/snapshots#create-a-snapshot) - a point-in-time
   backup of the Node-RED flows and configuration.
2. [Mark that snapshot](https://flowfuse.com/docs/user/snapshots#setting-a-device-target-snapshot) as the **Remote Instance Target** snapshot.

This model allows you to develop your flows in FlowFuse and only push it out
to the registered Remote Instances when you're happy with what you've created.

## Starting Node-RED on the Remote Instance without deploying a snapshot

A Remote Instance can be assigned to an application without a snapshot being deployed to it.

In this mode, the Remote Instance will start Node-RED with a default set of flows that can
be edited on the Remote Instance see [Editing the Node-RED flows on a Remote Instance that is assigned to an application](https://flowfuse.com/#editing-the-node-red-flows-on-a-remote-instance-that-is-assigned-to-an-application) below

## Editing the Node-RED flows on a Remote Instance that is assigned to an instance

When running in the default of Fleet Mode, the device agent does not allow local access to the
Node-RED editor. This ensures the Remote Instance is running the deployed snapshot without modification.

When running on FlowFuse Cloud, or a premium licensed FlowFuse instance (with the
[MQTT broker enabled](https://flowfuse.com/docs/contribute/local/#setting-up-mosquitto-optional){rel="&#x22;nofollow&#x22;"})
the Remote Instance can be placed in Developer Mode that enables remote access to the editor.

This can then be used to develop the flows directly on the Remote Instance and a new snapshot
generated from the Remote Instance that can be deployed to other Remote Instances in the application.

Whilst in Developer Mode the Remote Instance will not receive new updates from the platform
when new snapshots are deployed.

**Accessing the Editor**

1. Once developer mode is enabled, click the **Enable** button next to the 'Editor Access' option
2. When the editor is available, the Editor button in the header will become active and will take you to the device editor.

**Creating a Remote Instance Snapshot**

To create an instance snapshot from the Remote Instance use the **Create Snapshot** button
in the Developer Mode options panel.

You will be prompted to give the snapshot a name and description. See [Snapshots](https://flowfuse.com/docs/user/snapshots) for more information
about working with snapshots.

## Editing the Node-RED flows on a Remote Instance that is assigned to an application

Access to the editor is only available when:

- The Remote Instance is in Developer Mode
- When running on FlowFuse Cloud, or a premium licensed FlowFuse instance (with the
  [MQTT broker enabled](https://flowfuse.com/docs/contribute/local/#setting-up-mosquitto-optional){rel="&#x22;nofollow&#x22;"}
  the Remote Instance can be placed in Developer Mode that enables remote access to the editor.
- Local access to the editor can be enabled by defining a Username & Password in the Device
  Settings -> Security and enabling "Allow offline access"
  ![Device Allow Offline Access Settings](https://flowfuse.com/docs/device-agent/images/device-local-access.png){dataZoomable=""}*Device Allow Offline Access Settings*

Whilst in Developer Mode the Remote Instance will not receive new updates from the platform.

**Enabling Developer Mode**

1. Go to your team's **Remote Instances** page.
2. Select the Remote Instance you want to edit by clicking its name.
3. Click the "Developer Mode" button to enable developer mode.
4. Once enabled, Developer Mode options are available under the tab labelled "Developer Mode" on the Remote Instance page.

**Accessing the Editor**

1. Once developer mode is enabled, click the **Enable** button next to the 'Editor Access' option
2. When the editor is available, the Editor button in the header will become active and will take you to the Remote Instance editor.

**Creating a Remote Instance Snapshot**

To create a snapshot from an application owned Remote Instance use the **Create Snapshot** button
in the Developer Mode options panel.

You will be prompted to give the snapshot a name and description. See [Snapshots](https://flowfuse.com/docs/user/snapshots) for more information
about working with snapshots.

**Auto Remote Instance Snapshots**

For Remote Instances that are assigned to an application, the platform will automatically create a snapshot of the Remote Instance
when it detects flows modified. This snapshot will be created with the name "Auto Snapshot - yyyy-mm-dd hh\:mm-ss".
Only the last 10 auto snapshots are kept, others are deleted on a first in first out basis.

**Custom Node Catalogues**

For Remote Instances that want to make use of custom node catalogues, these can be configured
under the Remote Instance settings page on the Palette tab

**.npmrc file**

Likewise for Remote Instances that need to be provided with a custom `.npmrc` file to allow access
to a custom npm registry or to provide an access token this can also be set on the Remote Instance
settings Palette tab

### Important Notes

- Remote access to the editor requires Device Agent v0.8.0 or later.
- The Web UI requires Device Agent v0.9.0 or later.
- Assigning a Remote Instance to an application requires Device Agent v1.11.0 and FlowFuse v1.11.0 or later.
- Snapshots of Remote Instances assigned to an application are supported in FlowFuse V1.12.0 or later.
- Deploying a snapshot from a different Hosted Instance or Remote Instance to an application owned Remote Instance is supported in FlowFuse V1.13.0 or later.
- When a Remote Instance is assigned to a Hosted Instance:
  - It must first have a snapshot applied before editor access is possible.
  - Disabling Developer Mode and returning to Fleet Mode will cause the Remote Instance to check in with the platform.
    If the Remote Instance flows have changed, it will be reloaded with the current target snapshot assigned to that Remote Instance,
    causing any changes made in Developer Mode to be overwritten. Therefore, it is recommended to create a snapshot
    of the changes before disabling Developer Mode.
- When a Remote Instance is assigned to an application:
  - It will start with a set of default flows.
- The Remote Instance will not receive any updates from the platform while in Developer Mode.
- The Remote Instance must be online and connected to the platform to enable "Editor Access".
- To minimise server and Remote Instance resources, it is recommended to disable "Editor Access" when not actively developing flows on a Remote Instance.
- Auto snapshots were introduced in FlowFuse V2.1.
- Auto snapshots are only supported for Remote Instance assigned to an application.
- If an auto snapshot is set as the target snapshot for a Remote Instance or assigned to a pipeline stage, it will not be auto cleaned up meaning it is possible to have more than 10 auto snapshots.


# FlowFuse Device Agent Installer

## What is the FlowFuse Device Agent Installer?

The FlowFuse Device Agent Installer is a CLI tool for the FlowFuse Device Agent that automatically sets up Node.js runtime, installs the device agent package, and configures it as a system service.
Additionally, it provides a simple interface for keeping the device agent up to date.

The FlowFuse Device Agent Installer is the easiest way to get the FlowFuse Device Agent up and running on your remote device.

## Requirements

- Linux, macOS, or Windows
- Internet connection for downloading dependencies
- Administrator/root privileges for system service installation

### Networking requirements

Please see [Networking requirements](https://flowfuse.com/docs/device-agent/install/overview#networking-requirements).

## Use the FlowFuse Device Agent Installer to install or update the FlowFuse Device Agent

### One-line install

For the fastest one-line install experience, see the [Quick Start guide](https://flowfuse.com/docs/device-agent/quickstart).

### Manual install

If you prefer to install the FlowFuse Device Agent manually with the Installer, you can follow these steps:

#### 1. Download the installer script:

##### Linux/macOS

```bash
/bin/bash -c "$(curl -fsSL https://flowfuse.github.io/device-agent/get.sh)"
```

##### Windows

```bash
powershell -c "irm https://flowfuse.github.io/device-agent/get.ps1|iex"
```

#### 2. Install the Device Agent using One Time Code

##### Linux/MacOS

```bash
./flowfuse-device-agent-installer --otc <one-time-code>
```

##### Windows (run elevated[1](https://flowfuse.com/#user-content-fn-1){#user-content-fnref-1 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""})

```bash
flowfuse-device-agent-installer.exe --otc <one-time-code>
```

### Other installation options

#### Install without One Time Code

You can also install the FlowFuse Device Agent without a One Time Code by providing the `device.yml` content during interactive installation. To do this, run the installer without the `--otc` flag.

##### Linux/MacOS

```bash
./flowfuse-device-agent-installer
```

##### Windows (run elevated[1](https://flowfuse.com/#user-content-fn-1){#user-content-fnref-1-2 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""})

```bash
flowfuse-device-agent-installer.exe
```

#### Install in custom directory

There is a possibility to install the Device Agent in a custom directory by using the `--dir` option. For example:

##### Linux/MacOS

```bash
./flowfuse-device-agent-installer --dir /path/to/custom/dir
```

##### Windows (run elevated[1](https://flowfuse.com/#user-content-fn-1){#user-content-fnref-1-3 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""})

```bash
flowfuse-device-agent-installer.exe --dir C:\path\to\custom\dir
```

#### Install on custom port

You can configure a custom port using the `--port` flag. The service name includes the port, for example `flowfuse-device-agent-1882` for `--port 1882`.

##### Linux/MacOS

```bash
./flowfuse-device-agent-installer --port 1882
```

##### Windows (run elevated[1](https://flowfuse.com/#user-content-fn-1){#user-content-fnref-1-4 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""})

```bash
flowfuse-device-agent-installer.exe --port 1882
```

## Updating components

### Node.js runtime

To update bundled Node.js runtime, specify the `--update-nodejs` flag with the desired version:

```bash
./flowfuse-device-agent-installer --update-nodejs --nodejs-version 20.19.1
```

Specifying `--update-nodejs` without a version will pick the default version defined in the installer. From the Device Agent v4 release, the installer defaults to Node.js 22.

### Device Agent

To update the Device Agent package, use the `--update-agent` flag, optionally specifying the version:

```bash
./flowfuse-device-agent-installer --update-agent --agent-version 3.3.2
```

Specifying `--update-agent` without the `--agent-version` flag will update to the latest available version.

## Troubleshooting

### Managing the Device Agent service

Services are named per-port, for example `flowfuse-device-agent-1880`. On macOS, the launchd label is `com.flowfuse.device-agent-1880`.

#### Linux (systemd)

```bash
sudo systemctl start flowfuse-device-agent-<port>
sudo systemctl stop flowfuse-device-agent-<port>
sudo systemctl restart flowfuse-device-agent-<port>
```

#### Linux (SysVinit)

```bash
sudo service flowfuse-device-agent-<port> start
sudo service flowfuse-device-agent-<port> stop
sudo service flowfuse-device-agent-<port> restart
```

#### Linux (OpenRC)

```bash
sudo rc-service flowfuse-device-agent-<port> start
sudo rc-service flowfuse-device-agent-<port> stop
sudo rc-service flowfuse-device-agent-<port> restart
```

#### macOS (launchd)

```bash
sudo launchctl start com.flowfuse.device-agent-<port>
sudo launchctl stop com.flowfuse.device-agent-<port>
sudo launchctl kickstart -k system/com.flowfuse.device-agent-<port>
```

#### Windows (Service Control)

```bash
sc.exe start flowfuse-device-agent-<port>
sc.exe stop flowfuse-device-agent-<port>
```

### Check the Device Agent service status

You can check the status of the Device Agent service to verify if it is running correctly or to diagnose any issues.
The status command provides information about the current state of the service, including whether it is active, inactive, or failed.

#### Linux (systemd)

```bash
sudo systemctl status flowfuse-device-agent-<port>
```

#### Linux (SysVinit)

```bash
sudo service flowfuse-device-agent-<port> status
```

#### Linux (OpenRC)

```bash
sudo rc-service flowfuse-device-agent-<port> status
```

#### macOS (launchd)

```bash
sudo launchctl print system/com.flowfuse.device-agent-<port>
```

#### Windows (Service Control)

```bash
sc.exe query flowfuse-device-agent-<port>
```

### Viewing Device Agent log files

Adjust the path if custom directory has been specified during installation.

#### Linux/macOS:

```bash
tail -f /opt/flowfuse-device/logs/flowfuse-device-agent.log
```

#### Linux (systemd):

```bash
journalctl -f -u 'flowfuse-device-agent-<port>'
```

#### Windows:

```powershell
Get-Content -Path 'C:\opt\flowfuse-device\flowfuse-device-agent.log' -Wait
```

### Error: Disk space check failed

> [ERROR] Disk space check failed: insufficient disk space in temporary directory (/tmp): need at least 500.0 MB, available 490.4 MB

##### Cause:

The `Disk space check failed` error indicates that the installer has detected insufficient disk space in the temporary directory.
The FlowFuse Device Agent Installer requires a minimum of 500MB of free disk space in the temporary directory to ensure proper installation.

This error might also appear if there is not enough space on the disk partition where the Device Agent is being installed.
Make sure that the target installation directory has at least 500MB of free space available.
[Adjust installation directory](https://flowfuse.com/docs/device-agent/install/device-agent-installer/#install-in-custom-directory) accordingly.

##### Solution:

To fix this issue, you can try to free up some disk space by deleting unnecessary files or moving them to another location.
Alternatively, you can specify a different temporary directory with sufficient space by setting proper environmental variable before running the installer.

**On Linux/macOS**, set the `TMPDIR` environment variable:

```bash
export TMPDIR=/path/to/existing/directory/with/sufficient/space
```

**On Windows**, you can set the `TEMP` or `TMP` environment variable:

```powershell
Set TMP="C:\path\to\existing\directory\with\sufficient\space"
```

Retry installation after making these adjustments.

## Further reading

For more detailed technical information about the FlowFuse Device Agent, like list of supported parameters or how to contribute, please refer to the [documentation](https://github.com/FlowFuse/device-agent/blob/main/installer/README.md){rel="&#x22;nofollow&#x22;"}.

## Footnotes

1. Run `powershell -Command "Start-Process 'cmd' -Verb RunAs"` to launch an elevated command prompt window (e.g. as an admin user) [↩](https://flowfuse.com/#user-content-fnref-1){.data-footnote-backref ariaLabel="Back to reference 1" dataFootnoteBackref=""} [↩2](https://flowfuse.com/#user-content-fnref-1-2){.data-footnote-backref ariaLabel="Back to reference 1-2" dataFootnoteBackref=""} [↩3](https://flowfuse.com/#user-content-fnref-1-3){.data-footnote-backref ariaLabel="Back to reference 1-3" dataFootnoteBackref=""} [↩4](https://flowfuse.com/#user-content-fnref-1-4){.data-footnote-backref ariaLabel="Back to reference 1-4" dataFootnoteBackref=""}


# Docker Install

Run the Device Agent in a container. Bind-mount your `device.yml` and expose the editor port.

## Prerequisites

- Docker or Docker Compose
- A `device.yml` configuration from [Register your Remote Instance](https://flowfuse.com/docs/device-agent/register)

## Docker run

```bash
docker run \
  --mount type=bind,src=/path/to/device.yml,target=/opt/flowfuse-device/device.yml \
  -p 1880:1880 \
  flowfuse/device-agent:latest
```

### Time zone

Set the container time zone using the `TZ` environment variable:

```bash
docker run \
  -e TZ=Europe/London \
  --mount type=bind,src=/path/to/device.yml,target=/opt/flowfuse-device/device.yml \
  -p 1880:1880 \
  flowfuse/device-agent:latest
```

## Docker Compose

```yaml
version: '3.9'

services:
  device:
    image: flowfuse/device-agent:latest
    ports:
      - "1880:1880"
    volumes:
      - /path/to/device.yml:/opt/flowfuse-device/device.yml
    environment:
      - TZ=UTC
```

## Running as a non-root user

From Device Agent v4, the container no longer runs as `root`. It runs as the unprivileged `flowfuse` user (UID `2000` / GID `2000`), following least-privilege security practices.

This affects bind-mounted directories: the directory the agent uses for its state must be writable by UID/GID `2000`, otherwise the agent will fail to start with a permissions error.

Before upgrading an existing container to v4, update the ownership of any mounted directory so the `flowfuse` user can access it:

```bash
sudo chown -R 2000:2000 /path/to/config/dir
```

Alternatively, run the container as a user of your choosing with the `--user` flag:

```bash
docker run \
  --user 1000:1000 \
  --mount type=bind,src=/path/to/device.yml,target=/opt/flowfuse-device/device.yml \
  -p 1880:1880 \
  flowfuse/device-agent:latest
```

## Verify

Once running and assigned, access the Node-RED editor at `http://<device-ip>:1880`.

## Notes

- Device Agent 4.x defaults to Node.js 22; the `latest` tag now uses Node.js 22. Node.js 20 reached end-of-life in April 2026.
- Device Agent 3.x uses Node.js 18 in the base image. To stay on a specific line, use a fixed tag instead of `latest`.
- For 2.x, use a fixed tag like `2.8.0` instead of `latest`.
- Ensure outbound TCP 443 to `app.flowfuse.com` and `mqtt.flowfuse.cloud` and access to `https://registry.npmjs.com` unless using a module cache. See [Running with no access to npmjs.org](https://flowfuse.com/docs/device-agent/running#running-with-no-access-to-npmjsorg).


# Kubernetes Install

## When to Use Each Option

Running the Device Agent in Kubernetes is appropriate when devices are containerized or managed as part of a Kubernetes-based edge or infrastructure platform.

Choose your deployment pattern based on how you manage device identity:

- **Fixed Configuration**:br
  Use when the device already exists in FlowFuse and you have a `device.yml` with its credentials. One deployment maps to one device identity.
- **Automatic Provisioning**:br
  Use when devices should register themselves at startup using a Provisioning Token. Each instance requires writable persistent storage.

Any deployment on Kubernetes is going to be specific to the environment and requirements of the solution. The following examples show two common patterns for running the FlowFuse Device Agent on Kubernetes:

- Fixed configuration using a static `device.yml`
- Automatic provisioning using a FlowFuse Provisioning Token

Choose the approach that matches how you manage device lifecycle and credentials.

## Fixed Configuration

If you have an existing `device.yml` file containing a set of Device Agent credentials.

```bash
kubectl create secret generic device-one-secret --from-file=device.yml=./device.yml
```

The following manifest will create a Deployment and Service for a device using the supplied Secret as its credentials

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: device-one
  labels:
    app: device-one
spec:
  replicas: 1 # there can only be one replica as there is one configuration
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: device-one
  template:
    metadata:
      labels:
        app: device-one
    spec:
      containers:
      - name: device-one
        image: flowfuse/device-agent:latest
        ports:
        - containerPort: 1880
        volumeMounts:
        - name: config
          mountPath: "/opt/flowfuse-device/device.yml"
          subPath: "device.yml"
          readOnly: true
        resources:
          limits:
            cpu: 1000m
            memory: 256Mi
          requests:
            cpu: 500m
            memory: 128Mi
      volumes:
      - name: config
        secret:
          secretName: device-one-secret
---
apiVersion: v1
kind: Service
metadata:
  name: device-one-service
spec:
  selector:
    app: device-one
  ports:
  - protocol: TCP
    port: 1880
    targetPort: 1880
```

## Automatic Provisioning

Using a FlowFuse Provisioning Token to automatically configure a new Device Agent on deployment.

Because the Device Agent will need to re-write the `device.yml` file it can no longer be stored in a Secret and a PersistentVolume must be used for each instance of the Device Agent.

A Secret is used to hold the initial `device.yml` which contains the provisioning token.

```bash
kubectl create secret generic device-provisioning-secret --from-file=device.yml=./device.yml
```

The following manifest will create a Deployment, Service and PVC for a device using the supplied Secret as the source of the Provisioning token.

The PVC will be used to store the updated `device.yml` and the Node-RED nodes installed by the Remote Instance.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: device-one
  labels:
    app: device-one
spec:
  replicas: 1 # to scale to more than one instance you should modify this to use a StatefulSet
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: device-one
  template:
    metadata:
      labels:
        app: device-one
    spec:
      initContainers: # on first run copies the device.yml from Secret to PVC volume
      - name: config-copy
        image: busybox:latest
        command: 
        - "/bin/sh"
        - "-c"
        - "if [ ! -f /opt/flowfuse-device/device.yml ]; then cp /tmp/device.yml /opt/flowfuse-device/device.yml; fi"
        volumeMounts:
        - name: config
          mountPath: "/opt/flowfuse-device"
        - name: initial-config
          mountPath: "/tmp/device.yml"
          subPath: "device.yml"
          readOnly: true
      containers:
      - name: device-one
        image: flowfuse/device-agent:latest
        ports:
        - containerPort: 1880
        volumeMounts:
        - name: config
          mountPath: "/opt/flowfuse-device"
        resources:
          limits:
            cpu: 1000m
            memory: 256Mi
          requests:
            cpu: 500m
            memory: 128Mi
      volumes:
      - name: initial-config
        secret:
          secretName: device-provisioning-secret
      - name: config
        persistentVolumeClaim:
          claimName: device-one-pvc
        
---
apiVersion: v1
kind: Service
metadata:
  name: device-one-service
spec:
  selector:
    app: device-one
  ports:
  - protocol: TCP
    port: 1880
    targetPort: 1880
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: device-one-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
```


# Manual Install (NPM)

Use this method if you want direct control over the Node.js runtime and filesystem.

## Prerequisites

- Node.js 18 or later installed (Node.js 22 recommended; supported versions are 18, 20, 22, and 24). Node.js 20 reached end-of-life in April 2026.
- Linux, macOS, or Windows
- Outbound network access to FlowFuse platform and the NPM registry

### Networking requirements

Please see [Networking requirements](https://flowfuse.com/docs/device-agent/install/overview#networking-requirements).

## Install the Device Agent

The Device Agent is published to npm as [@flowfuse/device-agent](https://www.npmjs.com/package/@flowfuse/device-agent){rel="&#x22;nofollow&#x22;"}.

### Linux/macOS

```bash
sudo npm install -g @flowfuse/device-agent
```

### Windows (run elevated[1](https://flowfuse.com/#user-content-fn-1){#user-content-fnref-1 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""})

```bash
npm install -g @flowfuse/device-agent
```

## Working directory

By default the agent uses `/opt/flowfuse-device` (Linux/macOS) or `c:\opt\flowfuse-device` (Windows) as its working directory. Override with `-d/--dir` if needed.

Ensure the directory exists and is writable by the service user.

### Linux/macOS

```bash
sudo mkdir -p /opt/flowfuse-device
sudo chown -R $USER /opt/flowfuse-device
```

### Windows (run elevated[1](https://flowfuse.com/#user-content-fn-1){#user-content-fnref-1-2 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""})

```bash
mkdir c:\opt\flowfuse-device
icacls c:\opt\flowfuse-device /grant "user":F /T
```

Where "user" is the service account that will run the device agent (ideally, not an admin account).

## Configuration

Place a `device.yml` in the working directory. See [Register your Remote Instance](https://flowfuse.com/docs/device-agent/register) for obtaining the configuration via Quick Connect or provisioning.

## Listen Port

Node-RED listens on port `1880` by default. Change with `-p/--port`:

```bash
flowfuse-device-agent --port 1881
```

## Start on system boot

Use the provided systemd service file on Linux to run the agent as a service.

1. Download the service file:

```bash
curl -L https://raw.githubusercontent.com/FlowFuse/device-agent/main/service/flowfuse-device.service -o flowfuse-device.service
```

2. Adjust `User`, `Group`, and `WorkingDirectory` if needed.
3. Update `ExecStart` to include a custom port if required.
4. Move the file into place and enable the service:

```bash
sudo mv flowfuse-device.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable flowfuse-device
sudo systemctl start flowfuse-device
```

On Windows or macOS, consider using the [Installer](https://flowfuse.com/docs/device-agent/install/device-agent-installer) to set up services automatically.

## Verify

Start the agent from a terminal to confirm it runs:

```bash
flowfuse-device-agent -v
```

Once assigned, access the Node-RED editor at `http://<device-ip>:1880`.

## Upgrading the agent

With Device Agent 1.13+, the package moved from the `@flowforge` scope to `@flowfuse`:

- npm: `@flowforge/flowforge-device-agent` ➜ `@flowfuse/device-agent`

### Linux/macOS

```bash
sudo npm install -g @flowfuse/device-agent@latest
```

### Windows (run elevated[1](https://flowfuse.com/#user-content-fn-1){#user-content-fnref-1-3 ariaDescribedBy="&#x22;footnote-label&#x22;" dataFootnoteRef=""})

```bash
npm install -g @flowfuse/device-agent@latest
```

If you must stay on 2.x, use `@2.x`. Device Agent 3.x requires Node.js 18+. Device Agent 4.x defaults to Node.js 22 and supports Node.js 18, 20, 22, and 24.

## Footnotes

1. Run `powershell -Command "Start-Process 'cmd' -Verb RunAs"` to launch an elevated command prompt (e.g. as an admin user) [↩](https://flowfuse.com/#user-content-fnref-1){.data-footnote-backref ariaLabel="Back to reference 1" dataFootnoteBackref=""} [↩2](https://flowfuse.com/#user-content-fnref-1-2){.data-footnote-backref ariaLabel="Back to reference 1-2" dataFootnoteBackref=""} [↩3](https://flowfuse.com/#user-content-fnref-1-3){.data-footnote-backref ariaLabel="Back to reference 1-3" dataFootnoteBackref=""}


# Installing Device Agent

## Choose your install path

**Recommended for most users:** Use the Device Agent Installer (Quick Start), the fastest way to deploy with minimal configuration. Power users can choose Manual (using `npm`), Docker, or Kubernetes deployments.

### Quick install

Run the one-line installer on your device. It installs Node.js, registers the device on your FlowFuse platform, and configures it to run as a local service.

**Linux / macOS**

```bash
/bin/bash -c "$(curl -fsSL https://flowfuse.github.io/device-agent/get.sh)" && ./flowfuse-device-agent-installer
```

**Windows** — run in an elevated PowerShell terminal:

```powershell
Set-Location $env:USERPROFILE; powershell -c "irm https://flowfuse.github.io/device-agent/get.ps1 | iex"; .\flowfuse-device-agent-installer.exe
```

See the [Quick Start guide](https://flowfuse.com/docs/device-agent/quickstart) for the full walkthrough, or the [Installer reference](https://flowfuse.com/docs/device-agent/install/device-agent-installer) for all options and service management.

- Recommended: Use the Device Agent Installer
  - Fastest way to get started with a one-line command in the [Quick Start guide](https://flowfuse.com/docs/device-agent/quickstart)
  - Full options and service management in the [Installer reference](https://flowfuse.com/docs/device-agent/install/device-agent-installer)
- Alternative: Manual install (using `npm`)
  - Install the npm package, set working directory, configure, and run as a service. See [Manual install](https://flowfuse.com/docs/device-agent/install/manual)
- Alternative: Docker / Docker Compose
  - Run the agent in a container; bind-mount the configuration. See [Docker install](https://flowfuse.com/docs/device-agent/install/docker)
- Alternative: Kubernetes
  - Deploy the agent in a Kubernetes cluster. See [Kubernetes install](https://flowfuse.com/docs/device-agent/install/kubernetes)

## Prerequisites

- Node.js 18 or later (for Manual install and for running locally). Supported versions are 18, 20, 22, and 24. Device Agent v4 (and its installer and official Docker image) defaults to Node.js 22 — this is the recommended runtime. Note that Node.js 20 reached end-of-life in April 2026.
- Supported OS: Linux, macOS, Windows, or Docker container
- Networking: allow outbound access on 443 to:
  - `app.flowfuse.com`
  - `mqtt.flowfuse.cloud`
- Access to npm registry when snapshots are installed: <https://registry.npmjs.com>{rel="&#x22;nofollow&#x22;"}

Note: The Device Agent downloads the required Node-RED version and any nodes specified by the assigned snapshot. Ensure firewall/proxy permits access to the npm registry or see [Running with no access to npmjs.org](https://flowfuse.com/docs/device-agent/running#running-with-no-access-to-npmjsorg).

### Networking requirements

If you're working behind a firewall, and need to configure it to allow the Device Agent to connect to FlowFuse and the npm registry, see the following:

Allow outbound TCP 443 to:

- `app.flowfuse.com`
- `mqtt.flowfuse.cloud`
- `registry.flowfuse.cloud`
- `registry.flowfuse.com`

Ensure access to npm registry to download Node-RED and nodes:

- `https://registry.npmjs.com`

For offline environments, see [Running with no access to npmjs.org](https://flowfuse.com/docs/device-agent/running#running-with-no-access-to-npmjsorg).

## Verify the installation

After installing by any method:

1. Ensure a working directory exists (default is `/opt/flowfuse-device` or `c:\opt\flowfuse-device`).
2. Run the agent and it will help you get it registered, or provide a device configuration you have already created (via Quick Connect, provisioning, or manual `device.yml`). See [Register your Remote Instance](https://flowfuse.com/docs/device-agent/register).
3. Start the agent (service or CLI) and open `http://<device-ip>:1880` when assigned and running.

## What’s next

- Follow the [Quick Start guide](https://flowfuse.com/docs/device-agent/quickstart) to add and connect a Remote Instance
- Learn [how to run and configure the agent](https://flowfuse.com/docs/device-agent/running)
- Use [DevOps Pipelines](https://flowfuse.com/docs/user/devops-pipelines) to deploy flows


# FlowFuse Device Agent

![The installer running in a terminal, walking through sign-up and connection to FlowFuse](https://flowfuse.com/docs/device-agent/images/device-agent-install.gif){dataZoomable=""}

### Overview

FlowFuse Device Agent allows you to remotely manage Node-RED instances running on your hardware, for example, devices on your factory floor.

The Agent creates a secure connection between the FlowFuse Platform and your devices, enabling you to manage and deploy your applications.

### Get Started

You can install the Device Agent on any hardware capable of running Node.js / Node-RED.

The [Quick Start Guide](https://flowfuse.com/docs/device-agent/quickstart) will get the Device Agent installed and connected to FlowFuse in under 5 minutes.

For more detailed information on installing and running the Device Agent, the full [installation guide](https://flowfuse.com/docs/device-agent/install/overview) has you covered.


# Quick Start Guide: Device Agent

This guide will walk you through the process of adding a device to FlowFuse, connecting it to the platform, and deploying your Node-RED flows remotely. FlowFuse's Device Agent helps unlock the power of your devices by allowing you to manage and deploy Node-RED flows running on those devices securely and remotely.

## Before you begin

You will need:

- A terminal or command prompt on the device you wish to install the Agent on
- A FlowFuse platform account; either on [FlowFuse Cloud](https://app.flowfuse.com){rel="&#x22;nofollow&#x22;"} or a self-hosted platform.

If you do not currently have a FlowFuse platform account, this guide will help you set up a trial account on FlowFuse Cloud.

## Step 1: Install the Device Agent

The Device Agent Installer is a one-line command that will:

- Install Node.js
- Get your device registered on a FlowFuse platform
- Configure it to run as a local service

It is the quickest way to get started.

If you already have Node.js v22+ installed, or need to customize the setup, check the [manual installation guide](https://flowfuse.com/docs/device-agent/install/manual).

##### Linux/MacOS

```bash
/bin/bash -c "$(curl -fsSL https://flowfuse.github.io/device-agent/get.sh)" && ./flowfuse-device-agent-installer
```

##### Windows

1. Open a powershell terminal with elevated permission:

```bash
# From Windows Run dialog or a terminal window, enter:
powershell -Command "Start-Process 'powershell' -Verb RunAs"
```

2. Run the following command in the elevated terminal to download and run the installer:

```bash
Set-Location $env:USERPROFILE; powershell -c "irm https://flowfuse.github.io/device-agent/get.ps1 | iex"; .\flowfuse-device-agent-installer.exe
```

::div{.ff-callout.ff-callout--note}
Note

  :::div{.ff-callout__content}
  The installer checks to see if port 1880 is available to use. If it isn't, it will let you know before exiting. This is typically because you already have Node-RED running locally. You can tell the installer to configure its Node-RED to use a different port using the `--port <port>` argument. Pick a different port, for example `1881` and re-run the above command with `--port 1881` added to the end.
  :::
::

::div{.ff-callout.ff-callout--note}
Note

  :::div{.ff-callout__content}
  By default, the installer will use `/opt/flowfuse-device` (Linux/MacOS) or `c:\opt\flowfuse-device` (Windows) as the install location. To use a different location, use the `--dir` option with the install command. For example, `--dir /path/to/custom/location`.
  :::
::

## Step 2: Follow the installer prompts

The installer will step you through the whole setup process.

It will ask if you are registering a new instance or connecting with a One-Time Code (OTC).

##### Registering a new instance

Select this option if you have not yet registered the instance on your FlowFuse platform.

It will give you a URL to open in your browser where you can register the instance. Once you complete the registration, keep the browser tab open and switch back to the terminal.

##### Connecting with a One-Time Code

If you have already registered the instance on FlowFuse, the platform will have given you a One-Time Code to use when installing the Device Agent.

Enter the code when prompted and the Device Agent will connect.

## Step 3: Import existing flows

The Agent will check common locations for existing Node-RED flows. If it finds any, it will ask if you want to import those flows into your Device Agent managed Node-RED. This makes it easy to migrate an existing Node-RED setup into a fully managed FlowFuse instance. If you want to run an entirely separate instance, you can skip this step.

## Step 4: Set up a system service

The Installer will then setup a system service so the Device Agent automatically runs when the device restarts.

## Step 5: Start editing your flows

Once the Device Agent is running, and Node-RED has started, you can start editing your flows.

If you still have the browser window open from registering the device, it will automatically put the instance into 'Developer Mode' and open up the Node-RED editor.

From there you can start building your applications.

## Deploy Flows to Remote Instances

There are two approaches to deploying flows to your Remote Instances.

- **Developer Mode**: This mode allows you to edit and deploy flows directly from the FlowFuse platform.
- **DevOps Pipelines**: FlowFuse provides [DevOps Pipelines](https://flowfuse.com/docs/user/devops-pipelines) as a way of pushing flows from one Hosted Instance/Remote Instance to another (or several in the case of [Device Groups](https://flowfuse.com/docs/user/device-groups)). This is the recommended approach if you're pushing from development environments (e.g. remote test instances) out to remote production instances.

### Developer Mode

1. Navigate to **Applications** and select the application your device was added to.
2. Go to the **Remote Instances** tab within the application.
3. Locate your newly added device and **click** on your Remote Instance.
4. Then Click **Developer Mode** toggle button on upper right. :br![The "Developer Mode" toggle button available on the Device screen](https://flowfuse.com/docs/device-agent/images/developer.png){dataZoomable=""}*The "Developer Mode" toggle button available on the Device screen*
5. This will enable editor access for your device. :br![The "Device Editor" button available on the Device screen](https://flowfuse.com/docs/device-agent/images/editorEnabled.png){dataZoomable=""}*The "Device Editor" button available on the Device screen*
6. Clicking **Device Editor** will launch the editor. :br![Screenshot of a Node-RED Editor for a Device](https://flowfuse.com/docs/device-agent/images/nr_editor.png){dataZoomable=""}*Screenshot of a Node-RED Editor for a Device*

### DevOps Pipelines

![Screenshot showing the user interface for creating and running DevOps Pipelines in FlowFuse](https://flowfuse.com/docs/device-agent/images/ui-devops-pipelines.png){width="750"}{data-zoomable}
*Screenshot showing the user interface for creating and running DevOps Pipelines in FlowFuse*

To work with Pipelines, you need at least one other Hosted Instance or Remote Device to push *from*/*to*. You can follow the instructions on setting up a Pipeline and deploying your flows between Hosted Instances/Remote Instances [DevOps Pipelines](https://flowfuse.com/docs/user/devops-pipelines).

## Next Steps

Now you have a device connected to the platform, there are many features you can use to manage and monitor your Remote Instances.
Here are a few to get you started:

- [Snapshots](https://flowfuse.com/docs/user/snapshots)
- [Pipelines](https://flowfuse.com/docs/user/devops-pipelines)
- [Environment Variables](https://flowfuse.com/docs/user/envvar)
- [Logs](https://flowfuse.com/docs/user/logs)


# Register your Remote Instance

To connect your hardware to FlowFuse, you will need to:

1. Install the Device Agent on your hardware
2. Add a "Remote Instance" to FlowFuse, via the FlowFuse UI
3. Connect your hardware to FlowFuse by configuring the Device Agent

The best configuration to use will depend on how many Remote Instances you want to connect:

- **[Single Instance Registration](https://flowfuse.com/#single-remote-instance-registration)**: for connecting a single Remote Instance, or a small number of Remote Instances, to the platform.
- **[Bulk Registration](https://flowfuse.com/#bulk-registration)**: for setting up one or more Remote Instances which will automatically register themselves to the platform when the device agent is run.

## Single Remote Instance Registration

For a single Remote Instance, or small batch of Remote Instances, you can manually register each Remote Instance individually, naming each Remote Instance and assigning it to an application.

### Add Remote Instance

1. Go to your team's **Remote Instances** page.
2. Click the **Add Remote Instance** button.
3. You will be prompted to give the Remote Instance a **Name**, an optional **Type** and to choose which **Application**, if any, the Instance should be assigned to.
   - ![](https://flowfuse.com/docs/device-agent/images/add_remote_instance.png){width="500"}
   - The **Type** field can be used to record additional meta information about the Remote Instance.
   - If you do not wish to assign the Remote Instance to an **Application** at this time, you can do so later.
4. Click **Add**

### Connect Hardware to FlowFuse

Once the Remote Instance has been added in the FlowFuse UI, you will be shown the **Device Agent Configuration** dialog which
contains all the information needed to connect your hardware to the FlowFuse platform.

#### Quick Connect

By default, you are offered the [Setup command](https://flowfuse.com/#quick-connect) method that was introduced in FlowFuse V2.1, and provides a one-time passcode to automatically connect the hardware to FlowFuse.

![](https://flowfuse.com/docs/device-agent/images/config_yml1.png){width="500px"}

Running this command on hardware with the Device Agent installed will automatically configure it and connect it to FlowFuse.

#### Manual Setup

For older versions of the device agent, you can expand the **Manual Setup** section
and use the configuration data with the [Device Agent Web UI](https://flowfuse.com/#device-agent-web-ui) or the [Manual Download](https://flowfuse.com/#manual-download) methods instead.

Repeat these steps for each Remote Instance you want to connect to the platform.

## Bulk Registration

If you have dozens, or hundreds of pieces of hardware to connect, you can use the **Device Provisioning Configuration** method.

This approach provides you with a single "Provisioning Token" for all of your Remote Instances. When passed to the `flowfuse-device-agent`, this token will automatically register your Remote Instances with the relevant instance or application. There is no need to "Add Remote Instance" each time, as is the case with the [Single Device Registration](https://flowfuse.com/#single-remote-instance-registration) method.

### Generating a "Device Provisioning Configuration"

1. Go to your **Team Settings** page.
2. Open the **Provisioning** tab.
3. Click the **Add Token** button.
4. Enter a value for **Token Name**
5. Optionally, choose whether the device should Auto Assign to an **Instance**, an **Application**, or be left unassigned.
   - Select an **Instance** if you want the device to be automatically assigned to an instance.
   - Select an **Application** if you want the device to be automatically assigned to an application.
6. Click **Create**

![Screenshot of a FlowFuse Remote Instance Provisioning Token](https://flowfuse.com/docs/device-agent/images/create-provisioning-token.png){dataZoomable=""}

Once the Provisioning Token has been created, you will be shown the
**Device Provisioning Configuration** dialog:

![Screenshot of a FlowFuse Remote Instance Provisioning Token](https://flowfuse.com/docs/device-agent/images/provisioning-token.png){dataZoomable=""}

**IMPORTANT:** This is the only time the platform will show you
this information. Make sure to take a copy or use the **Download**
button to save the configuration file locally.

Once the token is created, it will be shown in the list of tokens on the **Provisioning** tab.
![Screenshot of FlowFuse Remote Instance Provisioning Tokens](https://flowfuse.com/docs/device-agent/images/provisioning-tokens.png){dataZoomable=""}

## Connecting your Hardware

### Install the configuration

The Device Agent requires information about the FlowFuse Platform, and how to connect. This comes in the form of a **Device Configuration** file or a **Device Provisioning Configuration**
file present in its working directory

There are three methods by which you can get this configuration onto your hardware:

- **[Quick Connect](https://flowfuse.com/#quick-connect):** Copy the Setup Command (with one-time passcode) and run it in a terminal window on the hardware. Your hardware will then automatically configure itself.
- **[Device Agent Web UI](https://flowfuse.com/#device-agent-web-ui):** Copy the configuration file (`device.yml`) to your hardware using its built in Web UI.
  - *The Device Agent must be running and the [command line flag](https://flowfuse.com/docs/device-agent/running#device-agent-command-line-options) for the Web UI must be enabled.*
- **[Manual Download](https://flowfuse.com/#manual-download):** Download the configuration file directly into the hardware's [Working Directory](https://flowfuse.com/docs/device-agent/install/manual#working-directory).

### Methods

#### Quick Connect

The Quick Connect method was introduced in FlowFuse v2.1. This is the fastest way to connect your hardware to the platform.

When registering your hardware you would have been presented the following dialog, with a one-time-passcode that the Device Agent can use to retrieve its configuration:

![](https://flowfuse.com/docs/device-agent/images/config_yml1.png){style="margin: auto;" width="500px"}

If you're no longer able to see that dialog, you can regenerate the configuration by following the [Regenerating Configurations](https://flowfuse.com/#regenerating-configurations&#x29; steps, or clicking &#x2A;*"Finish Setup"** on the Remote Instance's page:

![](https://flowfuse.com/docs/device-agent/images/finish-setup.png){style="margin: auto; margin-bottom: 12px;" width="750px"}

When the quick connect command has been run, the terminal window will report that the Remote Instance has connected to the platform and
will output a new `command` for you to use to start the Remote Instance agent with the new configuration.

NOTES

- The Setup command is only valid for 24h. If you do not use it within this time, you will need to [regenerate](https://flowfuse.com/#regenerating-configurations) it.
- The 3 word One-Time-Code (OTC) contained in the Setup command is single use and is deleted immediately upon use.

#### Device Agent Web UI

![](https://flowfuse.com/docs/device-agent/images/device_gui.png){style="margin: auto; margin-bottom: 12px;" width="550px"}

If the Device Agent is running [with the Web UI enabled](https://flowfuse.com/docs/device-agent/running#device-agent-command-line-options), you can download the
configuration file to the Remote Instance using the Web UI. This is useful if you don't
have direct access to the Remote Instance's file system. Once the configuration file is
downloaded, the device agent will automatically restart and load the configuration.

#### Manual Download

Place the **Device Configuration** or **Device Provisioning Configuration** file onto your hardware.
in the [Working Directory](https://flowfuse.com/docs/device-agent/install/manual#working-directory)

By default, the device agent expects the configuration file to be named `device.yml`, if not, you will need to start the device agent with the `-c` [Command Line Option](https://flowfuse.com/docs/device-agent/running#device-agent-command-line-options) and specify the path of the configuration file.

The agent can then be started with the command: [^global-install]

```bash
flowfuse-device-agent
```

You will see the Device Agent start and perform a 'call-home' where it connects back
to the platform to check what it should be running.

#### Additional Information

If you copy or download a **Device Provisioning Configuration** file to your hardware,
you will see the Device Agent start and perform a 'call-home' where it connects back
to the platform to auto register itself in the Team's Remote Instances. If successful,
the real **Device Configuration** is generated and downloaded to the device.
The original **Provisioning Configuration** will be overwritten meaning subsequent
runs will not need to perform the auto registration again.

## Assign the Remote Instance

The next step is to assign the device to a Node-RED instance or application. Note, that if
you've followed [Single Device Registration](https://flowfuse.com/#single-remote-instance-registration) or
[Bulk Registration](https://flowfuse.com/#bulk-registration) to register your device, it will
automatically be assigned to an Application or Instance.

### Applications

This step will permit you to push Snapshots to your Remote Instance via [DevOps Pipelines](https://flowfuse.com/docs/user/devops-pipelines), or via a [Target Snapshot](https://flowfuse.com/docs/user/snapshots/#application-owned-devices) from the Application.

#### Assign to Application

1. Go to your team's **Remote Instances** page.
2. Open the dropdown menu to the right of the Remote Instance you want to assign and
   select the **Add to Application** option.
3. Select the application in the dialog and click **Add** to continue.

#### Remove from Application

To remove the Remote Instance from an application:

1. Go to your team's **Remote Instances** page.
2. Open the dropdown menu to the right of the Remote Instance you want to remove and
   select the **Remove from Application** option.
3. Confirm the action by clicking the **Remove** option.

The Remote Instance will stop running the current Node-RED flows. It will then wait
until it is assigned to another application or instance.

#### Bulk Assigning Remote Instances to an Application

If you have a large number of Remote Instances to assign to an application, you can do them all at once:

1. Select the Remote Instances you want to assign and open the **Actions** dropdown menu.
2. Select the **Move to Application** option and then select the application or instance you want to assign the Remote Instances to.
3. Click **Move** to continue.

##### Details:

- Remote Instances that are already assigned to the chosen application will not be changed or updated.
- For any Remote Instance that is moved by the operation:
  - Remote Instances moved by the operation will have their target snapshot cleared, device group membership cleared and will be sent an update command.
  - Remote Instances in Fleet Mode will automatically apply the changes resulting in Remote Instances restarting with the basic starter snapshot flows.
  - Remote Instances in [Developer Mode](https://flowfuse.com/docs/device-agent/quickstart/#developer-mode) will continue to run their current flows until they are switched to fleet mode at which point they will update accordingly.

NOTE: If you wish to keep the flows currently running on the Remote Instance, it must be in developer mode at the time of operation. Once the Remote Instance is moved, create a new snapshot with the "Set as Target" option checked.

### Hosted Instances

This method establishes a deployment relationship where a Hosted Instance becomes the source for snapshot deployments to your Remote Instance(s).

**Important:** This is a legacy feature; [assigning to Applications](https://flowfuse.com/docs/device-agent/register#applications) is the recommended approach as it provides better fleet management and DevOps Pipeline capabilities. For guidance, see [when to use each approach](https://flowfuse.com/docs/user/concepts#when-to-use-instance-assignment-vs-devops-pipelines).

#### Assign to Hosted Instance

1. Go to your team's **Remote Instances** page.
2. Open the dropdown menu to the right of the Remote Instance you want to assign and select the **Add to Instance** option.
3. Select the Hosted Instance in the dialog and click **Add** to continue.

**Note:** There are constraints on which instances can be assigned to each other. For detailed information, refer to [Assignment Rules and Constraints](https://flowfuse.com/docs/user/concepts#assignment-rules).

### Remove from Hosted Instance

To remove the Remote Instance from a Node-RED instance:

1. Go to your team's **Remote Instances** page.
2. Open the dropdown menu to the right of the Remote Instance you want to remove and
   select the **Remove from Hosted Instance** option.
3. Confirm the action by clicking the **Remove** option.

The Remote Instance will stop running the current Node-RED flows. It will then wait
until it is assigned to another Hosted Instance or Application

### Bulk Assigning Remote Instances to a Hosted Instance

If you have a number of Remote Instances to assign to an instance, you can do them all at once.

1. Select the Remote Instances you want to assign and open the **Actions** dropdown menu adjacent to the **Add Remote Instance** button.
2. Select the **Move to Instance** option and then select the instance you want to assign the Remote Instances to.
3. Click **Move** to continue.

#### Details:

- Remote Instances that are already assigned to the chosen instance will not be changed or updated.
- For any Remote Instance that is moved by the operation:
  - If the chosen instance has a target snapshot set, the newly assigned Remote Instances will inherit this.
  - If the chosen instance does not have a target snapshot set, newly assigned Remote Instances will have their target snapshot cleared.
  - Remote Instances in fleet mode will automatically apply the changes.
  - Remote Instances in developer mode will continue to run their current flows until they are switched to fleet mode at which point they will update accordingly.

### Bulk Removing Remote Instances from an Application or Instance

If you have a number of Remote Instances to remove from an application or instance, you can do them all at once.

1. Select the Remote Instances you want to remove and open the **Actions** dropdown menu adjacent to the **Add Remote Instance** button.
2. Select the **Unassign**option.
   1. Depending on where you are viewing Remote Instances, this may say "Remove from Application" or "Remove from Instance".
3. Confirm the action by clicking **Unassign**.

#### Details:

- Remote Instances that are already unassigned will not be changed or updated.
- For any Remote Instance that was previously assigned to an application or instance:
  - Remote Instances in developer mode will be switched to fleet mode.
  - Remote Instances will have their target snapshot and Remote Instance group membership cleared.
  - Remote Instances will be informed of the changes resulting in their flows being cleared and the Remote Instance entering a stopped state waiting for a new assignment.

## Regenerating Configurations

To regenerate Remote Instance configurations:

1. Go to your team's or instance's **Remote Instances** page.
2. Open the dropdown menu to the right of the Remote Instance and select the
   **Regenerate Configuration** option.
3. You will need to confirm this action as the existing configuration will be
   immediately revoked. If the Remote Instance tries to use the old configuration it will
   fail to connect and will delete its local copy of the snapshot it was
   running. Click **Regenerate Configuration** to continue.

You will then be shown the **Remote Instance Configuration** dialog again with a new
setup command and the manual configuration to copy or download.

## Deleting a Remote Instance

To delete a Remote Instance:

1. Go to your team's or instance's **Remote Instances** page.
2. Open the dropdown menu to the right of the Remote Instance and select the
   **Delete Remote Instance** option.
3. Confirm the action by clicking the **Delete** option.

The next time the Remote Instance attempts to connect to the platform it will find it is
no longer authorised and will stop and delete its local copy of the flows it was running.

## Node-RED Settings

Most Node-RED settings are managed by the platform as part of deploying an instance
to the Remote Instance. However some settings can be overridden locally on the Remote Instance.

### HTTPS configuration

*Available in Device Agent 0.10+*

The `https` configuration option in `device.yml` can be used to enable HTTPS within Node-RED. The values
are passed through to the [Node-RED `https` setting](https://nodered.org/docs/user-guide/runtime/configuration){rel="&#x22;nofollow&#x22;"}.

The `ca`, `key` and `cert` properties can be used to provide custom certificates and keys.
The values should be set to the contents of the certificate/key.

Alternatively, the properties `caPath`, `keyPath` and `certPath` can be used instead
to provide absolute paths to files containing the certificates/keys.

```yml [device.yml]
https:
   keyPath: /opt/flowfuse-device/certs/key.pem
   certPath: /opt/flowfuse-device/certs/cert.pem
   caPath: /opt/flowfuse-device/certs/ca.pem
```

### `httpStatic` configuration

*Available in Device Agent 0.10+*

This option can be used to serve content from a local directory.

If set to a path, the files in that directory will be served relative to `/`.

```yml [device.yml]
httpStatic: /opt/flowfuse-device/static-content
```

It is also possible to configure it with a list of directories and the corresponding
path they should be served from.

```yml [device.yml]
httpStatic:
  - path: /opt/flowfuse-device/static-content/images
    root: /images
  - path: /opt/flowfuse-device/static-content/js
    root: /js
```

### `localAuth` configuration

*Available in Device Agent 3.20+*

This option can be used to enable local login for the Node-RED editor. This option is not recommended for day to day use.

It can be configured under the Remote Instance's Settings

![Local Auth settings for Remote Instance](https://flowfuse.com/docs/device-agent/images/device-local-access.png){dataZoomable=""}*Local Auth settings for Remote Instance*

Or by adding the following to the `device.yml` file

```yml [device.yml]
localAuth:
    enabled: true
    user: user-name
    pass: $hashed-password
```

NOTE: The password should be hashed version generated using the Node-RED admin CLI. For example:

```bash
node-red admin hash-pw
```

Alternatively, the password can be set in FlowFuse on the settings -> security tab of the Remote Instance.

## Troubleshooting

If you have problems with the device agent the first thing to do is to enable the verbose logging mode.

To do this add a `-v` to the command line. This will present a lot more information about what the agent is doing.
It will show that is has connected to the FlowFuse instance and every time it checks in, it will also log all the
local HTTP requests made when accessing the Node-RED Editor via the FlowFuse application.


# Running the Device Agent

## Running

If the agent was installed as a global npm module, the command `flowfuse-device-agent` will be on the path.

If the default working directory and config file are being used, then the agent can be started with:

```bash
flowfuse-device-agent
```

By default, Node-RED will listen to port `1880`, you can change it using the options
detailed [here](https://flowfuse.com/docs/device-agent/install/manual#listen-port).

This will start the agent, set the Remote Instance in the default of fleet mode, and connect to
FlowFuse, waiting until a Target Snapshot has been assigned to it, or it is assigned
to an Application.

### When assigned to an instance:

Once the agent has been assigned a Target Snapshot, it will download the Snapshot and
deploy it to the Remote Instance.

### When assigned to an application:

Once the agent has been assigned to an application it starts up. If the device is new,
it will get a default set of flows which can be edited directly.
See [Editing the Node-RED flows on a Remote Instance that is assigned to an application](https://flowfuse.com/docs/device-agent/deploy#editing-the-node-red-flows-on-a-remote-instance-that-is-assigned-to-an-application) for details.

### Device Agent Command Line Options

The following command line options are available:

```text
Options

  -c, --config file           Device configuration file. Default: device.yml
  -d, --dir dir               Where the agent should store its state. Default: /opt/flowfuse-device
  -i, --interval secs
  -p, --port number
  -m, --moduleCache           Use local npm module cache rather than install
  --node-options string       Node.js command-line options to pass to the Node-RED process. Can be specified multiple times. You must use `=` between the option and its value.

Web UI Options

  -w, --ui            Start the Web UI Server (optional, does not run by default)
  --ui-host string    Web UI server host. Default: (0.0.0.0) (listen on all interfaces)
  --ui-port number    Web UI server port. Default: 1879
  --ui-user string    Web UI username. Required if --ui is specified
  --ui-pass string    Web UI password. Required if --ui is specified
  --ui-runtime mins   Time the Web UI server is permitted to run. Default: 10

Setup command

  -o, --otc string    Setup device using a one time code
  --otc-no-start      Do not start the agent after setup
  --otc-no-import     Do not ask to import Node-RED flows during setup
  -u, --ff-url url    URL of FlowFuse. Required for setup

Global Options

  -h, --help          print out helpful usage information
  --version           print out version information
  -v, --verbose       turn on debugging output
  --log-format json   output logs in JSON format
```

### Command Line Examples

*Start the agent with a different port number*

```bash
flowfuse-device-agent -p 8080
```

*Start the agent with a different working directory and the Web UI enabled*

```bash
flowfuse-device-agent -d /path/to/working/directory -w --ui-user admin --ui-pass password --ui-port 8081
```

## Structured JSON logging

By default the Device Agent prints plain-text logs, which can be hard to parse with log aggregation tools. From Device Agent v4, you can output machine-readable, structured logs in JSON format using the `--log-format json` flag:

```bash
flowfuse-device-agent --log-format json
```

## Configuring Node.js Options

Node.js command-line arguments can be passed to the Node-RED process started by the Device Agent. This is useful for memory-intensive workflows or certificate management.

### Via command line

Use `--node-options` — it can be specified multiple times:

```bash
# Set a custom heap size limit
flowfuse-device-agent --node-options='--max-old-space-size=256'

# Enable system certificate authorities (Linux)
flowfuse-device-agent --node-options='--use-openssl-ca'

# Enable system certificate authorities (Windows/macOS)
flowfuse-device-agent --node-options='--use-system-ca'

# Combine multiple options
flowfuse-device-agent --node-options='--max-old-space-size=256' --node-options='--use-openssl-ca'
```

### Via `device.yml`

Add a `nodeOptions` array to the `device.yml` configuration file:

```yaml [device.yml]
nodeOptions:
  - "--max-old-space-size=256"
  - "--use-openssl-ca"
```

## Running behind a HTTP Proxy

If the Remote Instance is behind a HTTP proxy, the agent can be configured to use the proxy by setting the `http_proxy`, `https_proxy` or `all_proxy` environment variables.

If necessary, the `no_proxy` environment variable can be used to specify a list of hosts that should not be accessed via the proxy.

For connecting to FlowFuse Cloud, the `https_proxy` variable should be set to your proxy URL. This environment variable will be used by the agent for both the HTTP
and MQTT connections.

### Example setting the proxy environment variables on Linux

```bash
# Set the https_proxy environment variable
export https_proxy=http://my-proxy:3128
# Set the no_proxy environment variable to exclude local addresses and all hosts in the .mydomain.com domain
export no_proxy=localhost,127.0.0.1,.mydomain.com
# Start the agent
flowfuse-device-agent
```

*To make these settings permanent, see the documentation for your Linux distribution.*

### Example setting the proxy environment variables on Windows

```bash
# Set the https_proxy environment variable
set https_proxy=http://my-proxy:3128
# Set the no_proxy environment variable to exclude local addresses and all hosts in the .mydomain.com domain
set no_proxy=localhost,127.0.0.1,.mydomain.com
# Start the agent
flowfuse-device-agent
```

*To make these settings permanent, see the documentation for your version of Windows.*

## Running with no access to npmjs.org

By default, the Device Agent will try and download the correct version of Node-RED and
any nodes required to run the Snapshot that is assigned to run on the Remote Instance.

If the Remote Instance is being run on an offline network or security policies prevent the
Device Agent from connecting to npmjs.org then it can be configured to use a pre-cached
set of modules.

You can enable this mode by adding `-m` to the command line or adding `moduleCache: true`
to the `device.yml` file. This will cause the Device Agent to load the modules from the
`module_cache` directory in the Device Agent's [Working Directory](https://flowfuse.com/docs/device-agent/install/manual#working-directory) (or whatever is set
with the `-d` option) (e.g. `/opt/flowfuse-device/module_cache`.).

### Creating a module cache

To create a suitable module cache, the device must be assigned to a Remote Instance. You will need to
install the modules on a local device with access to npmjs.org, ensuring you use the same
OS and Architecture as your target device, and then copy the modules on to your Remote Instance.

1. From the Snapshot page, select the snapshot you want to deploy and select the option to download its `package.json` file.
2. Place this file in an empty directory on your local device.
3. Run `npm install` to install the modules. This will create a `node_modules` directory.
4. On your target Remote Instance, create a directory called `module_cache` inside the Device Agent Configuration directory.
5. Copy the `node_modules` directory from your local instance to the target instance so that it is under the `module_cache` directory.


# ctrlX Device Agent App

**Currently not available - will be available soon**

## Installation Procedure

1. In the ctrlX CORE web interface, navigate to the window **Settings** ➔ **Apps**.
2. Switch the ctrlX device to the **Service** mode.
3. In the app overview, navigate to the category **Available apps**. This category displays all apps saved in the app storage on the ctrlX device and all apps provided via the ctrlX Store.
4. Search for the FlowFuse Device Agent ctrlX App to be installed and click on the Installation button. If multiple app versions are provided for installation, a list of available versions and app sources will be displayed. In this case, select the desired app version from the list to start the installation. If only one app version is provided, the installation will start directly. After the installation, the app will be shown in the app overview, under the category **Installed apps**.
5. Switch the ctrlX device back to the **Operating** mode.

## Device Agent Configuration for ctrlX

1. After successful installation, [generate and download the "Device Credentials" in FlowFuse](https://flowfuse.com/docs/device-agent/register/#manual-setup)
2. In the ctrlX CORE web interface, navigate to the window **Settings** ➔ **Apps** ➔ **Manage App Data**
3. Select the folder "FlowFuse Device Agent"
4. Click on upload file and select the **device.yml** configuration from step 1
5. The Device Agent connects automatically to your FlowFuse instance. Ensure your ctrlX has a network connection to your FlowFuse platform (e.g. FlowFuse Cloud) and to the npmjs registry.


# ctrlX Node-RED App

Learn more about the Node-RED App in the [ctrlX World Store](https://developer.community.boschrexroth.com/t5/Store-and-How-to/FlowFuse-Node-RED/ba-p/82135){rel="&#x22;nofollow&#x22;"}

## Installation Procedure

Follow these steps to install the Rexroth CtrlX App by FlowFuse on your ctrlX device:

1. In the ctrlX CORE web interface, navigate to the window **Settings** ➔ **Apps**.
2. Switch the ctrlX device to the **Service** mode.
3. In the app overview, navigate to the category **Available apps**. This category displays all apps saved in the app storage on the ctrlX device and all apps provided via the ctrlX Store.
4. Search for the `Rexroth CtrlX App` to be installed and click on the Install button. If multiple app versions are provided for installation, a list of available versions and app sources will be displayed. In this case, select the desired app version from the list to start the installation. If only one app version is provided, the installation will start directly. After the installation, the app will be shown in the app overview, under the category **Installed apps**.
5. Switch the ctrlX device back to the **Operating** mode.

## Start and Login

1. Open the Flow Editor from the Node-RED menu in your ctrlX.
2. **Log in using your ctrlX username and password**.
3. A successful login requires a valid license and user permission.
4. Create your Node-RED flow.


# Device Agent - Hardware

The FlowFuse Device Agent can be installed on any Mac, Linux, or Windows-supported device. If you want to learn more about how to install the Device Agent in general, [click here](https://flowfuse.com/docs/device-agent/install/overview). Nevertheless, this overview provides a guide for specific hardware platforms.

## Official FlowFuse Hardware Partners

[![](https://upload.wikimedia.org/wikipedia/commons/0/0d/Logo_of_Bosch_Rexroth_AG.svg){height="75" width="150"}](https://developer.community.boschrexroth.com/t5/Store-and-How-to/FlowFuse-Node-RED/ba-p/82135)

- [ctrlX - Node-RED App](https://flowfuse.com/docs/hardware/ctrlx-node-red)
- [ctrlX - Device Agent App](https://flowfuse.com/docs/hardware/ctrlx-device-agent) - will be available soon

## Other Hardware Guides

[![](https://upload.wikimedia.org/wikipedia/de/c/cb/Raspberry_Pi_Logo.svg){height="30" width="80"}](https://flowfuse.com/docs/hardware/raspbian)

- [Raspberry Pi](https://flowfuse.com/docs/hardware/raspbian)


# Raspberry Pi

The Raspberry Pi section provides instructions for installing and setting up the FlowFuse Device Agent on your Raspberry Pi device, enabling seamless integration for efficient device management and automation.

## Installing the Device Agent

FlowFuse provides a script to install Node.JS, npm, and the FlowFuse Device Agent onto a Raspberry Pi.
This script won't work on ARMv6 builds as the standard Node.JS builds don't support it, as result Pi Zero's are not supported.

```sh
bash <(curl -sL https://raw.githubusercontent.com/FlowFuse/device-agent/main/service/raspbian-install-device-agent.sh)
```

**This script will:**

1. Detect if Node.js is already installed, it will ensure it is at least v14. If less than v14 it will stop. If nothing is found it will install the Node.js 18 LTS release
2. Install the latest version of the FlowFuse Device Agent using npm.
3. Setup the FlowFuse Device Agent to run as a service

## Running as a service

You can run the device agent as a service, which means it can run in the background and be enabled to automatically start on boot. The install script will automatically set up the FlowFuse Device Agent to run as a service. The following commands can be useful for controlling the service or changing the default service settings.

### Starting the service on boot (optional)

If you want Node-RED to run when the device is turned on, or re-booted, you can enable the service to autostart by running the command:

`sudo systemctl enable flowfuse-device-agent.service`

To disable the service, run the command:

`sudo systemctl disable flowfuse-device-agent.service`

### Controlling the service

You can start the service with the command:

`sudo systemctl start flowfuse-device-agent`

You can check the current status with the command:

`sudo systemctl status flowfuse-device-agent`

You can stop your with the command:

`sudo systemctl stop flowfuse-device-agent`


# FlowFuse Documentation

Welcome to the documentation for FlowFuse, an open-source, industrial data platform that enables engineers to build, manage, scale, and secure their Node-RED solutions.

It covers everything from setup, to usage, and development. All [contributions](https://flowfuse.com/docs/contribute/introduction/) are welcome.

## Getting Started

::div{.ff-offering-tiles.grid-cols-1.sm:grid-cols-2}
  :::div{.ff-tile.ff-offering-tile}
  FlowFuse Self-Hosted


  Run FlowFuse yourself on your own infrastructure.

  - [Quick Start Instructions
    :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/quick-start/)
  - [Install FlowFuse Self-Hosted
    :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/install/introduction/)
  - [Upgrade Your FlowFuse Instance
    :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/upgrade)
  - [Unlock Enterprise Features
    :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/upgrade/open-source-to-premium/)
  - [Administering FlowFuse
    :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/admin/introduction/)
  :::

  :::div{.ff-tile.ff-offering-tile}
  FlowFuse Cloud


  Hosted solution, nothing to install anything, jump straight in.

  - [Sign Up for Free :icon-chevron-right{.ff-icon.ff-icon-sm}](https://app.flowfuse.com/account/create)
  - [Upgrading Teams :icon-chevron-right{.ff-icon.ff-icon-sm}]()
  - [Billing :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/cloud/billing/)
  - [Single Sign On :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/cloud/introduction/#single-sign-on)
  :::
::

## Using FlowFuse

### Getting Started

Here are some quick reference links to our most popular topics. You can also view the full documentation available for FlowFuse in our [Getting Started](https://flowfuse.com/docs/user/introduction/){rel="&#x22;nofollow&#x22;"} guide.

::div{.ff-product-feature-tiles.grid-cols-1.md:grid-cols-2}
  :::div{.ff-product-feature-tile-decorator}
  [](https://flowfuse.com/docs/user/instance-settings/){.ff-tile.ff-product-feature-tile}
  :::

  :::div
  [Configuring Instances
  [Understand the options available for your Node-RED Instances]](https://flowfuse.com/docs/user/instance-settings/){.ff-tile.ff-product-feature-tile}
  :::

  :::div{.ff-product-feature-tile-decorator}
  [](https://flowfuse.com/docs/user/snapshots/){.ff-tile.ff-product-feature-tile}
  :::

  :::div
  [Snapshots
  [Version Control for your Node-RED Instances.]](https://flowfuse.com/docs/user/snapshots/){.ff-tile.ff-product-feature-tile}
  :::

  :::div{.ff-product-feature-tile-decorator}
  [](https://flowfuse.com/docs/user/shared-library/){.ff-tile.ff-product-feature-tile}
  :::

  :::div
  [Team Library
  [Centralized management of re-usable flows and functions.]](https://flowfuse.com/docs/user/shared-library/){.ff-tile.ff-product-feature-tile}
  :::

  :::div{.ff-product-feature-tile-decorator}
  [](https://flowfuse.com/docs/user/snapshots/){.ff-tile.ff-product-feature-tile}
  :::

  :::div
  [Pipelines
  [Deploy flows between Test, Staging & Production Environments.]](https://flowfuse.com/docs/user/snapshots/){.ff-tile.ff-product-feature-tile}
  :::

  :::div{.ff-product-feature-tile-decorator}
  [](https://flowfuse.com/docs/user/device-groups/){.ff-tile.ff-product-feature-tile}
  :::

  :::div
  [Remote Instances
  [Deploy flows remotely with FlowFuse "Devices".]](https://flowfuse.com/docs/user/device-groups/){.ff-tile.ff-product-feature-tile}
  :::

  :::div{.ff-product-feature-tile-decorator}
  [](https://flowfuse.com/docs/user/device-groups/){.ff-tile.ff-product-feature-tile}
  :::

  :::div
  [Device Groups
  [Manage large numbers of devices together.]](https://flowfuse.com/docs/user/device-groups/){.ff-tile.ff-product-feature-tile}
  :::
::

### Advanced Features

Once you're more comfortable with FlowFuse, you may want to explore some of our more advanced features that will help elevate your Node-RED experience even further.

::div{.ff-product-feature-tiles.grid-cols-1.md:grid-cols-2}
  :::div{.ff-product-feature-tile-decorator}
  [](https://flowfuse.com/docs/user/team/){.ff-tile.ff-product-feature-tile}
  :::

  :::div
  [Managing Teams
  [Host your Instances at a custom subdomain]](https://flowfuse.com/docs/user/team/){.ff-tile.ff-product-feature-tile}
  :::

  :::div{.ff-product-feature-tile-decorator}
  [](https://flowfuse.com/docs/user/custom-hostnames/){.ff-tile.ff-product-feature-tile}
  :::

  :::div
  [Custom Domains
  [Host your Instances at a custom subdomain]](https://flowfuse.com/docs/user/custom-hostnames/){.ff-tile.ff-product-feature-tile}
  :::

  :::div{.ff-product-feature-tile-decorator}
  [](https://flowfuse.com/docs/user/device-groups/){.ff-tile.ff-product-feature-tile}
  :::

  :::div
  [High Availability
  [Automatically distribute workload across multiple copies of your Node-RED Instance.]](https://flowfuse.com/docs/user/device-groups/){.ff-tile.ff-product-feature-tile}
  :::
::

## FlowFuse Extras

::div{.ff-offering-tiles.grid-cols-1.sm:grid-cols-2.lg:grid-cols-2}
  :::div{.ff-tile.ff-offering-tile}
  FlowFuse Node-RED Nodes


  A complete set of FlowFuse-maintained nodes for data sharing between instances, MQTT messaging, AI/ONNX models, MCP agent integrations, and enterprise data features.

  - [FlowFuse Project Nodes :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/user/projectnodes/)
  - [FlowFuse MCP Nodes :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/node-red/flowfuse/mcp/)
  - [FlowFuse Tables Nodes :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/node-red/flowfuse/flowfuse-tables/)
  - [FlowFuse AI Nodes :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/node-red/flowfuse/ai/)
  - [FlowFuse MQTT Nodes :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/user/mqtt-nodes/)
  - [See all the Nodes :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/node-red/flowfuse/)
  :::

  :::div{.ff-tile.ff-offering-tile}
  FlowFuse Dashboard


  Create interactive, responsive and secure Dashboards in Node-RED.

  - [Install FlowFuse Dashboard :icon-chevron-right{.ff-icon.ff-icon-sm}](https://dashboard.flowfuse.com)
  - [Build Your First Dashboard :icon-chevron-right{.ff-icon.ff-icon-sm}](https://dashboard.flowfuse.com)
  - [Multi Tenant Dashboards :icon-chevron-right{.ff-icon.ff-icon-sm}](https://dashboard.flowfuse.com/user/multi-tenancy.html)
  :::

  :::div{.ff-tile.ff-offering-tile}
  FlowFuse Device Agent


  Manage thousands of Node-RED Instances remotely with the FlowFuse Device Agent.

  - [Install the Device Agent :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/device-agent/install/)
  - [Registering Devices in FlowFuse :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/device-agent/register/)
  - [Deploying Flows to your Device :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/device-agent/deploy/)
  - [Editing Flows on your Device :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/device-agent/deploy/)
  :::

  :::div{.ff-tile.ff-offering-tile}
  FlowFuse Assistant


  AI in the Node-RED Editor to help build your flows.

  - [Getting Started Guide :icon-chevron-right{.ff-icon.ff-icon-sm}](https://flowfuse.com/docs/user/expert/)
  :::
::

## Support

- [Troubleshooting](https://flowfuse.com/docs/debugging/)
- [FlowFuse Cloud Support](https://flowfuse.com/docs/premium-support/)

## Contributing to FlowFuse

- [Useful Information](https://flowfuse.com/docs/contribute/introduction#contributing-to-flowfuse) - Learn the foundational concepts of how FlowFuse is built & structured.
- [Development Setup](https://flowfuse.com/docs/contribute/introduction#development-setup) - Configure your local development environment to contribute to FlowFuse.
- [Testing](https://flowfuse.com/docs/contribute/introduction#testing) - Understand our testing philosophy at FlowFuse.


# Configuring FlowFuse

The base configuration of the FlowFuse platform is provided in the file
`/opt/flowforge/etc/flowforge.yml`. This assumes the default install location
of `/opt/flowforge`.

To run a local install, you can use the default options. This section describes
the options available in the configuration file.

## Server configuration

| Option                      | Description                                                                                                                                                                                                                                                                                                                                                            |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `host`                      | The address to serve the web ui on. This defaults to `localhost` which means the ui will only be available when browsing from the same server that is running the platform. To make it accessible to other devices on the network, set it to `0.0.0.0`. :br NOTE: If `host` is changed, please also update `base_url` to match e.g. `http://[ip-address-of-host]:3000` |
| `port`                      | The TCP port the platform serves its web ui. Default: `3000`                                                                                                                                                                                                                                                                                                           |
| `base_url`                  | The url to access the platform. This defaults to `http://localhost:3000` which means a number of internally generated URLs will only work when browsing on the same device as is running the platform. To be able to access the platform remotely, replace `localhost` with the ip address of the device running FlowFuse.                                             |
| `domain`                    | The domain that instance names will be prepended to on Docker & Kubernetes platforms to create a hostname to access the instance. A wildcard DNS A record should point be configured to point to the FlowFuse entry IP Address.                                                                                                                                        |
| `support_contact`           | a URL or string with contact details for the administrator e.g `mailto:support@example.com` or `https://support.example.com` . Defaults to the email address of the first admin user or `the administrator` if no email address set.                                                                                                                                   |
| `create_admin`              | If set to `true` will create a default admin user on first run, the username/password is written to the logs. Default: `false`                                                                                                                                                                                                                                         |
| `create_admin_access_token` | If set to `true` an access token (ffpat) is created for the default admin user on first run. Its value is written to the logs. Default: `false`                                                                                                                                                                                                                        |
| `license`                   | Can be used to pass in a license key for FlowFuse. Default not set                                                                                                                                                                                                                                                                                                     |

NOTE: Changing the `base_url` and `domain` after Node-RED instances have been created is possible, but the original hostname and domain must remain active in order to access the instances and for an them to be able to access the FlowFuse resources.

An example workflow would be:

1. Register new domain
2. Set up DNS entries for:
   - A record for the forge app
   - wildcard A record for the domain
3. Leave the existing entries for the old domain in place
4. Stop the forge app
5. Edit the flowforge.yml to set the base\_url and domain entries
6. Restart the forge app

## Database configuration

FlowFuse supports `sqlite` and `postgres` databases.

| Option    | Description                                     |
| --------- | ----------------------------------------------- |
| `db.type` | The type of database to use. Default: `sqlite`. |

### SQLite configuration

| Option       | Description                                                                                      |
| ------------ | ------------------------------------------------------------------------------------------------ |
| `db.storage` | Path to the SQLite Database file to use, relative to `/opt/flowforge/var/`. Default: `forge.db`. |

### Postgres configuration

| Option        | Description                                             |
| ------------- | ------------------------------------------------------- |
| `db.host`     | Hostname of the Postgres Database. Default: `postgres`. |
| `db.database` | Database name on Postgres Server. Default: `flowforge`. |
| `db.user`     | Username used when connecting to Postgres Server.       |
| `db.password` | Password used when connecting to Postgres Server.       |
| `db.ssl`      | Client should connect with SSL/TLS. Default: `false`    |

## Node-RED Driver configuration

This configures how Node-RED instances are run by the platform.

| Option        | Description                                             |
| ------------- | ------------------------------------------------------- |
| `driver.type` | The type of deployment model to use. Default: `localfs` |

### Localfs Driver options

| Option                          | Description                                                                                                                        |
| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `driver.options.start_port`     | The port number to start assigning to Node-RED instances as they are created. Default: `12080`                                     |
| `driver.options.node_path`      | The path to find the node.js executable - useful if Node.js has been installed with `nvm` so isn't necessarily on the system path. |
| `driver.options.logPassthrough` | Prints the Node-RED logs in JSON format to stdout of the nr-launcher process. Default: `false`                                     |
| `driver.options.privateCA`      | The fully qualified path to a pem file containing locally trusted CA cert chain. Default: not set                                  |

### Docker Driver options

| Option                          | Description                                                                                                           |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| `driver.options.socket`         | The path to the Docker control unix domain socket. Default `/var/run/docker.sock`                                     |
| `driver.options.logPassthrough` | Prints the Node-RED logs in JSON format to stdout of the Instance containers. Default: `false`                        |
| `driver.options.privateCA`      | The fully qualified path to a pem file on the host machine containing locally trusted CA cert chain. Default: not set |

### Kubernetes Driver options

| Option                                            | Description                                                                                                                                                        |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `driver.options.namespace`                        | The namespace to run Node-RED instances in. Default: `flowforge`                                                                                                   |
| `driver.options.cloudProvider`                    | Enables specific options for certain platforms e.g. `aws`. Default: not set                                                                                        |
| `driver.options.projectSelector`                  | A YAML object containing node annotations to use to filter which nodes Node-RED instances run on. Default: `role: projects`                                        |
| `driver.options.logPassthrough`                   | Prints the Node-RED logs in JSON format to stdout of the instance pods. This should be set with the `forge.logPassthrough=true` Helm chart value. Default: `false` |
| `driver.options.privateCA`                        | The name of a ConfigMap containing a file called `certs.pem` which holds locally trusted CA cert chain. Default: not set                                           |
| `driver.options.customHostname.enabled`           | Enables the custom hostname feature. Default: `false`                                                                                                              |
| `driver.options.customHostname.cnameTarget`       | The hostname users should configure their DNS entries to point at. This value is required to enable this feature. Default: not set                                 |
| `driver.options.customHostname.ingressClass`      | The name of the Ingress Class that should be used for the custom hostname. Default: not set                                                                        |
| `driver.options.customHostname.certManagerIssuer` | The name of the CertManager ClusterIssuer to provision HTTPS certificates for custom hostnames. Default: not set                                                   |

## MQTT Broker configuration

By default, the platform runs without an MQTT broker. This restricts some features
in the platform, such as the Project Nodes, Device Actions and Remote Device Editing.

If a broker has been setup in the platform, the following configuration is required:

| Option              | Description                                                                                                                                                             |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `broker.url`        | The url for the platform to access the broker. For example: `mqtt://localhost:4800`.                                                                                    |
| `broker.public_url` | The url used by devices to connect to the broker, if different to `broker.url`. For example, this may require devices to use WebSockets instead: `ws://localhost:4881`. |

## Email configuration

By default, email is disabled. This restricts some features in the platform around
inviting new users to join.

| Option                 | Description                                                                                           |
| ---------------------- | ----------------------------------------------------------------------------------------------------- |
| `email.enabled`        | Enables the email sending functionality of the platform. Default: `false`                             |
| `email.from`           | Sets the address email will appear from. Default: `"FlowFuse" <donotreply@flowforge.com>`             |
| `email.smtp.host`      | Hostname of the SMTP server to send email through. Default: `localhost`                               |
| `email.smtp.port`      | Port of the SMTP server to send email through. Default: `587` if `secure` is `false`, `465` otherwise |
| `email.smtp.secure`    | Whether to use TLS to connect to the SMTP server. Default: `false`                                    |
| `email.smtp.auth.user` | Username to authenticate the connection with. Default: `unset`                                        |
| `email.smtp.auth.pass` | Password to authenticate the connection with. Default: `unset`                                        |
| `email.debug`          | If set to true, it will log the full content of emails it tries to send. Default: `false`             |

See [here](https://flowfuse.com/docs/install/email-providers) for example configuration with common email providers.

### AWS SES Email

There is also support for using AWS SES email, this is mainly intended to be used when deployed on AWS EKS.

This assumes that the instance is running with a Service Account that has a AWS Role with SES access enabled.

| Option                | Description                                                                                       |
| --------------------- | ------------------------------------------------------------------------------------------------- |
| `email.ses.region`    | The AWS region to connect to. Default `unset`                                                     |
| `email.ses.sourceArn` | The AWS ARN of a SES Identity to send email as. Default: `unset`                                  |
| `email.ses.fromArn`   | The AWS ARN of a SES Identity to set as the from field. Default to value of `email.ses.sourceArn` |

## Telemetry configuration

By default, the platform will send anonymous usage information back to us at FlowForge Inc.
This can be disabled via the Admin Settings in the UI, or turned off in the configuration file with the `telemetry.enabled` option.
**IMPORTANT: Licensed installations cannot disable telemetry**

Additionally, you can configure your own instance of FlowFuse to report back to you on how users are using your instance of FlowFuse. FlowFuse supports integration with two different services:

- [PostHog](https://posthog.com/){rel="&#x22;nofollow&#x22;"&#x7D; &#x2A;(recommended)*: You will require your own API key to pass into the `yml`, which will begin the logging of user interactions.
- [Plausible](https://plausible.io/){rel="&#x22;nofollow&#x22;"&#x7D;: &#x2A;(deprecated since 0.9 and will be removed in the future)*: You can setup your own account, and pass the relevant domain to the `yml` in the telemetry configuration

For more information about this feature, see [here](https://flowfuse.com/docs/admin/telemetry)

| Option                                        | Description                                                                                                                                                                                                                                                                                              |
| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `telemetry.enabled`                           | Enables the anonymous usage telemetry of the platform. Default: `true`                                                                                                                                                                                                                                   |
| `telemetry.frontend.posthog.apiurl`           | The API URL for PostHog, either '<https://app.posthog.com>{rel="&#x22;nofollow&#x22;"}' or '<https://eu.posthog.com>{rel="&#x22;nofollow&#x22;"}'. Default: `https://app.posthog.com`                                                                                                                    |
| `telemetry.frontend.posthog.apikey`           | The API key provided to you from your own PostHog account. Default: `null`                                                                                                                                                                                                                               |
| `telemetry.frontend.posthog.capture_pageview` | FlowFuse is designed as to provide custom posthog `$pageview` events that provide more detail on navigation than the default, and suit a single page application better. As such, we recommend setting this to false in order to prevent duplicate `pageleave`/`pageview` events firing. Default: `true` |
| `telemetry.frontend.google.tag`               | A Google Analytics (gtag) measurement ID. Default: `null`                                                                                                                                                                                                                                                |
| `telemetry.frontend.google.events`            | An object with keys matching the names of tag events to be enabled and any payload values. Default `null`                                                                                                                                                                                                |
| `telemetry.frontend.google.gtm`               | A Google Tag Manager container ID (e.g. `GTM-XXXXXXX`). Loads GTM once cookie consent is accepted. Default: `null`                                                                                                                                                                                       |

## Rate Limiting configuration

By default, rate limiting is disabled and the platform will not rate limit any requests.

To enable rate limiting, you can set the `rate_limits.enabled` option to `true`.

When enabled, all routes will be limited to 1000 requests per 1 minute window. These defaults can be adjusted by setting values in the configuration options listed below.

| Option                     | Description                                                                                                                            |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| `rate_limits.enabled`      | Enables rate limiting. Default: `false`                                                                                                |
| `rate_limits.global`       | Enables rate limiting for all routes. Default: `true` (defaults to all routes being rate limited)                                      |
| `rate_limits.timeWindow`   | The time window in which requests are counted. Default: `60000` (1 minute)                                                             |
| `rate_limits.max`          | The maximum number of requests allowed in the time window. Default: `1000`                                                             |
| `rate_limits.maxAnonymous` | The maximum number of requests allowed in the time window for anonymous users. Default: not configured (defaults to `rate_limits.max`) |

For additional options, see [fastify-rate-limit](https://github.com/fastify/fastify-rate-limit#options){rel="&#x22;nofollow&#x22;"} documentation.

## Session timeouts

Allows control of the maximum user session life.

| Option                     | Description                                                                                                                 |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| `sessions.maxDuration`     | The maximum number of seconds a user session can last. Default: `604800` (1 week)                                           |
| `sessions.maxIdleDuration` | The maximum number of seconds a session can be idle. Must be less than `sessions.maxDuration`. Default: `115200` (32 hours) |

## Support configuration

It is possible to add a [HubSpot Support Widget](https://knowledge.hubspot.com/chatflows/create-a-live-chat){rel="&#x22;nofollow&#x22;"} into FlowFuse. This will appear as a floating chat bubble on the bottom-right corner of the screen. To enable this, you'll need to provide the

| Option                                  | Description                                                                                                                                                                                       |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `support.enabled`                       | Enables the chat support widget in the UI. Default: `false`                                                                                                                                       |
| `support.frontend.hubspot.trackingcode` | The numerical identifier within your [HubSpot Tracking Code](https://knowledge.hubspot.com/conversations/chat-widget-is-not-appearing-on-your-pages){rel="&#x22;nofollow&#x22;"}. Default: `null` |

## MQTT Broker configuration

The platform uses an MQTT broker to provide real-time messaging between devices,
Node-RED instances and the platform. The broker shipped with the platform's
Docker Compose and Kubernetes installations is [EMQX](https://www.emqx.io/){rel="&#x22;nofollow&#x22;"}: the
Docker Compose installation includes it by default, and the Helm chart deploys it
when the broker is enabled (`forge.broker.enabled`), which requires the
[EMQX Operator](https://docs.emqx.com/en/emqx-operator/latest/getting-started/getting-started.html#install-emqx-operator){rel="&#x22;nofollow&#x22;"}
to be installed on the cluster.

This is currently an *optional* component - the platform will work without the
broker, but some features will not be available:

- Without a broker: Project Nodes, Device Actions and Remote Device Editing are unavailable.
- The following features additionally require the platform broker to be EMQX:
  the [Team Broker](https://flowfuse.com/docs/user/teambroker), [FlowFuse Expert](https://flowfuse.com/docs/user/expert/)
  and live device log and performance views in the platform UI.

[Mosquitto](https://mosquitto.org/){rel="&#x22;nofollow&#x22;"} is supported at a legacy level for existing
installations that manage their own broker: core platform messaging works, but the
EMQX-dependent features listed above are unavailable. Replacing the platform broker
with a different customer-supplied broker is not supported.

| Option              | Description                                                                                                                                                                                                                                                             |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `broker.url`        | The full url to the platform broker. This is used by the platform and Node-RED instances to connect to the broker. For example: `mqtt://localhost:1883`.                                                                                                                |
| `broker.public_url` | If set, this is the url provided to Devices to connect to the broker with. When running in a Docker or K8S environment, this url should be the externally addressable url the broker is provided on. This could be via WebSockets, for example: `ws://example.com:1884` |

## AI Configuration

| Option       | Description                                                                                                                                                                                                                                                          |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ai.enabled` | Enables all AI features on the platform (still requires an Enterprise License). When set to `false`, all AI functionality is disabled regardless of individual feature configuration (assistant, expert, inline completions, snapshot descriptions). Default: `true` |

## FF Tables

| Option                  | Description                                                                                        |
| ----------------------- | -------------------------------------------------------------------------------------------------- |
| `tables.enables`        | Enables the FlowFuse Tables feature. Default: `false`                                              |
| `tables.driver.type`    | Selects the FF Tables driver to use (`postgres-localfs` or `postgres-supavisor`). Default: not set |
| `tables.driver.options` | Configuration options for the driver. Details depend on the driver used. Default: not set          |

The options for the `postgres-localfs` driver require connection details for an admin user on a Postgres instance e.g.

```text
database:
  user: root
  password: password
  host: localhost
  port: 5432
  database: postgres
  ssl: false

```

## Logging configuration

By default the forge app is set to `info` level logging, with the HTTP routes logged at `warn`

| Option           | Description                                                                    |
| ---------------- | ------------------------------------------------------------------------------ |
| `logging.level`  | Change the default logging level. Default: `info`                              |
| `logging.http`   | Change the default HTTP route logging level. Default: `warn`                   |
| `logging.pretty` | Enable/Disable pretty-printing of the log output. Default: `false` - see below |

Setting `logging.http` to `info` will log every HTTP request and response details.

The `pretty` option controls the formatting of the log output. When running in developer
mode, (for example, if `NODE_ENV` is set to `developer`), then pretty formatting is enabled
by default. This makes the logs more human-readable.

Otherwise, the log output is JSON formatted for consumption by other tools.

## File storage

FlowFuse includes a service that can be used by Node-RED instances to read and write files
in their flows as well as providing persistent storage for flow context information.

Details of configuring the File Storage service are available [here](https://flowfuse.com/docs/install/file-storage).

The main `flowforge.yml` file needs to contain the following properties so it
can access the File server.

| Option          | Description                                                  |
| --------------- | ------------------------------------------------------------ |
| `fileStore.url` | The URL of the FlowFuse File Server to use. Default: not set |

## Enabling Persistent File Storage - File Nodes

These nodes are enabled by default on the FlowFuse Cloud platform. If you're
running a self-hosted environment you should follow the next steps.

FlowFuse file nodes replace the core Node-RED file nodes. To make use of these
nodes, the FlowFuse platform Administrator must ensure the core file nodes are
not loaded.

This is done by adding `10-file.js` in the **Exclude nodes by filename**
section of your instance settings under the **Palette** section.

This setting is modifiable only by a Team owner and only if it has not been
locked in the [template](https://flowfuse.com/docs/user/concepts#template) by the platform Administrator.

[Click here](https://flowfuse.com/docs/user/filenodes), to learn more about the usage of the FlowFuse File Nodes.

## Content Security Policy

| Option                                | Description                                                                                                                                                                    |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `content_security_policy.enabled`     | Enabled `Content-Security-Policy` headers. Default: `false`                                                                                                                    |
| `content_security_policy.directives`  | Overrides the default set of directives, supplied as a JSON object defined by HelmetJS [here](https://helmetjs.github.io/#content-security-policy){rel="&#x22;nofollow&#x22;"} |
| `content_security_policy.report_only` | Enables reporting only mode. Default: `false`                                                                                                                                  |
| `content_security_policy.report_uri`  | Provides at URI for reporting to be sent to if enabled                                                                                                                         |

## NPM Registry

These settings enable per team Node-RED private catalogue generation

| Option                       | Description                                           |
| ---------------------------- | ----------------------------------------------------- |
| `npmRegistry.enabled`        | Enables NPM Registry support. Default: `false`        |
| `npmRegistry.url`            | The URL for the Verdaccio NPM Registry. Default: none |
| `npmRegistry.admin.username` | Username for Verdaccio admin user                     |
| `npmRegistry.admin.password` | Password for Verdaccio admin user                     |

## BluePrint Updates

For Licenses instances these options control how new BluePrints are imported

`blueprintImport.enabled` | Enables the import of new BluePrints from FlowFuse. Default: `true``blueprintImport.export` | Enables the API endpoint to export the local BluePrints. Default: `false``blueprintImport.url` | The URL to import BluePrints from. Default: `https://app.flowfuse.com/api/v1/flow-blueprints/export-public`


# DNS Setup

When running FlowFuse on Docker or Kubernetes you will need to be able to setup an entry in a DNS server.

This is because FlowFuse uses hostname based routing to know which Node-RED instance you want to access.

By default the instance name is used in combination with a supplied domain. In this document we will use `example.com` as the domain. (It doesn't need to be a "whole" domain, it could also be a sub domain of one you already own. e.g. `ff.example.com`).

If you are running Docker/Kubernetes on the same machine as the DNS server and Web Browser do not use `127.0.0.1` as the IP address to point the wild card domain at. This is because the host names will be looked up by the Web Browser, the Forge Application, and the Node-RED instances. The last 2 are running in containers and `127.0.0.1` will resolve to the container, not the entry point.

## Production

For a production deployment you will need to have access to modify DNS, if you are not sure how to set up DNS records talk to whoever manages your DNS.

As mentioned earlier you will need them to create a [wildcard DNS](https://en.wikipedia.org/wiki/Wildcard_DNS_record){rel="&#x22;nofollow&#x22;"} entry that points to either the Docker host machine or the Kubernetes Nodes which are running the Ingress Controller.

This can be either:

- a `A` (and `AAAA` for IPv6) record pointing to an IP address e.g. `*.example.com 8600 A 192.0.2.1`
- a `CNAME` record pointing to the hostname of the entry point e.g. `*.ff.example.com 8600 CNAME forge.example.com`

### AWS ALB Ingress

When using AWS ALB (Application Load Balancer) as an Ingress Controller for FlowFuse deployed into an EKS cluster then you would create a wildcard CNAME entry pointing to the hostname of the ALB

### Digital Ocean

You should create an A record pointing to the public IP address of the Load Balancer created when you install the Traefik Helm Chart.

## Local Testing and Development

For development and testing we probably only need to set up DNS entries for the developers local machine. The easiest way to do this is to use an application called dnsmasq.

Dnsmasq is a tool that can be used as a DNS caching proxy (and a DHCP server, but we don't need that). We can set it up to point to an upstream DNS server to resolve all normal addresses, but we can also give it a list of hostname/IP address pairs to use locally.

### DNSMasq

Setting up dnsmasq is not too complex, what is harder is setting it up in a way that works well with the network configuration on a laptop that might move between different networks and expects to get its default DNS configuration automatically assigned by DHCP.

The following headings cover how to do this on a number of different operating systems

#### Ubuntu

For Docker on Linux you can use `172.17.0.1` as the address for the domain which is the IP address assigned to the `docker0` interface.

```bash
sudo apt-get install dnsmasq
sudo echo "bind-interfaces" >> /etc/dnsmasq.conf
sudo echo "no-resolv" >> /etc/dnsmasq.conf
sudo echo "conf-dir=/etc/dnsmasq.d" >> /etc/dnsmasq.conf
sudo echo "address=/example.com/172.17.0.1" > /etc/dnsmasq.d/02-flowforge.conf
sudo service dnsmasq restart
sudo echo "DNS=127.0.0.1" >> /etc/systemd/resolved.conf
sudo echo "DOMAINS=~example.com" >> /etc/systemd/resolved.conf
sudo service systemd-resolved restart
```

#### Fedora

For Docker on Linux you can use `172.17.0.1` as the address for the domain which is the IP address assigned to the `docker0` interface.

```bash
sudo dnf install dnsmasq
sudo echo "bind-interfaces" >> /etc/dnsmasq.conf
sudo echo "no-resolv" >> /etc/dnsmasq.conf
sudo echo "conf-dir=/etc/dnsmasq.d" >> /etc/dnsmasq.conf
sudo echo "address=/example.com/172.17.0.1" > /etc/dnsmasq.d/02-flowforge.conf
sudo systemctl enable dnsmasq.service
sudo service dnsmasq restart
sudo echo "DNS=127.0.0.1" >> /etc/systemd/resolved.conf
sudo echo "DOMAINS=~example.com" >> /etc/systemd/resolved.conf
sudo service systemd-resolved restart
```

#### Windows

Unfortunately dnsmasq will not run on Windows and I have not found something similar yet.

#### MacOS

On MacOS you can alias a private IP address to the loop back interface e.g. `10.128.0.1` with

```bash
sudo ifconfig lo0 alias 10.128.0.1
```

You will need install dnsmasq using [homebrew](https://docs.brew.sh/Installation){rel="&#x22;nofollow&#x22;"}

```bash
brew install dnsmasq
```

It appears that the install location differs based on the Apple Hardware. For Intel hardware Macs it's in `/usr/local` and for M1 hardware it's `/opt/homebrew`. Please check where it installed things when the previous command has completed.

Then edit a configuration file

M1 mac

```bash
echo "conf-dir=/opt/homebrew/etc/dnsmasq.d" >> /opt/homebrew/etc/dnsmasq.conf
echo "address=/example.com/10.128.0.1" > /opt/homebrew/etc/dnsmasq.d/ff.conf
```

Intel mac

```bash
echo "conf-dir=/usr/local/etc/dnsmasq.d" >> /usr/local/etc/dnsmasq.conf
echo "address=/example.com/10.128.0.1" > /usr/local/etc/dnsmasq.d/ff.conf
```

Set dnsmasq to run as a service

```bash
sudo brew services start dnsmasq
sudo dscacheutil -flushcache
```

Tell MacOS to use dnsmasq for our test domain

```bash
sudo mkdir -p /etc/resolver
sudo tee /etc/resolver/example.com > /dev/null <<EOF
nameserver 127.0.0.1
domain example.com
search_order 1
EOF
```

And finally kick the MacOS resolver so it sees the updates

```bash
sudo killall -HUP mDNSResponder
```

### Pi Hole

Pi Hole is a package that bundles dnsmasq as an image to run on a Raspberry Pi (or in Docker container e.g. on your NAS). Its main use is to block advertisements embedded in web pages. But since in its normal configuration it is already handling all the local DNS traffic, making us work with FlowFuse is possible and means you do not need to change any settings on your development/test machine.

Create the following file in `/etc/dnsmasq.d` called `02-flowforge.conf`

```bash
address=/example.com/192.168.0.22
```

Where 192.168.0.22 is the ipv4 address of the Docker host machine or a Kubernetes node. And `example.com` is the domain to use.

After making the change you will probably need to restart things with:

```bash
sudo pihole restartdns
```

If running Pi Hole in Docker then you will need to create the file on the host and mount it to the `/etc/dnsmasq.d/02-flowforge.conf` location.

### No Local DNS server

If you really can't run dnsmasq then there is a possible alternative.

A really useful service called sslip.io allows you to test FlowFuse even when you cannot use dnsmasq. You can read more about [sslip.io on their web site](https://sslip.io){rel="&#x22;nofollow&#x22;"}.

You will need to set the `domain` entry in the `flowforge.yml` configuration file to the following pattern `172.17.0.1.sslip.io`. Don't forget to replace the IP address with the correct one for your the machine FlowFuse is running on.

This will work because the `sslip.io` domain is set up to always return the IP address embedded in the hostname queried.


# Installing FlowFuse from AWS Market Place

We have packaged the Docker Compose build of FlowFuse as a AWS EC2 AMI. It can be found on the AWS Market Place [here](https://aws.amazon.com/marketplace/pp/prodview-3ycrknfg67rug){rel="&#x22;nofollow&#x22;"}.

This will allow you to quickly spin up an AWS EC2 Machine with everything pre-installed.

## Prerequisites

### DNS

To make use of the AWS Machine image you will need a DNS Domain to host both the FlowFuse application and the Node-RED instances you create.

For example if you use `ff.example.com` then the FlowFuse application will run on `https://forge.ff.example.com` and Node-RED would be on `https://[instance-name].ff.example.com`.

You will need to set up a wildcard DNS entry that points the whole domain to the Public IP address of the Droplet.

```text
*.ff.example.com 3600 A xxx.xxx.xxx.xxx
```

The Public IP address of the EC2 machine will be listed in the AWS Console once it has started and at the start of the Setup Wizard when you first SSH into the machine.

### SMTP Server (Optional)

This is used to send invites to new user and to enable password resets.

You will need to know the following:

- SMTP Server hostname
- Port (Default 587)
- Username/Password

If you don't already have a SMTP server you can grab one from an email delivery service like SparkPost, Sendgrid, Mailgun, etc.

## Setup

After the EC2 Machine has been created and you have set up the DNS entry you will need to connect to the machine to and enter the domain name

You can do this in 2 ways

1. With SSH, either using keys or password depending on what Authentication mechanism you picked at creation time
   ```text
   ssh -i aws-ssh.pem ubuntu@xxx.xxx.xxx.xxx
   ```
2. Using the "Connect" button on the EC2 console. Be sure to change the username from `root` to `ubuntu`![AWS EC2 Console](https://flowfuse.com/docs/install/images/aws-console-connect.png)

Once logged in you will be presented with a wizard to set the domain and confirm by entering `1` or `2` to enter the domain again.

![Digital Ocean Wizard](https://flowfuse.com/docs/install/images/do-wizard.png)

The wizard will then ask about setting up a SMTP server to allow FlowFuse to send email. This used to invite users or reset passwords,
it is optional.

![Digital Ocean Wizard SMTP](https://flowfuse.com/docs/install/images/do-wizard-smtp.png)

The wizard will then update the configuration files and start FlowFuse

![Digital Ocean Direct to Setup](https://flowfuse.com/docs/install/images/do-direct-to-setup.png)

It will then present a link to complete setup in the browser and a Username and Password to log in as the default admin user. You will be asked to change the password when you use it for the first time.

You can now close the console connection to the droplet.

Details of how to complete this steps are [here](https://flowfuse.com/docs/install/first-run)

## Upgrade

You can follow the normal FlowFuse Docker [upgrade instructions](https://flowfuse.com/docs/install/docker#upgrade), the install directory is `/opt/flowforge`


# 1-Click Digital Ocean Droplet Install

We have packaged the Docker Compose build of FlowFuse as a Digital Ocean Droplet. It can be found in the [Digital Ocean Market Place](https://marketplace.digitalocean.com/apps/flowfuse?refcode=fb23e438a477){rel="&#x22;nofollow&#x22;"}.

You can go straight to the [deployment wizard](https://marketplace.digitalocean.com/apps/flowfuse?refcode=fb23e438a477&action=deploy){rel="&#x22;nofollow&#x22;"}

## Prerequisites

### DNS

To make use of this Droplet you will need a DNS Domain to host both the FlowFuse application and the Node-RED instances you create.

For example if you use `ff.example.com` then the FlowFuse application will run on `https://forge.ff.example.com` and Node-RED would be on `https://[instance-name].ff.example.com`.

You will need to set up a wildcard DNS entry that points the whole domain to the Public IP address of the Droplet.

```text
*.ff.example.com 3600 A xxx.xxx.xxx.xxx
```

The Public IP address of the Droplet will be listed in the UI when it has been created

![Digital Ocean Droplet IP address ](https://flowfuse.com/docs/install/images/do-public-ip.png)

### SMTP Server (Optional)

This is used to send invites to new user and to enable password resets.

You will need to know the following:

- SMTP Server hostname
- Port (Default 587)
- Username/Password

If you don't already have a SMTP server you can grab one from an email delivery service like
SparkPost, Sendgrid, Mailgun, or any [other email solution provided by Digital Ocean](https://marketplace.digitalocean.com/category/email){rel="&#x22;nofollow&#x22;"}.

## Setup

After the Droplet has been created and you have set up the DNS entry you will need to connect to the droplet to and enter the domain name

You can do this in 2 ways

1. With SSH, either using keys or password depending on what Authentication mechanism you picked at creation time
   ```text
   ssh -i digital-ocean-ssh.key root@xxx.xxx.xxx.xxx
   ```
2. Opening a Console from the Web Interface
   ![Digital Ocean Console](https://flowfuse.com/docs/install/images/do-droplet-console.png)

Once logged in you will be presented with a wizard to set the domain and confirm by entering `1` or `2` to enter the domain again.

![Digital Ocean Wizard](https://flowfuse.com/docs/install/images/do-wizard.png)

The wizard will then ask about setting up a SMTP server to allow FlowFuse to send email. This used to invite users or reset passwords,
it is optional.

![Digital Ocean Wizard SMTP](https://flowfuse.com/docs/install/images/do-wizard-smtp.png)

The wizard will then update the configuration files and start FlowFuse

![Digital Ocean Direct to Setup](https://flowfuse.com/docs/install/images/do-direct-to-setup.png)

It will then present a link to complete setup in the browser. You can now close the console connection to the droplet.

Details of how to complete this steps are [here](https://flowfuse.com/docs/install/first-run)

## Upgrade

You can follow the normal FlowFuse Docker [upgrade instructions](https://flowfuse.com/docs/install/docker#upgrade), the install directory is `/opt/flowforge`


# Docker Install

This guide walks you through detailed set up of FlowFuse Platform on a Docker container environment using Docker Compose. Typically suited for small/medium on premise deployments.
By the end, you will have a fully functioning FlowFuse instance running in a Docker container.

The following guide walks through a full production-ready deployment. If you want to install FlowFuse for evaluation purposes, please refer to the [Quick Start Guide](https://flowfuse.com/docs/quick-start).

## Checklist

::div{.grid.grid-cols-2.gap-8}
  :::div{.checklist}
  Prerequisites


    ::::div
    :checklist-item{task="Domain Name"}
    :checklist-item{task="Docker Engine & Docker Compose"}
    :checklist-item{task="Setup Dedicated Database" type="recommended"}
    :checklist-item{task="Prepare TLS Certificates" type="recommended"}
    ::::
  :::

  :::div{.checklist}
  Installation


    ::::div
    :checklist-item{task="Download FlowFuse"}
    :checklist-item{task="Configure FlowFuse"}
    :checklist-item{task="Enable HTTPS" type="recommended"}
    ::::
  :::
::

## Prerequisites

Before you begin, ensure you have the following:

1. **Domain Name & DNS:** A domain name that you own and can configure DNS settings for (explained in [DNS](https://flowfuse.com/#dns))
2. **Install Docker:** [Docker Engine](https://docs.docker.com/engine/){rel="&#x22;nofollow&#x22;"} and [Docker Compose](https://docs.docker.com/compose/install/){rel="&#x22;nofollow&#x22;"} (in `2.23.1` version or higher) must be installed on your system (either as a standalone binary or as docker plugin).

For a production-ready environment, we also recommend:

- **Database:** Prepare dedicated database on a external database server (see [FAQ](https://flowfuse.com/#how-to-use-external-database-server) for more details)
- **TLS Certification:** Prepare TLS certificate for your domain and configure FlowFuse platform to use it (see [Enable HTTPS](https://flowfuse.com/#enable-https-optional))

### Requirements

To run the FlowFuse platform smoothly, we recommend the following minimum hardware specs:

- CPU: 2 cores
- Memory: 4 GB RAM
- Storage: 20 GB disk space
  Each Node-RED instance you host will uses 0.1 CPU cores and 256 MB of memory by default. This parameters can be adjusted in admin area of FlowFuse platform. Keep this in mind when sizing your hardware, especially if plan to create multiple hosted instances.

When deploying the FlowFuse platform behind a firewall or proxy, ensure that the following ports are open and forwards a traffic to the server where FlowFuse is installed:

- Port `80` (HTTP)
- Port `443` (HTTPS)

#### AWS Elastic Container Service

At this time we do not support deploying FlowFuse to AWS's Elastic Container Service.

### DNS

The orchestration uses an instance of Nginx to route requests to each Node-RED instance. To do this it needs each instance to have a unique hostname, to generate this the instance name is prepended to a supplied domain.

To make this work you will need to configure a DNS server to map a [wildcard domain entry](https://en.wikipedia.org/wiki/Wildcard_DNS_record){rel="&#x22;nofollow&#x22;"} to the IP address of the host running Docker. e.g `*.example.com`.

The FlowFuse Application will be hosted on `http://forge.example.com`

**Note** At this moment FlowFuse platform is not capable to run on localhost. You must point your domain to the external IP address of the host machine, not the loopback address (`127.0.0.1`).

Notes on how to setup DNS can be found [here](https://flowfuse.com/docs/install/dns-setup).

## Installing FlowFuse

### Download installation files

Download the latest version of the FlowFuse Docker Compose file and example `.env` file used for installation configuration:

```bash
curl -L -o docker-compose.yml https://github.com/FlowFuse/docker-compose/releases/latest/download/docker-compose.yml
curl -L -o .env https://raw.githubusercontent.com/FlowFuse/docker-compose/refs/heads/main/.env.example
```

### Configure

Installation configuration is done via the `.env` file.
The minimal configuration required is the domain name you will be using for the platform.

Edit downloaded `.env` file with the editor of your choice and update the `DOMAIN` variable with the domain you will be using for the platform.

Alternatevily, use `sed` to update the `DOMAIN` variable in the `.env` file:

```bash
sed -i 's/^DOMAIN=.*/DOMAIN=example.com/' .env
```

Please note that once set, the `DOMAIN` value should not be changed as it is used as part of the configuration stored in the database of each Node-RED instance. The ability to migrate to different domain is on the feature backlog.

### Enable HTTPS (optional)

If you want to serve the FlowFuse platform and Node-RED instances over TLS you will need to obtain a wildcard TLS certificate for the domain you are using eg `*.example.com`. If you are running on an Internet facing machine you can use our configuration files to generate it atomatically.

Otherwise you will need to contact a SSL Certificate vendor and configure Nginx manually.

#### Automatic TLS Certificate

**Note: Automatic TLS generation is possible only for the publicly available servers**

In the `.env` file, set the `TLS_ENABLED` variable to `true`:

```bash
TLS_ENABLED=true
```

Proceed to the [next paragraph](https://flowfuse.com/#start-flowfuse-platform) to start the platform with automatically generated TLS certificate.

> When using automatic TLS certificate generation, the platform will take a few minutes to generate them on the first platform startup.
> For a short period of time browsers may report untrusted certificate warning. This is expected behavior and should resolve itself once the certificate is generated.

#### Custom TLS Certificate

If you have own TLS certificate, you can use it in FlowFuse platform installation as well. As mentioned before, the certificate must be a wildcard one for the domain you are using.

::div{.ff-callout.ff-callout--note}
Note

  :::div{.ff-callout__content}
  If your TLS certificate is issued by a private Certificate Authority, additional configuration is required so that Hosted Instances trust the CA. See [What additional configuration is required when the TLS certificate is issued by a private Certificate Authority?](https://flowfuse.com/#what-additional-configuration-is-required-when-the-tls-certificate-is-issued-by-a-private-certificate-authority) for the step-by-step instructions.
  :::
::

To configure FlowFuse platform with your certificate, you need to have:

- certificate key file
- certificate's full chain (server certificate and intermediate certificates bundled into single file)

To add your certificate to the platform, edit the `.env` file downloaded earlier and set values for `TLS_ENABLED`, `TLS_CERTIFICATE` and `TLS_KEY` variables. `TLS_ENABLED` variable should be set to `true`.
`TLS_CERTIFICATE` should contain the full chain of the certificate while `TLS_KEY` should contain the key file.
Example of `.env` file with the custom TLS certificate configuration:

```bash
TLS_ENABLED=true
TLS_CERTIFICATE="
-----BEGIN CERTIFICATE-----
MIIFfzCCBKegAwIBAgISA0
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFfzCCBKegAwIBAgISA0
...
-----END CERTIFICATE-----
"
TLS_KEY="
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQD
...
-----END PRIVATE KEY-----
"
```

## Start FlowFuse platform

**Note: Make sure all configuration are done above before proceeding.**

**Note: Commands must be executed within the same directory where the Docker Compose and `.env` files are located.**

#### With automatic TLS certificate generation

```bash
docker compose --profile autotls -p flowfuse up -d
```

#### In all other scenarios, including custom TLS certificate

```bash
docker compose -p flowfuse up -d
```

The platform will take a few minutes to start up. You can check the status of the containers by running:

```bash
docker compose -p flowfuse ps
```

Visit `forge.example.com` (replace `example.com` with the domain configured in the `.env` file) in your browser to access the FlowFuse platform.

## First Run Setup

The first time you access the platform in your browser, it will take you through
creating an administrator for the platform and other configuration options.

For more information, follow [this guide](https://flowfuse.com/docs/install/first-run).

Once you have finished setting up the admin user there are some Docker specific items to consider.

## Upgrade

**Note: If you are upgrading from version `2.10.0` or lower, please follow [this guide](https://github.com/FlowFuse/docker-compose/blob/main/UPGRADE.md){rel="&#x22;nofollow&#x22;"}**

1. Find the Docker Compose project name:
   ```bash
   docker compose ls
   ```
   The output will show the project name, as well as the location of Docker Compose file used for creating the project.
2. Stop the existing project (replace `$projectName`with your project name):
   ```bash
   docker compose -p $projectName down --rmi all
   ```
3. Download the latest Docker Compose files:
   ```bash
   curl -L -o docker-compose.yml https://github.com/FlowFuse/docker-compose/releases/latest/download/docker-compose.yml
   ```
4. Make sure the `.env` file is present and contains your installation-specific configuration. Download an example `.env`file if needed:
   ```bash
   curl -o .env.example https://raw.githubusercontent.com/FlowFuse/docker-compose/refs/heads/main/.env.example
   ```
5. Pull the latest version of the default stack container (and any other stacks you have configured)
   ```bash
   docker pull flowfuse/node-red:latest
   ```
6. Start the project depending on the TLS configuration (replace `$projectName` with your project name):

- automatic TLS:
  ```bash
  docker compose --profile autossl -p $projectName up -d
  ```
- any other scenario:
  ```bash
  docker compose -p $projectName up -d
  ```

## Common Questions

### How to use external database server?

FlowFuse platform uses PostgreSQL database to store its data. By default, the database is created and managed by the Docker Compose.
If you want to use an external database server, you need to:

- on your database server, create `flowforge` and `ff-context` databases as well as a user with access to both of them (see `configs.postgres_db_setup` and `configs.postgres_context_setup` in the `docker-compose.yml` file for the reference)
- configure the connection to the database in the `.env` file. Set the `DB_HOST`, `DB_USER`, `DB_PASSWORD` variables to the connection details of the external database server

Once ready, [start the application](https://flowfuse.com/#start-flowfuse-platform) .

### How can I provide my own TLS certificate?

If you have your own TLS certificate, you can use it in FlowFuse platform installation as well. See [Enable HTTPS](https://flowfuse.com/#enable-https-optional) section for more details.

Additionally, if your TLS certificate is issued by a private Certificate Authority, you will need to perform some additional configuration to make hosted Node-RED instances trust the CA. See [What additional configuration is required when the TLS certificate is issued by a private Certificate Authority](https://flowfuse.com/#what-additional-configuration-is-required-when-the-tls-certificate-is-issued-by-a-private-certificate-authority) for the step-by-step instructions.

### What additional configuration is required when the TLS certificate is issued by a private Certificate Authority?

When the FlowFuse platform is configured with a TLS certificate issued by a private Certificate Authority (CA), hosted Node-RED instances will not trust the CA by default. As a result, opening the editor for a hosted instance will fail with a certificate trust error.

To make hosted Node-RED instances trust the private CA, follow the steps below:

1. **Update the environment file.** In the `.env` file created during the installation process, set `DOCKER_DRIVER_PRIVATE_CA_PATH` to the path of your Certificate Authority certificate file. This must be the path to the file stored on the Docker host server. For example, if the `ca.pem` file is located at `/usr/local/ssl/ca.pem`:
   ```bash
   DOCKER_DRIVER_PRIVATE_CA_PATH="/usr/local/ssl/ca.pem"
   ```
2. **Modify the Compose file.** In the `docker-compose.yml` file used to create the FlowFuse Docker stack, uncomment the `NODE_EXTRA_CA_CERTS` environment variable and the corresponding volume mount on the `forge` service so the certificate is passed correctly to the platform. You can apply both changes with a single `sed` command:
   ```bash
   sed -i.bak -E -e 's/^#([[:space:]]*- "NODE_EXTRA_CA_CERTS=)/\1/' -e 's/^#([[:space:]]*- \$\{DOCKER_DRIVER_PRIVATE_CA_PATH\})/\1/' docker-compose.yml && rm docker-compose.yml.bak
   ```
3. **Restart the Forge service** to apply the changes:
   ```bash
   docker compose restart forge
   ```
4. **Apply changes to running instances.** Once the platform is online, manually suspend and start all running hosted instances so they pick up the new TLS settings.

### I would like to invite my team members to the platform with e-mail, how can I do that?

In order to configure FlowFuse platform with external e-mail server, you need to adjust `EMAIL_*` variables in the `.env` file.
Find the `.env` file end edit `Email configuration` section with following details:

- `EMAIL_ENABLED` - set to `true` to enable e-mail functionality
- `EMAIL_HOST` - provide SMTP server host
- `EMAIL_PORT` - provide SMTP server port (default is `587`)
- `EMAIL_SECURE` - set to `true` if the connection should be secured
- `EMAIL_USER` - provide SMTP server username
- `EMAIL_PASSWORD` - provide SMTP for the user defined in `EMAIL_USER`

Restart the core application to apply the changes:

```bash
docker compose restart forge
```

### Connection Refused error

After starting the platform, I can't access it in the browser - I see "Connection Refused error"

If you are using the Digital Ocean Docker Droplet to host FlowFuse you will need to ensure that port 80 & 443 are opened in the UFW firewall before starting.

FlowFuse platform is running on ports 80 and 443, so you need to open these ports in the firewall. Below are examples of commands to open these ports:

Ubuntu:

```bash
sudo ufw apply http
sudo ufw apply https
```

CentOS:

```bash
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --reload
```

Windows (command prompt):

```bash
netsh advfirewall firewall add rule name="Open Port 80" dir=in action=allow protocol=TCP localport=80
netsh advfirewall firewall add rule name="Open Port 443" dir=in action=allow protocol=TCP localport=443
```

Windows (PowerShell):

```powershell
New-NetFireWallRule -DisplayName 'WSL 8080TCP' -Direction Inbound -LocalPort 8080 -Action Allow -Protocol TCP
New-NetFireWallRule -DisplayName 'WSL 8080TCP' -Direction Outbound -LocalPort 8080 -Action Allow -Protocol TCP
```

### I installed FlowFuse on Windows with WSL2, application is running but I can't access it in the browser

Next to [opening the ports in the firewall](https://flowfuse.com/#connection-refused-error),
you need to configure port forwarding from Windows host to WSL2 server.

To forward traffic from an external IP to your container, run the following PowerShell command (administrator privileges required):

```powershell
netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=127.0.0.1
```

This command forwards traffic from port 80 on your external IP address to port 80 on your localhost, where the Nginx Proxy container is listening for connections.

### How can I enable persistent storage for Node-RED instances?

Node-RED instances running in Docker do not have direct access to a persistent file system to store files or use for storing context data.

FlowFuse includes a File Storage service that can be enabled to provide persistent storage.

To disable the default File nodes, edit the Template and add `10-file.js,23-watch.js` to the "Exclude nodes by filename" section

![](https://flowfuse.com/docs/install/images/file-node-template.png){width="500"}

FlowFuse Docker Compose files includes FlowFuse File Storage component by default and starts it along with the platform.

Full details on configuring the File Storage service are available [here](https://flowfuse.com/docs/install/file-storage).

## Uninstall

- Bring the services down with `docker compose -p flowfuse down -v` (note the extra `-v` to delete all the volumes, only include this if you do not want to reuse this install)
- Use `docker images` to list container images
- Use `docker rmi [imagename]:[tag]` to remove all images that start with `flowfuse/`


# Docker Stacks

A Stack defines a set of platform configuration options that will get
applied to each Node-RED instance when created.

For container based deployment models, this covers three things:

- `memory` - the amount of memory (in MB) to limit container to. Recommended minimum: `256`.
- `cpu` - a value between 1 and 100 that is the % of a CPU core the container should be allowed to consume.
- `container location` - this is the fully qualified name of the container to use. The default container built when following the install instructions is named `flowfuse/node-red:latest`

If you wish to use different Node-RED version, you need to specify the name of the container and the version you want to use. For example, if you want to use Node-RED v3.1.x, you should enter `flowfuse/node-red:latest-3.1.x` in the `container location` section of the Stack configuration.
Full list of available pre-built containers can be found on [Docker Hub](https://hub.docker.com/r/flowfuse/node-red/tags){rel="&#x22;nofollow&#x22;"}.

## Creating Own Containers

As mentioned in the previous paragraph, we encourage to use our pre-built containers in your stacks.
However, if you want to create your own container, you can do so by creating a `Dockerfile` and `package.json` files.
There is an example `Dockerfile` and `package.json` in the [node-red-container](https://github.com/FlowFuse/docker-compose/tree/main/node-red-container){rel="&#x22;nofollow&#x22;"}
directory of the [docker-compose](https://github.com/FlowFuse/docker-compose){rel="&#x22;nofollow&#x22;"} project. This will start with `nodered/node-red:latest`
as it's base and then add the required FlowFuse components.

Builds of this container for amd64, arm64 and armv7 are built for every release and published to Docker hub as [flowfuse/node-red](https://hub.docker.com/r/flowfuse/node-red){rel="&#x22;nofollow&#x22;"}. These can be used as a base to build custom stacks.

If you wanted to pin at Node-RED v3.0.2 you would change the first line to:

```docker
FROM nodered/node-red:3.0.2

ARG REGISTRY
RUN if [[ ! -z "$REGISTRY" ]] ; then npm config set @flowfuse:registry "$REGISTRY"; fi

COPY package.json /data
...
```

To add nodes to the default image you can extend the supplied container.
The following Dockerfile will install the node-red-dashboard

```docker
FROM flowfuse/node-red

WORKDIR /usr/src/node-red
RUN npm install node-red-dashboard

WORKDIR /usr/src/flowforge-nr-launcher
```

To build the container run the following:

```shell
docker build node-red-container/Dockerfile-dashboard -t flowfuse/node-red-dashboard:3.0.2
```

You would then enter `flowfuse/node-red-dashboard:3.0.2` in the `container` section
of the Stack configuration.

Stacks can be changed on a per instance basis, see also the
[user stack documentation](https://flowfuse.com/docs/user/changestack).


# Using Docker on Windows

While Docker is inherently a Linux-based technology and we recommend running FlowFuse on Linux when ever possible, there are several ways to run Docker on Windows.
Below, we outline the primary methods available, along with recommendations based on specific needs and use cases.

### Docker Desktop

[Docker Desktop](https://docs.docker.com/desktop/install/windows-install/){rel="&#x22;nofollow&#x22;"} is the most straightforward option for running Docker on Windows, offering a complete Docker environment with GUI support.
It’s well-suited for users seeking ease of setup and use.

**Recommendation:**

Use Docker Desktop if licensing is not a constraint for your organization, as it provides a user-friendly, fully-integrated Docker experience on Windows.

### Rancher Desktop

[Rancher Desktop](https://rancherdesktop.io/){rel="&#x22;nofollow&#x22;"} is a free, open-source alternative to Docker Desktop, providing a similar experience but without the licensing concerns.
Rancher Desktop includes both container management and Kubernetes support, making it a flexible choice for containerized workloads on Windows.

**Recommendation:**

Consider Rancher Desktop if you prefer an open-source tool with no licensing restrictions.

### Windows Subsystem for Linux (WSL2)

[WSL2](https://docs.microsoft.com/en-us/windows/wsl/install){rel="&#x22;nofollow&#x22;"} enables users to run a Linux environment directly on Windows.
WSL2 supports running Docker Engine without the need for a GUI, making it ideal for headless configurations or for those looking to operate Docker from a Linux command line on Windows.

**Recommendation:**

WSL2 is best suited for advanced users who are comfortable with command-line tools and who want to run Docker Engine directly within a Linux environment on Windows.

For the installation of Docker Engine using WSL2, refer to the next paragraph.

## How to Install Docker Engine (Docker CE) on Windows using WSL2

This guide explains how to install Docker Engine (Docker CE) on Windows using Windows Subsystem for Linux (WSL2).

### Prerequisites

Ensure your system meets the following Windows Subsystem for Linux v2 requirements:

- Windows Server 2022
- Windows 10 version 2004 and higher (Build 19041 and higher)
- Windows 11

### Step 1: Install Windows Subsystem for Linux

Open PowerShell as an administrator and run the following commands:

1. Install WSL and the default Linux distribution (Ubuntu) using the following command:
   ```powershell
   wsl --install
   ```
2. Reboot your system to apply changes
   ```powershell
   shutdown -r -t 5
   ```

After the reboot, WSL will automatically start installing the Ubuntu Linux distribution.
You will be prompted to create a new UNIX account. Follow the instructions to create a new user account and set a password.
![wsl-unix-user-creation](https://flowfuse.com/docs/install/images/wsl-unix-user.png)

Once completed, you will be dropped into a new Ubuntu shell.
![wsl-install-complete](https://flowfuse.com/docs/install/images/wsl-install-complete.png)

3. Confirm using proper WSL version, by running (in Powershell window):
   ```powershell
   wsl --status
   ```

### Step 2: Install Docker on Ubuntu

Once the Ubuntu system is ready, follow these steps to install Docker:

1. **Remove Conflicting Packages**:br First, remove any existing Docker packages that might conflict with the installation:
   ```bash
   for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo apt-get remove $pkg; done
   ```
2. **Add Docker’s Official GPG Key and APT Repository**:br Next, update your package list and add Docker's official GPG key and APT repository:
   ```bash
   sudo apt-get update
   sudo apt-get install ca-certificates curl
   sudo install -m 0755 -d /etc/apt/keyrings
   sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
   sudo chmod a+r /etc/apt/keyrings/docker.asc
   ```
   :brAdd the Docker repository to your APT sources:
   ```bash
   echo \
     "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
     $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
     sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
   sudo apt-get update
   ```
3. **Install Docker Packages**:br Now, install Docker and its associated packages:
   ```bash
   sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
   ```
4. **Add user to Docker group**:br Add your user to the `docker` group to run Docker commands without `sudo`:
   ```bash
   sudo usermod -aG docker ubuntu
   ```
5. **Start the Docker Service**:br Start Docker using the following command:
   ```bash
   sudo /etc/init.d/docker start
   ```
6. **Verify Docker Installation**:br Run a test Docker container to verify that Docker is installed and running correctly:
   ```bash
   sudo docker run hello-world
   ```
   :brIf Docker is installed correctly, you should see a similar output: :br![wsl-docker-installation-complete](https://flowfuse.com/docs/install/images/wsl-docker-complete.png)

Once Docker is installed, you can [install the FlowFuse platform using docker compose](https://flowfuse.com/docs/install/docker).


# Example configuration for common email platforms

## GMail

```yaml
email:
  enabled: true
  debug: false
  smtp:
    host: smtp.gmail.com
    port: 465
    secure: true
    auth:
        user: [USER]@gmail.com
        pass: [PASSWORD]
```

Note: Gmail may require an app specific password to be created if you are using 2FA on the account you can set that up [here](https://security.google.com/settings/security/apppasswords){rel="&#x22;nofollow&#x22;"}

## Office365

```yaml
email:
  enabled: true
  debug: false
  smtp:
    host: smtp.office365.com,
    secure: false
    tls:
      ciphers: "SSLv3",
      rejectUnauthorized: false
    auth:
      user: [USERNAME]
      pass: [PASSWORD]
```


# FlowFuse File Storage

FlowFuse has two storage-related features for Node-RED instances in container-based deployments. They are not mutually exclusive, and some deployments use both.

- **Persistent Storage** mounts a persistent volume into the Node-RED instance at `/data/storage`. This was introduced in FlowFuse v2.6.0 for Kubernetes.
- **The File Storage service** provides the FlowFuse File nodes and Persistent Context.

The rest of this page is structured around those two features so it is clearer which configuration you need.

## Which configuration do I need?

Use the following guide when choosing what to configure:

| Requirement                                                                                                                   | FlowFuse version | What to configure                                                                                                                                                                                                                                                                                                                                                                 |
| ----------------------------------------------------------------------------------------------------------------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Files written directly by the Node-RED instance must survive restart, suspend/resume, or stack upgrades                       | v2.6.0 or later  | Configure [Persistent Storage for Node-RED instances](https://flowfuse.com/#persistent-storage-for-node-red-instances)                                                                                                                                                                                                                                                            |
|                                                                                                                               | Before v2.6.0    | Configure [The File Storage service](https://flowfuse.com/#the-file-storage-service)                                                                                                                                                                                                                                                                                              |
| You want to use [FlowFuse Persistent Context](https://flowfuse.com/docs/user/persistent-context/){rel="&#x22;nofollow&#x22;"} | v2.6.0 or later  | Configure [The File Storage service](https://flowfuse.com/#the-file-storage-service) and the [Persistent Context configuration](https://flowfuse.com/#persistent-context-configuration). If the instance also needs persistent filesystem access, configure [Persistent Storage for Node-RED instances](https://flowfuse.com/#persistent-storage-for-node-red-instances) as well. |
|                                                                                                                               | Before v2.6.0    | Configure [The File Storage service](https://flowfuse.com/#the-file-storage-service) and the [Persistent Context configuration](https://flowfuse.com/#persistent-context-configuration). The File Storage service also provides persistent storage for the instance.                                                                                                              |

## Persistent Storage for Node-RED instances

As part of the FlowFuse v2.6.0 release, a new Persistent Storage approach was implemented for Kubernetes. Docker support will follow.

This mounts a Persistent Volume into the container running the Node-RED instance on `/data/storage`.
Files written to this location are preserved for the life of the instance and across suspend/resume operations and stack upgrades.

If you are using FlowFuse version lower than v2.6.0, you will need to use the File Storage service to provide persistent storage to Node-RED or upgrade to v2.6.0 or later to use this feature.

### Configuring

Create a Kubernetes `StorageClass` that allows dynamic provisioning of `PersistentVolumes` from `PersistentVolumeClaims`, for example the [AWS EFS CSI driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver){rel="&#x22;nofollow&#x22;"}.

Then pass the following values to the FlowFuse Helm Chart when upgrading.

```yaml
forge:
  persistentStorage:
    enabled: true
    storageClass: '<name of StorageClass>'
    size: '5Gi'
```

Where `size` is the default size for the volume.

#### Azure

If you are using the `azurefile-csi` Persistent Storage driver then we recommend adding the following to the `StorageClass mountOptions`:

```yaml
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - mfsymlinks
  - nobrl
```

See [the Azure Kubernetes documentation](https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/storage/mountoptions-settings-azure-files){rel="&#x22;nofollow&#x22;"} for more details.

## The File Storage service

The FlowFuse Platform includes a File Storage service that provides:

- A set of custom File nodes that behave the same way as the standard Node-RED
  File nodes
- An optional Persistent Context store for storing context data within flows.
  This feature is only available for platforms running with a premium license.

On FlowFuse v2.6.0 or later, the File Storage service is used exclusively for Persistent Context. Instance-level Persistent Storage is handled separately via [Persistent Storage for Node-RED instances](https://flowfuse.com/#persistent-storage-for-node-red-instances).

Before FlowFuse v2.6.0, this service was also the primary way to provide persistent storage to Node-RED in container-based environments, in addition to Persistent Context.

::div{.ff-callout.ff-callout--note}
Note

  :::div{.ff-callout__content}
  The File Storage service is only required in Docker or Kubernetes environments. If you are using the LocalFS platform driver, Node-RED already has direct access to the local filesystem.
  :::
::

### Configuring

The File Storage server has its own configuration file: `etc/flowforge-storage.yml`.

- **Docker Compose** - edit the file directly before starting the service
- **Kubernetes/Helm** - include the options in your `customization.yml`, using `forge.fileStore.*` as the property name prefix.
  You must also set `forge.fileStore.enabled` to `true` to tell Helm to deploy the service.

There are three parts to the configuration:

- [Platform Configuration](https://flowfuse.com/#platform-configuration) - how to access the main FlowFuse platform application
- [File Storage service configuration](https://flowfuse.com/#file-storage-service-configuration) - what storage to use for the File nodes
- [Persistent Context configuration](https://flowfuse.com/#persistent-context-configuration) - what storage to use for Persistent Context

### Platform Configuration

| Option     | Description                                                                          |
| ---------- | ------------------------------------------------------------------------------------ |
| `host`     | Where to listen for incoming connections. Default: `0.0.0.0`.                        |
| `port`     | The port to listen on. Default: `3001`                                               |
| `base_url` | The url to access the FlowFuse platform on. This defaults to `http://localhost:3000` |

### File Storage service configuration

The File Storage configuration determines where the files used by the Node-RED File nodes are stored.

You can configure it to store files either on the local filesystem of the File Storage server or in an AWS S3-compatible service.

#### LocalFS

Stores the files locally, for example by using a volume mounted into the File Storage server container.

| Option                | Description                                                                                                    |
| --------------------- | -------------------------------------------------------------------------------------------------------------- |
| `driver.type`         | `localfs`                                                                                                      |
| `driver.quota`        | A per-instance quota for how much data will be stored - in bytes. If this is not set, no limit will be applied |
| `driver.options.root` | The root path under which Node-RED instance data should be stored.                                             |

The following shows an example configuration using the `localfs` file driver.

```yaml
driver:
  type: localfs
  quota: 104857600
  options:
    root: var/root
```

#### S3 Compatible Storage

Stores the files in an external service using the AWS S3 API.

| Option                                      | Description                                                                                                    |
| ------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `driver.type`                               | `s3`                                                                                                           |
| `driver.quota`                              | A per-instance quota for how much data will be stored - in bytes. If this is not set, no limit will be applied |
| `driver.options.bucket`                     | Name of the S3 bucket to use (required)                                                                        |
| `driver.options.region`                     | Name of AWS region of the bucket (required)                                                                    |
| `driver.options.endpoint`                   | S3 ObjectStore Endpoint, if not using AWS S3                                                                   |
| `driver.options.forcePathStyle`             | `true`                                                                                                         |
| `driver.options.credential.accessKeyId`     | Account ID / Username                                                                                          |
| `driver.options.credential.secretAccessKey` | Secret Key / Password                                                                                          |

The full list of valid options under `driver.options` is available in the [AWS S3Client documentation](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-s3/interfaces/s3clientconfig.html){rel="&#x22;nofollow&#x22;"}.

For example:

```yaml
driver:
  type: s3
  quota: 104857600
  options:
    bucket: flowforge-files
    credentials:
      accessKeyId: XXXXXXXXXXXXXXXXXXX
      secretAccessKey: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    forcePathStyle: true
    region: us-east-1
```

#### Enabling the FlowFuse File Nodes

The FlowFuse File nodes have been written to be direct replacements
for the Node-RED core file-in and file-out nodes. This means that only
one version of these nodes can be active in Node-RED at a time.

The FlowFuse File nodes will automatically disable themselves if the
core nodes are present. This means to enable the nodes you need to
exclude the code nodes.

This can be done in the FlowFuse Template.

![](https://flowfuse.com/docs/install/images/file-node-template.png){width="500"}

Adding `10-file.js` to the list of "Excluded nodes by filename" section will ensure that the core file nodes are not loaded by Node-RED.

### Persistent Context configuration

The Context Storage configuration determines where Node-RED Context data is stored.

This feature is only available when running with a FlowFuse Premium license.

Due to the different access patterns for context data, this requires a separate
storage configuration to the File store. It can use either an SQLite or PostgreSQL
database.

#### SQLite

| Option                    | Description                                                                                                    |
| ------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `context.type`            | `sequelize`                                                                                                    |
| `context.quote`           | A per-instance quota for how much data will be stored - in bytes. If this is not set, no limit will be applied |
| `context.options.type`    | `sqlite`                                                                                                       |
| `context.options.storage` | Path to the sqlite database file to use                                                                        |

For example:

```yaml
context:
  type: sequelize
  quota: 1048576
  options:
    type: sqlite
    storage: ff-context.db
```

#### PostgreSQL

| Option                     | Description                                                                                                    |
| -------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `context.type`             | `sequelize`                                                                                                    |
| `context.quote`            | A per-instance quota for how much data will be stored - in bytes. If this is not set, no limit will be applied |
| `context.options.type`     | `postgres`                                                                                                     |
| `context.options.host`     | The hostname of the database server                                                                            |
| `context.options.port`     | The port of the database server                                                                                |
| `context.options.database` | The name of the database to store context data in                                                              |
| `context.options.username` | The username to access to the database with                                                                    |
| `context.options.password` | The password to access to the database with                                                                    |

For example:

```yaml
context:
  type: sequelize
  quota: 1048576
  options:
    type: postgres
    host: flowforge-postgresql
    port: 5432
    database: ff-context
    username: postgres
    password: password
```

## Working with FlowFuse Devices

The FlowFuse Device Agent does *not* use the File Storage service. Any flows
using the file nodes or persistent context that are deployed to a Device will use
the local filesystem directly.


# First-run Setup

Following a successful install, you will be able to access the platform to go
through the initial setup.

## 1. Start setup

### - LocalFS

Open FlowFuse in your browser `http://localhost:3000`

### - Docker or Kubernetes

Open FlowFuse in your browser `http://forge.example.com` (Change `.example.com` to match the domain you set up in DNS)

Click the **START SETUP** button

![](https://flowfuse.com/docs/install/images/setup-01.png){width="500"}

## 2. Create an Administrator

The first user you create will be an Administrator. They will have full access
to the platform, be able to set platform-wide configuration and manage users and teams.

**Note**: with the 0.3 release, it is possible to reset your password *if* you have email
configured and enabled the `user:reset-password` option in Admin settings. Otherwise,
make sure you make a note of the password you set. We will provide tools to manage passwords
outside of the platform in a future release.

![](https://flowfuse.com/docs/install/images/setup-02-user.png){width="500"}

## 3. Upload a license

FlowFuse Community Edition is Open Source and can be used freely without a license.

If you have a FlowFuse Enterprise Edition license you can upload it here.

![](https://flowfuse.com/docs/install/images/setup-03-license.png){width="500"}

## 4. Finish setup

Once you complete the setup, you will be able to log in as the Administrator
user you created and start using the platform. You can setup your Team and
create your first Node-RED instance.

More information about using the FlowFuse platform is available in the
main [user guide](https://flowfuse.com/docs/user/introduction).


# Installing FlowFuse

FlowFuse can be installed to run in Docker or Kubernetes based environments.

- **Docker:**
  - [Quick Start Guide](https://flowfuse.com/docs/quick-start)
  - [Full Install](https://flowfuse.com/docs/install/docker/)
- **Kubernetes:**
  - [Install Guide](https://flowfuse.com/docs/install/kubernetes/)

We also provide one-click installs of the Docker version:

- [Digital Ocean Docker Install Guide](https://flowfuse.com/docs/install/docker/digital-ocean)
- [AWS Docker Install Guide](https://flowfuse.com/docs/install/docker/aws-marketplace)

## Upgrading FlowFuse

If you are upgrading FlowFuse, please refer to the [Upgrade Guide](https://flowfuse.com/docs/upgrade/)
for any specific actions required.

## Do You Need Help? Installation Service

If you need assistance, request our complimentary Installation Service, and we will help you install FlowFuse.


# AWS EKS Specific details

This document includes details of installing FlowFuse on AWS EKS.

The following assumptions have been made in the examples:

1. The user has the correct AWS IAM policy access to complete all tasks
2. All AWS services are running in `eu-west-1`

## Prerequisites

### AWS Cli

This is used to interact with the whole AWS environment

<https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html>{rel="&#x22;nofollow&#x22;"}

From here onwards this document assumes that you have configured the
AWS CLI tools with a user that has permission to carry out the steps.

This document does not include details of how to configure such a user
in AWS IAM. Please show this document to you AWS Account Admin if you
need help.

### eksctl

This tool is used to create/modify AWS EKS Clusters, it uses the credentials from the AWS Cli.

<https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html>{rel="&#x22;nofollow&#x22;"}

## Setup a new domain on Route53

Do this in the AWS Console/Your DNS provider

## Create an AWS Certificate

Request a certificate for `*.[DOMAIN]` from Amazon Certificate Manager

Do this in AWS Console, with Route53 validation

## Create EKS Cluster

Edit the `cluster.yml` file in `aws_eks` to set your preferred instance type and count along with AWS Region

```bash
eksctl create cluster -f cluster.yml
```

Example cluster.yml (Please visit [eksctl.io](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files){rel="&#x22;nofollow&#x22;"} to be sure you understand what this does.)

```yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: FlowFuse
  region: eu-west-1

iam:
  withOIDC: true

addons:
  - name: aws-ebs-csi-driver
    resolveConflicts: overwrite

nodeGroups:
  - name: management
    labels:
      role: "management"
    instanceType: t2.small
    desiredCapacity: 1
    volumeSize: 20
    ssh:
      allow: false
    iam:
      withAddonPolicies:
        ebs: true
  - name: instance
    labels: 
      role: "projects"
    tags:
      k8s.io/cluster-autoscaler/enabled: "true"
      k8s.io/cluster-autoscaler/flowforge: "owned"
    instanceType: t2.small
    desiredCapacity: 2
    volumeSize:
    ssh:
      allow: false
```

## Ingress Controller

### Traefik

It is recommended to run the [Traefik](https://doc.traefik.io/traefik/) even on AWS EKS (The AWS ALB load balancer currently appears to only support up to 100 Ingress Targets which limits the number of Hosted Instances that can be run).

Create a `traefik-values.yaml` file to pass the values to the Traefik helm file.

```bash
touch traefik-values.yaml
```

Fill the `traefik-values.yaml` file with the following content. Replace `<your-certificate-arn>` with the certificate ARN created earlier

```yaml
service:
  enabled: true
  type: LoadBalancer
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<your-certificate-arn>"
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "120"
    service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: "proxy_protocol_v2.enabled=true"
  spec:
    externalTrafficPolicy: Cluster

deployment:
  replicas: 2

ports:
  web:
    port: 8000
    expose:
      default: true
    exposedPort: 80
    protocol: TCP
    forwardedHeaders:
      trustedIPs:
        - "10.0.0.0/8"
    proxyProtocol:
      trustedIPs:
        - "10.0.0.0/8"
  websecure:
    port: 8443
    expose:
      default: true
    exposedPort: 443
    protocol: TCP
    http:
      middlewares:
        - traefik-force-https@kubernetescrd
        - traefik-large-body@kubernetescrd
      # Disable TLS since NLB handles termination
      tls:
        enabled: false
    forwardedHeaders:
      trustedIPs:
        - "10.0.0.0/8"
    proxyProtocol:
      trustedIPs:
        - "10.0.0.0/8"

ingressClass:
  enabled: true
  isDefaultClass: false
  name: traefik

additionalArguments:
  - "--entryPoints.web.proxyProtocol.insecure=true"
  - "--entryPoints.websecure.proxyProtocol.insecure=true"
  - "--entryPoints.web.forwardedHeaders.insecure=true"
  - "--entryPoints.websecure.forwardedHeaders.insecure=true"

providers:
  kubernetesIngress:
    enabled: true
  kubernetesCRD:
    enabled: true

api:
  dashboard: false
  insecure: false

logs:
  access:
    enabled: true
    fields:
      headers:
        defaultMode: keep

extraObjects:
  - apiVersion: traefik.io/v1alpha1
    kind: Middleware
    metadata:
      name: force-https
      namespace: traefik
    spec:
      headers:
        customRequestHeaders:
          X-Forwarded-Proto: "https"
  - apiVersion: traefik.io/v1alpha1
    kind: Middleware
    metadata:
      name: large-body
      namespace: traefik
    spec:
      buffering:
        maxRequestBodyBytes: 10485760
```

Install the Traefik with the following command:

```bash
helm repo add traefik https://traefik.github.io/charts
helm repo update
helm upgrade --install traefik traefik/traefik \
  --create-namespace \
  -n traefik \
  -f traefik-values.yaml \
  --wait \
  --atomic
```

### References

<https://doc.traefik.io/traefik/getting-started/kubernetes/>{rel="&#x22;nofollow&#x22;"}

## AWS ALB Ingress

AWS ALB has a hard limit of 100 Ingress endpoints which limits the number of Projects/Instances that can be deployed.

## Setup AWS SES for email

<https://eu-west-1.console.aws.amazon.com/ses/home?region=eu-west-1#/homepage>{rel="&#x22;nofollow&#x22;"}

Setup identity to match sending domain (requires DNS entries)
Setup email identity to send test emails to
Request move to production from sandbox (need to include examples of emails being sent and why/when those emails will be sent should only need this for prod)

`ses_policy.json` (with suitable aws id, aws region and domain modifications):

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ses:SendEmail",
                "ses:SendTemplatedEmail",
                "ses:SendRawEmail"
            ],
            "Resource": "arn:aws:ses:[aws region]:[aws id]:identity/[domain name]"
        }
    ]
}
```

```bash
IAM_POLICY_ARN=$(aws iam create-policy --policy-name FlowForgeSendEmail --policy-document file://ses_policy.json --output json | jq -r .Policy.Arn)
ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text)
OIDC_PROVIDER=$(aws eks describe-cluster --name flowforge --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")


read -r -d '' TRUST_RELATIONSHIP <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::${ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${OIDC_PROVIDER}:sub": "system:serviceaccount:default:flowforge"
        }
      }
    }
  ]
}
EOF
echo "${TRUST_RELATIONSHIP}" > trust.json

aws iam create-role --role-name flowforge_service_account_role --assume-role-policy-document file://trust.json --description "Role to bind to flowforge service account"

aws iam attach-role-policy --role-name flowforge_service_account_role --policy-arn=$IAM_POLICY_ARN
```

Make a note of the ARN for the IAM Role (flowforge\_service\_account\_role) is needed in the helm chart values yaml file.
`aws iam get-role --role-name flowforge_service_account_role`

### References

Create a IAM Role to bind IAM Policies to the service account <https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html>{rel="&#x22;nofollow&#x22;"}

Create IAM Policy to allow sending emails (example: <https://docs.aws.amazon.com/ses/latest/dg/sending-authorization-policy-examples.html>{rel="&#x22;nofollow&#x22;"})

## Use AWS RDS PostgreSQL instance

The following script creates a AWS RDS PostgreSQL instance, it also
sets up some network access rules so only the FlowFuse app can access
it from inside the cluster (and not the Node-RED instances).

Please read it carefully before running it to ensure you understand it.

A copy of this file can be found [here](https://github.com/FlowFuse/flowforge/blob/f8c06e3cea0ffb539350797af429f1a0366243f1/docs/install/kubernetes/setup-rds.sh){rel="&#x22;nofollow&#x22;"}

Run the following command

```bash
./setup-rds.sh
```

Make a note of the postgres hostname

```bash
aws rds describe-db-instances | jq .DBInstances[].Endpoint.Address
```

### References

<https://dev.to/bensooraj/accessing-amazon-rds-from-aws-eks-2pc3>{rel="&#x22;nofollow&#x22;"}


# FlowFuse-oriented infrastructure in AWS using Terraform and Helm

This step-by-step guide will help you use the Terraform modules available in the FlowFuse repository to setup resources required to run FlowFuse platform on AWS.
After following the commands in this documentation, the following resources will be created:

- [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
- [EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) (Elastic Kubernetes Service)
- [RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) (Relational Database Service)
- [VPC Peering](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html)
- [Route53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) domain zone
- [AWS Certificate](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)
- [SES](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) (Simple Email Service)

The full list of the resources created by each module can be found in the documentation of the respective modules.
To ensure proper infrastructure deployment, these modules must be executed in a specific order: `vpc`, `eks`, `rds`, `vpc-peering`, `route53` and `ses`.
Additionally, a shared variables file (`terraform.tfvars`) will be created to manage configuration used by all modules.

While Terraform supports nested modules for complex infrastructure, this guide will treat each module as a root module for simplicity.
All modules are configurable, allowing you to customize the infrastructure to meet your specific needs. Detailed information on configuring each module can be found in its documentation.
This guide will uses minimal configuration to demonstrate the basic setup.

## Prerequisites

- [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli), [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl), [Helm](https://helm.sh/docs/helm/helm_install/) and
  [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your machine.
- Access to an AWS account through [AWS access key](https://repost.aws/knowledge-center/create-access-key), that allows the creation of new resources. The specific resources created by each module are detailed in the documentation of the respective modules.

## Step 1: Clone the Repository

First, clone the FlowFuse Terraform repository to your local machine:

```bash
git clone https://github.com/FlowFuse/terraform-aws-flowfuse.git
cd terraform-aws-flowfuse
```

## Step 2: Set AWS Environment Variables

Set the following environment variables to authenticate Terraform with your AWS account:

```bash
export AWS_ACCESS_KEY_ID=<your-access-key-id>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
export AWS_REGION=<your-desired-region>
```

Replace `<your-access-key-id>`, `<your-secret-access-key>`, and `<your-desired-region>` with your actual AWS credentials and desired AWS region. All resources must be created in the same region.

For example, if you want to create resources in `us-west-2`, set the region as follows:

```bash
export AWS_REGION=us-west-2
```

Ensure that these environment variables are set for the duration of the session or included in your shell profile to persist across sessions.

## Step 3: Create the `terraform.tfvars` File

Create a `terraform.tfvars` file in the root directory of the repository. This file will contain the shared variables for all the modules.

```bash
touch terraform.tfvars
```

Edit the `terraform.tfvars` file and add the following content.
Replace `<aws-user-arn>` with the [ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) of the AWS user that will have access to the EKS cluster. This user will be granted the `ClusterAdmin` role in the EKS cluster.

```hcl
namespace = "my-company"
stage     = "production"
route53_zone_name = "my-domain.com"
eks_access_entry_map = {
    "<aws-user-arn>" = {
      access_policy_associations = {
        ClusterAdmin = {}
      }
    }
  }
```

## Step 4: Create AWS Resources

**The order of creating resources is important. The documentation specifies the correct order. Attempts to create resources in a different order may fail.**

### 1. VPC Module

To create basic networking, initialize the VPC module:

```bash
terraform -chdir=vpc init
```

Apply the VPC module using the shared variables file:

```bash
terraform -chdir=vpc apply -var-file=../terraform.tfvars
```

### 2. EKS Module

To create EKS cluster, initialize the EKS module:

```bash
terraform -chdir=eks init
```

Apply the EKS module using the shared variables file:

```bash
terraform -chdir=eks apply -var-file=../terraform.tfvars
```

### 3. RDS Module

To create RDS database, initialize the RDS module:

```bash
terraform -chdir=rds init
```

Apply the RDS module using the shared variables file:

```bash
terraform -chdir=rds apply -var-file=../terraform.tfvars
```

### 4. VPC Peering Module

To create a peering between EKS and RDS networks, initialize the VPC Peering module:

```bash
terraform -chdir=vpc-peering init
```

Apply the VPC Peering module using the shared variables file:

```bash
terraform -chdir=vpc-peering apply -var-file=../terraform.tfvars
```

### 5. Route53 Module

To create a domain and certificate, initialize the Route53 module:

```bash
terraform -chdir=route53 init
```

Apply the Route53 module using the shared variables file:

```bash
terraform -chdir=route53 apply -var-file=../terraform.tfvars
```

Remember to change NS records in your domain registrar to the ones provided by the Route53 module.
NS records are printed after the Route53 module is applied.
They can be also printed using the following command:

```bash
terraform -chdir=route53 output domain_dns_records
```

### 6. SES Module

To create an email service, initialize the SES module:

```bash
terraform -chdir=ses init
```

Apply the SES module using the shared variables file:

```bash
terraform -chdir=ses apply -var-file=../terraform.tfvars
```

To get the IAM role ARN created by the SES module and required during [FlowFuse platform configuration](https://flowfuse.com/docs/install/configuration#aws-ses-email), run the following command:

```bash
terraform -chdir=eks output flowfuse_role_arn
```

## Step 5: Deploy Traefik

It is recommended to run the [Traefik](https://doc.traefik.io/traefik/) even on AWS EKS (The AWS ALB load balancer currently appears to only support up to 100 Ingress Targets which limits the number of Hosted Instances that can be run).

Create a `traefik-values.yaml` file for Traefik configuration:

```bash
touch traefik-values.yaml
```

Get the certificate ARN (`<your-certificate-arn>`) from the `route53` module outputs:

```bash
terraform -chdir=route53 output acm_certificate_arn
```

Fill the `traefik-values.yaml` file with the following content. Replace `<your-certificate-arn>` with the certificate ARN.

```yaml
service:
  enabled: true
  type: LoadBalancer
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<your-certificate-arn>"
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "120"
    service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: "proxy_protocol_v2.enabled=true"
  spec:
    externalTrafficPolicy: Cluster

deployment:
  replicas: 2

ports:
  web:
    port: 8000
    expose:
      default: true
    exposedPort: 80
    protocol: TCP
    forwardedHeaders:
      trustedIPs:
        - "10.0.0.0/8"
    proxyProtocol:
      trustedIPs:
        - "10.0.0.0/8"
  websecure:
    port: 8443
    expose:
      default: true
    exposedPort: 443
    protocol: TCP
    http:
      middlewares:
        - traefik-force-https@kubernetescrd
        - traefik-large-body@kubernetescrd
      # Disable TLS since NLB handles termination
      tls:
        enabled: false
    forwardedHeaders:
      trustedIPs:
        - "10.0.0.0/8"
    proxyProtocol:
      trustedIPs:
        - "10.0.0.0/8"

ingressClass:
  enabled: true
  isDefaultClass: false
  name: traefik

additionalArguments:
  - "--entryPoints.web.proxyProtocol.insecure=true"
  - "--entryPoints.websecure.proxyProtocol.insecure=true"
  - "--entryPoints.web.forwardedHeaders.insecure=true"
  - "--entryPoints.websecure.forwardedHeaders.insecure=true"

providers:
  kubernetesIngress:
    enabled: true
  kubernetesCRD:
    enabled: true

api:
  dashboard: false
  insecure: false

logs:
  access:
    enabled: true
    fields:
      headers:
        defaultMode: keep

extraObjects:
  - apiVersion: traefik.io/v1alpha1
    kind: Middleware
    metadata:
      name: force-https
      namespace: traefik
    spec:
      headers:
        customRequestHeaders:
          X-Forwarded-Proto: "https"
  - apiVersion: traefik.io/v1alpha1
    kind: Middleware
    metadata:
      name: large-body
      namespace: traefik
    spec:
      buffering:
        maxRequestBodyBytes: 10485760
```

Update your kubeconfig file to point to the EKS cluster and set the correct context

```bash
aws eks update-kubeconfig --name $(terraform -chdir=eks output -raw cluster_name)
```

Install the Traefik Ingress controller with the following command:

```bash
helm repo add traefik https://traefik.github.io/charts
helm repo update
helm upgrade --install traefik traefik/traefik \
  --create-namespace \
  -n traefik \
  -f traefik-values.yaml \
  --wait \
  --atomic
```

## Conclusion

You have successfully set up the necessary AWS infrastructure to run the FlowFuse platform and performed minimal EKS cluster configuration required.
With this infrastructure in place, your environment is now ready for the installation of the FlowFuse platform. For detailed installation instructions, please visit: [FlowFuse Kubernetes Installation Guide](https://flowfuse.com/docs/install/kubernetes).


# Installing FlowFuse on a Digital Ocean Kubernetes cluster

## Prerequisites

### Digital Ocean Account

You will need an active Digital Oceans Account, you can sign up
for an account [here](https://cloud.digitalocean.com/registrations/new){rel="&#x22;nofollow&#x22;"}

### Utilities

- kubectl - <https://kubernetes.io/docs/tasks/tools/>{rel="&#x22;nofollow&#x22;"}
- helm - <https://helm.sh/docs/intro/install/>{rel="&#x22;nofollow&#x22;"}

### DNS

You will need a domain that FlowFuse will run on and access to configure
a wildcard entry for that domain in it's root DNS server.

In this guide I will use `example.com` as the domain, remember to substitute your domain.

## Create Cluster

- Click on the big green "Create" button at the top of the screen
- Select "Kubernetes" from the list
- Pick a suitable region (normally the one physically closest to you)
- Reduce the number of nodes from 3 to 2
- Reduce the "Node Plan" to 1GB Ram/2vCPU
- Change the cluster name to `k8s-flowforge`
- Hit "Create Cluster" button

When the cluster has finished provisioning you should be able to download
the `k8s-flowforge-kubeconfig.yaml` file which will allow you to connect to the cluster.

## Install Traefik

Prepare values for the Traefik Helm chart by creating a file called `traefik-values.yaml` with the following content:

```yaml
service:
  enabled: true
  type: LoadBalancer
  annotations:
    service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: "true"
  spec:
    externalTrafficPolicy: Cluster

deployment:
  replicas: 2

ports:
  web:
    port: 8000
    expose:
      default: true
    exposedPort: 80
    protocol: TCP
    forwardedHeaders:
      trustedIPs:
        - "10.0.0.0/8"
    proxyProtocol:
      trustedIPs:
        - "10.0.0.0/8"
  websecure:
    port: 8443
    expose:
      default: true
    exposedPort: 443
    protocol: TCP
    http:
      middlewares:
        - traefik-force-https@kubernetescrd
        - traefik-large-body@kubernetescrd
      # Disable TLS since NLB handles termination
      tls:
        enabled: false
    forwardedHeaders:
      trustedIPs:
        - "10.0.0.0/8"
    proxyProtocol:
      trustedIPs:
        - "10.0.0.0/8"

ingressClass:
  enabled: true
  isDefaultClass: false
  name: traefik

additionalArguments:
  - "--entryPoints.web.proxyProtocol.insecure=true"
  - "--entryPoints.websecure.proxyProtocol.insecure=true"
  - "--entryPoints.web.forwardedHeaders.insecure=true"
  - "--entryPoints.websecure.forwardedHeaders.insecure=true"

providers:
  kubernetesIngress:
    enabled: true
  kubernetesCRD:
    enabled: true

api:
  dashboard: false
  insecure: false

logs:
  access:
    enabled: true
    fields:
      headers:
        defaultMode: keep

extraObjects:
  - apiVersion: traefik.io/v1alpha1
    kind: Middleware
    metadata:
      name: force-https
      namespace: traefik
    spec:
      headers:
        customRequestHeaders:
          X-Forwarded-Proto: "https"
  - apiVersion: traefik.io/v1alpha1
    kind: Middleware
    metadata:
      name: large-body
      namespace: traefik
    spec:
      buffering:
        maxRequestBodyBytes: 10485760
```

Install the Traefik with the following command:

```bash
helm repo add traefik https://traefik.github.io/charts
helm repo update
helm --kubeconfig=./k8s-flowforge-kubeconfig.yaml upgrade --install traefik traefik/traefik \
  --create-namespace \
  -n traefik \
  -f traefik-values.yaml \
  --wait \
  --atomic
```

### Setup DNS

Run the following to get the external IP address of the Traefik controller

```bash
kubectl --kubeconfig=./k8s-flowforge-kubeconfig.yaml \
  -n traefik get service traefik
```

You will need to update the entry in your DNS server to point
`*.example.com` to the IP address listed under `EXTERNAL-IP`

## Install Cert-manager

This will use LetsEncrypt to issue certificates for both the FlowFuse application
but also for the Node-RED instances.

```bash
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install \
  --kubeconfig=./k8s-flowforge-kubeconfig.yaml \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.13.3 \
  --set installCRDs=true
```

After installing you will need to create a `ClusterIssuer` to access LetsEncrypt.

Create the following YAML file called `letsencrypt.yml`, please replace
`user@example.com` with your email address.

```yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: user@example.com
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod
    # Enable the HTTP-01 challenge provider
    solvers:
      - http01:
          ingress:
            ingressClassName: traefik
```

Then use `kubectl` to install this

```bash
kubectl --kubeconfig=./k8s-flowforge-kubeconfig.yaml apply -f letsencrypt.yml
```

## Install FlowFuse

Then setup the FlowFuse Helm repository

```bash
helm repo add flowforge https://flowfuse.github.io/helm
helm repo update
```

Now create a `customizations.yml` file. This is how we configure the
FlowFuse instance.

The following is the bare minimum to get started:

```yaml
forge:
  domain: example.com
  https: true
  localPostgresql: true
  projectSelector: 
  managementSelector: 
  broker:
    enabled: true
postgresql:
  global:
    storageClass: do-block-storage
ingress:
  certManagerIssuer: letsencrypt
```

Again, please replace `example.com` with the domain you configured
earlier in the [Setup DNS](https://flowfuse.com/#setup-dns) section

Then we use this to install FlowFuse

```bash
helm upgrade --install --kubeconfig ./k8s-flowforge-kubeconfig.yaml \
  flowforge flowforge/flowforge -f customizations.yml \
  --wait
```

Once complete you should be able to sign into the FlowFuse setup wizard
at `http://forge.example.com`


# Kubernetes Install

This guide walks you through a detailed set up of FlowFuse Platform on a container environment managed by Kubernetes. Typically suited for large on premise deployments or deployment in Cloud infrastructure.
By the end, you will have a fully functioning FlowFuse instance running on a Kubernetes cluster.

# Checklist

::div{.grid.grid-cols-2.gap-8}
  :::div{.checklist}
  Prerequisites


    ::::div
    :checklist-item{task="Domain Name"}
    :checklist-item{task="Kubernetes cluster"}
    :checklist-item{task="Setup Dedicated Database" type="recommended"}
    :checklist-item{task="Prepare TLS Certificates" type="recommended"}
    ::::
  :::

  :::div{.checklist}
  Installation


    ::::div
    :checklist-item{task="Download FlowFuse"}
    :checklist-item{task="Configure FlowFuse"}
    :checklist-item{task="Enable HTTPS" type="recommended"}
    ::::
  :::
::

## Prerequisites

Before you begin, ensure you have the following:

1. **Domain Name & DNS:** A domain name that you own and can configure DNS settings for (explained in [DNS](https://flowfuse.com/#dns))
2. **kubectl:** To manage a Kubernetes cluster you will need a copy of the `kubectl` utility. See the [kubectl install docs](https://kubernetes.io/docs/tasks/tools/){rel="&#x22;nofollow&#x22;"}
3. **Helm:** FlowFuse provides the Helm chart to manage platform deployment. Install it by following the instructions on [their website](https://helm.sh){rel="&#x22;nofollow&#x22;"}
4. **Kubernetes Cluster:**&#x54;he deployment has currently been tested on the following environments:
   - [AWS EKS](https://flowfuse.com/docs/install/kubernetes/aws-terraform)
   - [Digital Ocean](https://flowfuse.com/docs/install/kubernetes/digital-ocean)
   - MicroK8s
5. **Ingress Controller:** Install [Traefik](https://doc.traefik.io/traefik/){rel="&#x22;nofollow&#x22;"} on the cluster.
6. **Cert-Manager:** EMQX requires the CRDs from cert-manager. See the [installation instructions](https://cert-manager.io/docs/installation/){rel="&#x22;nofollow&#x22;"} for details.
7. **EMQX Operator:** This installs the operator that deploys the platform's MQTT broker, which is required whenever the broker is enabled. You must install exactly version 2.2.29 — later versions are not supported. Follow the [installation instructions](https://docs.emqx.com/en/emqx-operator/latest/getting-started/getting-started.html#install-emqx-operator){rel="&#x22;nofollow&#x22;"} and pin the version by adding `--version 2.2.29` to the install command.

For a production-ready environment, we also recommend:

- **Database:** Prepare dedicated database on an external database server (see [FAQ](https://flowfuse.com/#how-to-use-external-database-server) for more details)
- **TLS Certificate:** Prepare a TLS certificate for your domain and configure FlowFuse platform to use it (see [Enable HTTPS](https://flowfuse.com/#i-would-like-to-secure-the-platform-with-https-how-can-i-do-that))

### Hardware requirements

For a Kubernetes-based deployment, resource requirements depend on the number of FlowFuse and Node-RED instances running. As a baseline, we suggest:

Control Plane: At least 2 vCPUs, 4 GB RAM
Worker Nodes: Minimum 2 vCPUs, 4 GB RAM per node, 2 nodes for high availability
Storage: 20Gb of host storage (for container images), StorageClass of your choice available for Hosted Node-RED instances (optional)

Each Node-RED instance you host will use 0.1 CPU cores and 256 MB of memory by default. These parameters can be adjusted in admin area of FlowFuse platform. Keep this in mind when sizing your hardware, especially if you plan to create multiple hosted instances.

### DNS

You will need a [wildcard DNS entry](https://en.wikipedia.org/wiki/Wildcard_DNS_record){rel="&#x22;nofollow&#x22;"}
pointing to the domain that is used for the project instances. This will need to point
to the kubernetes Ingress controller.

For example if you want projects to be accessible as `[instance-name].example.com`
you will need to ensure that `*.example.com` is mapped to the IP address used by
your Kubernetes cluster's Ingress controller.

By default the FlowFuse application will be mapped to `forge.example.com` assuming
that you set the domain to `example.com`.

Notes on how to setup DNS can be found [here](https://flowfuse.com/docs/install/dns-setup).

## Installing FlowFuse

### Add FlowFuse Helm Repository

```bash
helm repo add flowfuse https://flowfuse.github.io/helm
helm repo update
```

### Customize Helm Chart

All the initial configuration is handled by the Helm chart. This is done by creating a `customization.yml` file that will be passed to the Helm along with the chart.

To create `customization.yml` file with a minimal required configuration (replace `example.com` with your domain):

```bash
cat <<EOF > customization.yml
forge:
  entryPoint: forge.example.com
  domain: example.com
  https: false
  localPostgresql: true
EOF
```

A full list of all the configuration options can be found in the [Helm Chart README](https://github.com/FlowFuse/helm/blob/main/helm/flowfuse/README.md#configuration-values){rel="&#x22;nofollow&#x22;"}.

### Label Nodes

By default FlowFuse platform expects that Kubernetes nodes have specific labels applied. The main reason behind this approach is to separate core application components from Node-RED instances.

You will need to label at least one node to run the management application and one to run the Node-RED Projects:

List all nodes in the cluster:

```bash
kubectl get nodes
```

Label management nodes:

```bash
kubectl label node <management-node-name> role=management
```

Label project nodes:

```bash
kubectl label node <projects-node-name> role=projects
```

To override this behavior, you can remove the node selectors with the following entry in the `customization.yml` file which will mean that all pods can run on any nodes.

```yaml [customization.yml]
forge:
  projectSelector:
  managementSelector:
```

## Start FlowFuse Platform

Once you have the `customization.yml` file created, you can install FlowFuse using our Helm chart. This will automatically create all required objects and start services:

```bash
helm upgrade --atomic --install --timeout 10m flowfuse flowfuse/flowfuse -f customization.yml
```

## First Run Setup

The first time you access the platform in your browser, it will take you through
creating an administrator for the platform and other configuration options.

For more information, follow [this guide](https://flowfuse.com/docs/install/first-run).

Once you have finished setting up the admin user there are some [Kubernetes specific items to consider](https://flowfuse.com/#common-questions).

## Upgrade

All technical aspects of the upgrade process of Flowfuse application running on Kubernetes and managed by Helm chart are maintained in our repository.
Please refer to the [Flowfuse Helm Chart documentation](https://github.com/FlowFuse/helm/blob/main/helm/flowfuse/README.md#upgrading-chart){rel="&#x22;nofollow&#x22;"} for more details
about the upgrade process.

## Common Questions

### I would like to secure the platform with HTTPS, how can I do that?

In cloud environments, it is recommended to use a Load Balancer to terminate SSL traffic.

However, if you want to use SSL termination on the Kubernetes Ingress Controller, this is possible by using the [Cert-Manager](https://cert-manager.io/docs/){rel="&#x22;nofollow&#x22;"} tool (not part of the FlowFuse Helm chart).

Once you have Cert-Manager installed, you can enable TLS support in the `customization.yml` file by specifying the [ClusterIssuer](https://cert-manager.io/docs/configuration/#cluster-resource-namespace){rel="&#x22;nofollow&#x22;"} name:

```yaml [customization.yml] {2}
ingress:
  clusterIssuer: <your-cluster-issuer>
```

Apply changes with [platform startup command](https://flowfuse.com/#start-flowfuse-platform).

#### Using Internal/Private Certificate Authorities

If you are issuing your own HTTPS certificates (rather than using a Public Certificate Authority) you will need to tell the Hosted Node-RED Instances to trust this CA. To do this you need to pass base64 encoded CA certificate chain to the helm chart in the `customization.yml`. Details are in the Helm chart [README.md](https://github.com/FlowFuse/helm/blob/main/helm/flowfuse/README.md#private-certificate-authority){rel="&#x22;nofollow&#x22;"}.

```yaml [customization.yml] {3}
forge:
  privateCA:
    certs: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk...
```

Assuming the certificate chain is held in `chain.pem` the value would be created by running `base64 -w 0 certs.pem`

### I use Kubernetes Network Policies, how can I configure them?

If your cluster uses Network Policies to restrict traffic between namespaces, you'll need to create appropriate policies.

Here's an example Network Policy that allows traffic from the `flowforge` namespace (default namespace for Node-RED instances) to the `flowfuse` namespace:

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-flowforge-to-flowfuse
  namespace: flowfuse
spec:
  podSelector: {}
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: flowforge
  policyTypes:
    - Ingress
```

You may need to adjust this policy based on your specific network requirements and namespace configuration.

### How to use external database server?

FlowFuse platform uses PostgreSQL database to store its data. By default, the Helm chart creates and manages the internal database instance.

If you want to use an external database server, you need to edit `customization.yml` file and provide the database connection details:

```yaml [customization.yml] {2}
forge:
  localPostgresql: false # Disable internal database
postgresql:
  host: <database-host>
  port: <database-port>
  auth:
    username: <database-username>
    password: <database-password>
    database: <database-name>
```

Apply changes with [platform startup command](https://flowfuse.com/#start-flowfuse-platform).

Check the [FlowFuse Helm chart documentation](https://github.com/FlowFuse/helm/tree/main/helm/flowfuse#postgresql){rel="&#x22;nofollow&#x22;"} for more details about the parameters that can be configured for the PostgreSQL database.

### How to backup embedded database?

If you are using the internal database (value `forge.localPostgresql` set to `true`), you can use Kubernetes [CronJobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/){rel="&#x22;nofollow&#x22;"} to backup the database.

Apply below `CronJob` and `PersistentVolumeClaim` definitions to create a backup job which will be executed every day at 23:05 and store the backup in a PVC named `db-backup-pvc`:

```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-backup-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: postgres-backup
spec:
  schedule: "5 23 * * *"
  jobTemplate:
    spec:
      ttlSecondsAfterFinished: 60
      template:
        metadata:
          labels:
            app: flowforge
        spec:
          containers:
          - name: backup
            image: postgres
            env:
            - name: PGPASSWORD
              valueFrom:
                secretKeyRef:
                  name: flowfuse-postgresql
                  key: postgres-password
            command:
            - /bin/sh
            - -c
            - |
              pg_dump -h flowfuse-postgresql -U postgres -d flowforge -F c -b -v -f /backup/db_backup.dump
            volumeMounts:
            - name: backup-volume
              mountPath: /backup
          restartPolicy: OnFailure
          volumes:
          - name: backup-volume
            persistentVolumeClaim:
              claimName: db-backup-pvc
```

### I would like to invite my team members to the platform with e-mail, how can I do that?

FlowFuse platform allows you to invite team members to the platform using their e-mail addresses.
To enable this feature, you need to configure the e-mail settings in the `customization.yml` file.

Check this [page](https://flowfuse.com/docs/install/configuration#email-configuration) for more details about the parameters.
Check [FlowFuse Helm chart documentation](https://github.com/FlowFuse/helm/tree/main/helm/flowfuse#email){rel="&#x22;nofollow&#x22;"} for information where configuration values should be placed in `customization.yml` file.

If you use AWS EKS (Elastic Kubernetes Service) and want to use AWS SES (Simple Email Service) for sending e-mails, you need to provide the IAM role with the required permissions to use SES.

```yaml [customization.yml] {6}
forge:
  entryPoint: forge.example.com
  domain: example.com
  cloudProvider: aws
  aws:
    IAMRole: arn:aws:iam::<aws-account-id>:role/flowforge_service_account_role
  email:
    ses:
      region: eu-west-1
```

Apply changes with [platform startup command](https://flowfuse.com/#start-flowfuse-platform).

### I would like to use embedded MQTT broker, how can I do that?

Click to expand

The FlowFuse Helm chart provides the MQTT broker service.
To enable the MQTT broker you need to add the following to the \`customization.yml\` file:
\`\`\`yaml \[customization.yml]
forge:
broker:
enabled: true
\`\`\`
Apply changes with \[platform startup command]\(#start-flowfuse-platform).
Check the \[FlowFuse Helm chart documentation]\(https\://github.com/FlowFuse/helm/tree/main/helm/flowfuse#mqtt-broker) for more details about the parameters that can be configured for the MQTT broker.


### I would like to use Kubernetes Persistent storage to store data, how can I do that?

Starting with the `2.6.0` release the Pods running the Node-RED Instances have a Persistent Volume mounted on `/data/storage` in which files can be written.
These files will persist for the lifetime of the Instance including across Suspend/Resume and Stack upgrades.

To enable this feature the following configuration needs to be added to the `customization.yml` file (replace ' :storage-class-name[' with the name of the StorageClass you have in the cluster):]

```yaml [customization.yml] {5}
forge:
  persistentStorage:
    enabled: true
    size: 5Gi
    storageClass: <storage-class-name>
```

Apply changes with [platform startup command](https://flowfuse.com/#start-flowfuse-platform).

### I would like to use FlowFuse File Storage to store context data, how can I do that?

To enable the FlowFuse File Storage component add the following to the `customization.yml` file:

```yaml [customization.yml]
forge:
  fileStore:
    enabled: true
```

Apply changes with [platform startup command](https://flowfuse.com/#start-flowfuse-platform).

Check the [FlowFuse Helm chart documentation](https://github.com/FlowFuse/helm/tree/main/helm/flowfuse#file-storage){rel="&#x22;nofollow&#x22;"} for more details about the parameters that can be configured for the File Storage.

### I would like to run FlowFuse on AWS EKS. Do you have any guidance?

Yes, we have a dedicated guide on how to deploy FlowFuse on AWS EKS. You can find it [here](https://flowfuse.com/docs/install/kubernetes/aws).
Furthermore, we also provide terraform scripts to automate the deployment process of all required AWS service. You can find the guide [here](https://flowfuse.com/docs/install/kubernetes/aws-terraform).


# Ingress Controller Migration

::div{.ff-callout.ff-callout--note}
Note

  :::div{.ff-callout__content}
  This guide should not be treated as a one-size-fits-all solution. Consider it as a blueprint and adapt it to your specific Kubernetes cluster setup.
  Test the migration in a testing/staging environment before applying it to production.

  If you have any questions about the migration, please contact <support@flowfuse.com>.
  :::
::

This document describes how to migrate a FlowFuse Platform Kubernetes deployment from the NGINX Ingress Controller to Traefik.

The main reason for this migration is [the retirement of Ingress NGINX](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/){rel="&#x22;nofollow&#x22;"} by the Kubernetes project due to long-term maintenance and security sustainability challenges. Best-effort maintenance continues only until March 2026, after which there will be no further releases, bug fixes, or security updates.

It describes a DNS-based migration approach where the actual traffic switch happens at the domain level by changing DNS records to point to the new ingress controller.
It is based on the FlowFuse Ingress Migration Tool and using the ingress classes separation capability provided by the FlowFuse Helm chart:

- Hosted Instances (project ingresses) via `forge.projectIngressClassName`
- Core application components via `ingress.className`

That separation allows you to migrate project traffic and core application traffic in stages.

## Prerequisites

Before you begin, ensure you have the following:

1. A working FlowFuse deployment installed with the `flowfuse/flowfuse`Helm chart
   - note down the FlowFuse Platform Helm release name and namespace, guide uses `<flowfuse-release-name>` and `<flowfuse-release-namespace>` placeholders for these values.
2. Access to the Helm values file used for your deployment
   - note down the path to the values file, guide uses `<flowfuse-values-file>` placeholder as a reference
3. `kubectl` and `helm` configured for the target cluster
4. A new Traefik ingress controller installed alongside the existing NGINX ingress controller. Check our [ingress installation guide](https://flowfuse.com/docs/install/kubernetes/aws/#ingress-controller){rel="&#x22;nofollow&#x22;"} for instructions on how to do this.
5. Access to the DNS records for:
   - the FlowFuse application domain
   - the wildcard domain used by Hosted Instances
6. A maintenance window

We also recommend the following before starting the migration:

- Reduce DNS TTL values in advance to minimize propagation delay
- Do not create new Hosted Instances during the migration window
- Test the procedure in a non-production cluster first

## Important notes

The FlowFuse Helm chart provides an ingress migration job controlled by the `ingressMigration` values block.

The migration job operates on:

- the project namespace (`forge.projectNamespace`)
- the release namespace, but only in `copy` mode

This guide therefore separates the process into two phases:

1. Copy existing ingress resources to the new ingress class
2. Clean up old ingress resources after traffic has moved

## Step 1: Install Traefik alongside NGINX

Install Traefik without removing the existing NGINX ingress controller. Check our [ingress installation guide](https://flowfuse.com/docs/install/kubernetes/aws/#ingress-controller){rel="&#x22;nofollow&#x22;"} for instructions on how to do this.

Before continuing, verify that both ingress controllers are running.
Also, write down the ingress class name used by Traefik, as you will need it for the migration configuration:

```bash
kubectl get ingressclass
```

## Step 2: Record the Traefik LoadBalancer address

You will need the public address of the new ingress controller before changing DNS.

For example, list services in the Traefik namespace:

```bash
kubectl get svc -n traefik
```

Record the external hostname or IP address of the Traefik LoadBalancer service.

## Step 3: Run the migration job in dry-run mode

Start by enabling the migration tool in `copy` mode with `dryRun: true`.

Update your values file:

```yaml
ingressMigration:
  enabled: true
  mode: copy
  dryRun: true
  newIngressClassName: traefik
  nameSuffix: -tfk
```

Then run the Helm upgrade:

```bash
helm upgrade --install <flowfuse-release-name> flowfuse/flowfuse -n <flowfuse-release-namespace> -f <flowfuse-values-file>
```

After the upgrade completes, inspect the Job created by the chart in the release namespace.
The Job name is generated by Helm, so first list the Jobs:

```bash
kubectl get jobs -n <flowfuse-release-namespace>
```

Then inspect the logs of the migration job:

```bash
kubectl logs -n <flowfuse-release-namespace> job/<migration-job-name>
```

Verify that the dry run identifies all Ingress resources.

## Step 4: Optionally scale down Traefik before copying resources

If your environment allows it, and especially if you have many ingress resources, you can temporarily scale Traefik down before executing the ingress resources copy step.

This is optional, but it can reduce repeated Traefik configuration reloads during the migration.

Example:

```bash
kubectl -n traefik scale deployment traefik --replicas 0
```

Only do this if your Kubernetes cluster hosts the FlowFuse Platform and stopping Traefik will not cause a downtime for other applications.

## Step 5: Copy ingress resources to the new ingress class

Once the dry run has been validated, disable dry-run mode and run the actual ingress resources copy.

Update your values file:

```yaml
ingressMigration:
  enabled: true
  mode: copy
  dryRun: false
  newIngressClassName: traefik
  nameSuffix: -tfk
```

Run the Helm upgrade again:

```bash
helm upgrade --install <flowfuse-release-name> flowfuse/flowfuse -n <flowfuse-release-namespace> -f <flowfuse-values-file>
```

This creates new Ingress resources that point to the new ingress class and use the configured suffix.

## Step 6: Scale Traefik back up

If you scaled Traefik down in step 4, scale it back up now.

Example:

```bash
kubectl -n traefik scale deployment traefik --replicas 2
```

Use the replica count that matches your environment.

## Step 7: Change DNS to point to Traefik

Update the DNS records used by the FlowFuse Platform so that incoming traffic is sent to the Traefik LoadBalancer address recorded earlier.

This includes:

- the FlowFuse application hostname (e.g. `forge.example.com`)
- the wildcard DNS record used by Hosted Instances (e.g. `*.example.com`)

Do not proceed to cleanup until you have confirmed that DNS is resolving to the new ingress controller.

## Step 8: Make new Hosted Instances use Traefik

After the copied ingress resources are in place, update the project ingress class so that newly created Hosted Instances use Traefik.

Add or update the following value in the FlowFuse Helm values file:

```yaml
forge:
  projectIngressClassName: traefik
```

Apply the change:

```bash
helm upgrade --install <flowfuse-release-name> flowfuse/flowfuse -n <flowfuse-release-namespace> -f <flowfuse-values-file>
```

## Step 9: Wait for DNS propagation and validate traffic

Allow time for DNS propagation according to your TTL settings.

During this period, validate the migration by checking:

- the FlowFuse Platform is reachable
- Hosted Instances are reachable
- TLS certificates are served correctly
- Traefik logs and metrics do not show routing errors
- Ingress NGINX logs do not show incoming traffic

Do not continue to cleanup until traffic is consistently served by Traefik. Otherwise, you risk potential downtime of the FlowFuse Platform and Hosted Instances.

## Step 10: Move core application components to Traefik

Once you are confident that the Traefik ingress controller is handling all the incoming traffic, update the ingress class used by the core application components.

Add or update the following value in the FlowFuse Helm values file:

```yaml
ingress:
  className: traefik
```

Apply the change:

```bash
helm upgrade --install <flowfuse-release-name> flowfuse/flowfuse -n <flowfuse-release-namespace> -f <flowfuse-values-file>
```

## Step 11: Optionally scale down NGINX

If the NGINX ingress controller is still used for resources outside FlowFuse, leave it in place.

If it is no longer needed, you can scale it down after you have confirmed that FlowFuse Platform traffic is fully handled by Traefik.

Example:

```bash
kubectl -n <nginx-namespace> scale deployment <nginx-deployment> --replicas 0
```

If your Ingress-Nginx installation created admission webhooks and you are about to retire that controller entirely soon, remove those webhook resources.

Examples:

```bash
kubectl delete validatingwebhookconfiguration <nginx-validating-webhook-name>
kubectl delete mutatingwebhookconfiguration <nginx-mutating-webhook-name> --ignore-not-found
```

## Step 12: Clean up old ingress resources

After traffic has fully moved to Traefik, switch the migration tool to `cleanup` mode.

In this mode, the tool removes old ingress resources and renames the migrated ones back to their original names.
This step can cause a short interruption while Kubernetes updates the resources.

Update your values file:

```yaml
ingressMigration:
  enabled: true
  mode: cleanup
  dryRun: false
  oldIngressClassName: nginx
  newIngressClassName: traefik
  nameSuffix: -tfk
```

Run the Helm upgrade again:

```bash
helm upgrade --install <flowfuse-release-name> flowfuse/flowfuse -n <flowfuse-release-namespace> -f <flowfuse-values-file>
```

If you want to validate the cleanup plan first, run the same configuration with `dryRun: true` before applying it.

## Step 13: Remove any remaining suffixed ingress resources from the release namespace

The migration job in `copy` mode creates new ingress resources with a suffix in the release namespace.
In `cleanup` mode, the job deletes old ingress resources and renames the new ones to match the original names, but it does not remove the suffixed copies from the release namespace.
This is to avoid any potential issues with the release namespace if it contains non-ingress resources or custom configurations.
Because of that, after cleanup you should inspect the release namespace and remove any remaining suffixed ingress resources that were copied there.

List ingress resources in the release namespace:

```bash
kubectl get ingress -n <flowfuse-release-namespace>
```

If any copied ingress resources with the migration suffix still exist (`-tfk`), delete them manually:

```bash
kubectl delete ingress <ingress-name> -n <flowfuse-release-namespace>
```

## Step 14: Disable the migration job

After the migration and cleanup are complete, disable the migration tool:

```yaml
ingressMigration:
  enabled: false
```

Apply the change one final time:

```bash
helm upgrade --install <flowfuse-release-name> flowfuse/flowfuse -n <flowfuse-release-namespace> -f <flowfuse-values-file>
```

## Related configuration values

This guide uses the following FlowFuse Helm chart values:

- `ingress.className`
- `forge.projectIngressClassName`
- `ingressMigration.enabled`
- `ingressMigration.mode`
- `ingressMigration.dryRun`
- `ingressMigration.newIngressClassName`
- `ingressMigration.oldIngressClassName`
- `ingressMigration.nameSuffix`

For the full list of ingress migration options, refer to the [FlowFuse Helm chart README](https://github.com/FlowFuse/helm/blob/main/helm/flowfuse/README.md#ingress-migration-tool){rel="&#x22;nofollow&#x22;"}.

## Need help?

If you would like guidance on planning this migration, we can provide migration consultation. To discuss this option, contact <support@flowfuse.com>.

## Resources

- [Ingress Nginx retirement announcement](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/){rel="&#x22;nofollow&#x22;"}
- [Zero-downtime Ingress controller migration guide](https://georg-schwarz.com/blog/zero-downtime-ingress-controller-migration-kubernetes/){rel="&#x22;nofollow&#x22;"}
- [Migrate from Ingress NGINX Controller to Traefik](https://doc.traefik.io/traefik/migrate/nginx-to-traefik/){rel="&#x22;nofollow&#x22;"}


# OpenShift Install

This guide walks you through detailed set up of FlowFuse Platform on a container envoronment managed by OpenShift. Typically suited for large on premise deployments or deployment in Cloud infrastructure.
By the end, you will have a fully functioning FlowFuse instance running on a OpenShift cluster.

# Checklist

::div{.grid.grid-cols-2.gap-8}
  :::div{.checklist}
  Prerequisites


    ::::div
    :checklist-item{task="Domain Name"}
    :checklist-item{task="OpenShift cluster"}
    :checklist-item{task="FlowFuse License"}
    :checklist-item{task="Setup Dedicated Database" type="recommended"}
    :checklist-item{task="Prepare TLS Certificates" type="recommended"}
    ::::
  :::

  :::div{.checklist}
  Installation


    ::::div
    :checklist-item{task="Download FlowFuse"}
    :checklist-item{task="Configure FlowFuse"}
    :checklist-item{task="Enable HTTPS" type="recommended"}
    ::::
  :::
::

## Prerequisites

Before you begin, ensure you have the following:

1. **Domain Name & DNS:** A domain name that you own and can configure DNS settings for (explained in [DNS](https://flowfuse.com/#dns))
2. **oc:** To manage a OpenShift cluster you will need a copy of the `oc` utility. Instructions on how to install `oc` can be found [here](https://docs.openshift.com/container-platform/4.17/cli_reference/openshift_cli/getting-started-cli.html){rel="&#x22;nofollow&#x22;"}
3. **Helm:** FlowFuse provides the Helm chart to manage platform deployment. Installation can be done through the instructions on [their website](https://helm.sh){rel="&#x22;nofollow&#x22;"}
4. **OpenShift Cluster:** an OpenShift cluster instance with at least two worker nodes
5. **Ingress Controller:** [The Traefik](https://doc.traefik.io/traefik/){rel="&#x22;nofollow&#x22;"} installed on the cluster.
6. **FlowFuse License:** A valid FlowFuse license key is required to run on OpenShift. You can request a quote [here](https://flowfuse.com/pricing/request-quote/){rel="&#x22;nofollow&#x22;"}

For a production-ready environment, we also recommend:

- **Database:** Prepare dedicated database on a external database server (see [FAQ](https://flowfuse.com/docs/install/kubernetes#how-to-use-external-database-server) for more details)
- **TLS Certificate:** Prepare TLS certificate for your domain and configure FlowFuse platform to use it (see [Enable HTTPS](https://flowfuse.com/docs/install/kubernetes#i-would-like-to-secure-the-platform-with-https-how-can-i-do-that))

### DNS

A [wildcard DNS entry](https://en.wikipedia.org/wiki/Wildcard_DNS_record){rel="&#x22;nofollow&#x22;"} will be needed
to point to the domain that is used for the project instances. This will need to point
to the Ingress controller.

For example if you want projects to be accessible as `[instance-name].example.com`
you will need to ensure that `*.example.com` is mapped to the IP address used by
your OpenShift clusters's Ingress controller.

By default the FlowFuse application will be mapped to `forge.example.com` assuming
that you set the domain to `example.com`.

Notes on how to setup DNS can be found [here](https://flowfuse.com/docs/install/dns-setup).

## Installing FlowFuse

### Create project in the OpenShift cluster

To maintain a clean environment, it is recommended to create a new project for the FlowFuse platform:

```bash
oc new-project flowfuse --description="FlowFuse Platform" --display-name="FlowFuse"
```

Describe the project to get the SCC information:

```bash
oc describe project flowfuse
```

Note the `openshift.io/sa.scc.uid-range` and `openshift.io/sa.scc.supplemental-groups` values. You will need to use these values when customizing the FlowFuse platform installation.
In example, if the `openshift.io/sa.scc.uid-range` value is `1000710000/10000`, the `<project-uid>` value will be `1000710000`.

### Add FlowFuse Helm Repository

```bash
helm repo add flowfuse https://flowfuse.github.io/helm
helm repo update
```

### Customize Helm Chart

All the initial configuration is handled by the Helm chart. This is done by creating a `customization.yml` file that will be passed to the Helm along with the chart.

To create `customization.yml` file with a minimal required configuration (replace `example.com` with your domain
and `<project-uid>` with the value from the project description collected on [project creation step](https://flowfuse.com/#create-project-in-the-openshift-cluster)):

```bash
cat <<EOF > customization.yml
forge:
  entryPoint: forge.example.com
  domain: example.com
  https: false
  localPostgresql: true
  cloudProvider: openshift
  podSecurityContext:
    runAsUser: <project-uid>
    runAsGroup: <project-uid>
    fsGroup: <project-uid>

postgresql:
  primary:
    podSecurityContext:
      fsGroup: <project-uid>
    containerSecurityContext:
      runAsUser: <project-uid>
EOF
```

A full list of all the configuration options can be found in the [Helm Chart README](https://github.com/FlowFuse/helm/blob/main/helm/flowfuse/README.md#configuration-values){rel="&#x22;nofollow&#x22;"}.

### Label Nodes

By default FlowFuse platform expects that worker nodes have specific labels applied. The main reason behind this approach is to separate core application components from Node-RED instances.

You will need to label at least one node to run the management application and one to run the Node-RED Projects:

List all nodes in the cluster:

```bash
oc get nodes
```

Label management nodes:

```bash
oc label node <management-node-name> role=management
```

Label project nodes:

```bash
oc label node <projects-node-name> role=projects
```

To override this behavior, you can remove the node selectors with the following entry in the `customization.yml` file which will mean that all pods can run on any nodes.

```yaml
forge:
  projectSelector:
  managementSelector:
```

## Start FlowFuse Platform

Once you have the `customization.yml` file created, you can install FlowFuse using our Helm chart. This will automatically create all required objects and start services:

```bash
helm upgrade --atomic --install --timeout 10m flowfuse flowfuse/flowforge -f customization.yml
```

## First Run Setup

The first time you access the platform in your browser, it will take you through
creating an administrator for the platform and other configuration options.

For more information, follow [this guide](https://flowfuse.com/docs/install/first-run).

Once you have finished setting up the admin user there are some [Kubernetes specific items to consider](https://flowfuse.com/#common-questions).

## Upgrade

All technical aspects of the upgrade process of Flowfuse application running on Kubernetes and managed by Helm chart are maintained in our repository.
Please refer to the [Flowfuse Helm Chart documentation](https://github.com/FlowFuse/helm/blob/main/helm/flowfuse/README.md#upgrading-chart){rel="&#x22;nofollow&#x22;"} for more details
about the upgrade process.

## Common Questions

For non-OpenShift specific questions, please refer to the [main kubernetes documentation](https://flowfuse.com/docs/install/kubernetes#common-questions).

### I would like to use embeded MQTT broker, how can I do that?

Click to expand

The FlowFuse Helm chart provides the MQTT broker service.
To enable the MQTT broker you need to add the following to the \`customization.yml\` file
(replace the \` :project-uid[\` with the value from the project description collected on \[project creation step\](#create-project-in-the-openshift-cluster)):
\`\`\`yaml
forge:
broker:
enabled: true
podSecurityContext:
runAsUser: :project-uid[runAsGroup: :project-uid[fsGroup: :project-uid[\`\`\`
Apply changes with \[platform startup command\](#start-flowfuse-platform).
Check the \[FlowFuse Helm chart documentation\](https://github.com/FlowFuse/helm/tree/main/helm/flowfuse#mqtt-broker) for more details about the parameters that can be configured for the MQTT broker.
]]]]

### I would like to use FlowFuse File Storage to store context data, how can I do that?

Click to expand

To enable the FlowFuse File Storage component add the following to the \`customization.yml\` file
(replace the \` :project-uid[\` with the value from the project description collected on \[project creation step\](#create-project-in-the-openshift-cluster)):
\`\`\`yaml
forge:
fileStore:
enabled: true
podSecurityContext:
runAsUser: :project-uid[runAsGroup: :project-uid[fsGroup: :project-uid[\`\`\`
Apply changes with \[platform startup command\](#start-flowfuse-platform).
Check the \[FlowFuse Helm chart documentation\](https://github.com/FlowFuse/helm/tree/main/helm/flowfuse#file-storage) for more details about the parameters that can be configured for the File Storage.
]]]]


# Kubernetes Stacks

A Stack defines a set of platform configuration options that will get
applied to each Node-RED instance when created.

For container based deployment models, this covers three things:

- `memory` - the amount of memory (in MB) to limit container to. Recommended minimum: `256`.
- `cpu` - a value between 1 and 100 that is the % of a CPU core the container should be allowed to consume.
- `container location` - this is the fully qualified name of the container to use. The default container built when following the install instructions is named `flowfuse/node-red:latest`

If you wish to use different Node-RED version, you need to specify the name of the container and the version you want to use. For example, if you want to use Node-RED v3.1.x, you should enter `flowfuse/node-red:latest-3.1.x` in the `container location` section of the Stack configuration.
Full list of available pre-built containers can be found on [Docker Hub](https://hub.docker.com/r/flowfuse/node-red/tags){rel="&#x22;nofollow&#x22;"}.

## Creating Own Containers

As mentioned in the previous paragraph, we encourage to use our pre-built containers in your stacks.
However, if you want to create your own container, you can do so by creating a `Dockerfile` and `package.json` files.
There is an example `Dockerfile` and `package.json` in the [node-red-container](https://github.com/FlowFuse/helm/tree/main/node-red-container){rel="&#x22;nofollow&#x22;"}
directory of the [helm](https://github.com/FlowFuse/helm){rel="&#x22;nofollow&#x22;"} project. This will start with `nodered/node-red:latest`
as it's base and then add the required FlowFuse components.

Builds of this container for amd64, arm64 and armv7 are built for every release and published to Docker hub as [flowfuse/node-red](https://hub.docker.com/r/flowfuse/node-red){rel="&#x22;nofollow&#x22;"}. These can be used as a base to build custom stacks.

If you wanted to pin at Node-RED v3.0.2 you would change the first line to:

```docker
FROM nodered/node-red:3.0.2

ARG REGISTRY
RUN if [[ ! -z "$REGISTRY" ]] ; then npm config set @flowfuse:registry "$REGISTRY"; fi

COPY package.json /data
...
```

To add nodes to the default image you can extend the supplied container.
The following Dockerfile will install the node-red-dashboard

```docker
FROM flowfuse/node-red

WORKDIR /usr/src/node-red
RUN npm install node-red-dashboard

WORKDIR /usr/src/flowforge-nr-launcher
```

To build the container run the following:

```shell
docker build node-red-container/Dockerfile-dashboard -t [your.container.registry]/flowfuse/node-red-dashboard:3.0.2
docker push [your.container.registry]/flowfuse/node-red-dashboard:3.0.2
```

You would then enter `[your.container.registry]/flowforge/node-red-dashboard:3.0.2` in the `container` section
of the Stack configuration.

Stacks can be changed on a per Node-RED instance basis, see also the
[user stack documentation](https://flowfuse.com/docs/user/changestack).


# Migrating a Node-RED application to FlowFuse

This guide will help you to move existing Node-RED instances into
FlowFuse.

When migrating your Node-RED instances into FlowFuse, you'll export
the flows, credentials, and environment variables.

Before you start ensure you can log in to FlowFuse Cloud or your own FlowFuse
server, and that you have created your Node-RED instance that you wish to move into FlowFuse.

If you have not yet created a Node-RED instance that you want to manage within FlowFuse, you can create the new instance within FlowFuse directly, and the following instructions will not apply in your case.

## Migrating the flows and credentials

Install the Node-RED tools plugin as explained
[in the documentation](https://flowfuse.com/docs/migration/node-red-tools). After you created a snapshot for
the Node-RED instance you wish to move, you'll have copied over the flows and credentials.

## Migrating Environment Variables

You can use [this flow](https://flows.nodered.org/flow/8ebfe9ae218aa5105e7da13db14ac272){rel="&#x22;nofollow&#x22;"}
to dump a list of your environment variables into the debug window. For each
variable needed for the flow should be added on FlowFuse under
Instance > Settings > Environment tabs.

## Starting the snapshot

Under the snapshots tab, click 'Restore Snapshot' in the kebab menu. The migrated flows
will now be started with the modules installed.

## Limitations

### Static Files

Check your `settings.js` file to see if `httpStatic` has been set, if so then
check for any files in this path. The files in this path need to be manually
migrated to [FlowFuse's Static Assets](https://flowfuse.com/docs/user/static-asset-service/) service.


# FlowFuse Node-RED Tools plugin

The Node-RED Tools Plugin is a module you can install into any Node-RED instance
running outside of FlowFuse, that gives you the ability to work on your flows
locally.

The current version of the plugin allows you to create a new Instance Snapshot
using the flows you have locally and push them into an instance on FlowFuse.

This can make it easier to develop hardware-specific flows locally, that can then
be pushed out to your devices through FlowFuse.

## Install

This plugin can be installed through the Manage Palette option by searching for
`@flowfuse/nr-tools-plugin` in the Node-RED editor, or on the command-line:

```bash
cd ~/.node-red
npm install @flowfuse/nr-tools-plugin
```

This assumes the default location of the Node-RED user directory. If you are not
sure where that is, check the log output when Node-RED starts as it will log the
full path to the `User directory`.

## Usage

This initial version of the plugin allows you to create a snapshot of your locally
developed flows and push them into one of your instances running inside FlowFuse.

### Connecting to FlowFuse

Before you can do anything, you need to connect the plugin to a FlowFuse platform.

1. In the Node-RED editor, open the FlowFuse Tools sidebar and click on the cog
   icon to open the settings panel.
2. Enter the url of your FlowFuse platform. For example, if you have signed-up
   to [FlowFuse Cloud](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"} then use the URL `https://app.flowfuse.com`.
3. Click connect. This will open another window where you can log in to FlowFuse
   and give permission for the plugin to connect to your account.
4. Once connected, close the settings panel.

### Working with Snapshots

The FlowFuse Tools sidebar allows you to browse the teams you are a member of
and their instances.

When you select an instance, the sidebar lists its snapshots.

You can then create a new snapshot using the flows you have running locally.

### Create a Snapshot

1. Click the `+ snapshot` button to open the Create Snapshot dialog.
2. In the dialog, enter a name for the snapshot and an optional description.
3. The dialog lists the modules your flows are using, along with the version number.
   This information is included in the snapshot when sent back to the FlowFuse instance.
   Check the notes below on how this is handled within FlowFuse.
4. Click 'Create Snapshot'

At this point, a new snapshot will be created in FlowFuse. You can then switch
to the FlowFuse platform and from the Snapshots menu either select the 'Restore Snapshot'
option to deploy that snapshot, or set it as the Device Target to deploy it to your
devices.

We'll be working on improving this workflow in future releases of the plugin - to
allow you to manage more from within the Node-RED plugin.

#### Adding modules to a snapshot

The snapshot created by the sidebar includes a list of the modules used by the flows.
If there are any modules included that have not already been added to your instance
you will need to manually add them via the `Instance Settings -> Palette -> Installed Modules`
view in the platform.

#### Defining Environment Variables

We do not currently support defining environment variables for the flows from
within the Node-RED Plugin. This means that when you create a snapshot from the
plugin, the platform will automatically merge in the currently defined environment
variables for that instance.

To manage your instance's environment variables, use the `Instance Settings -> Environment`
view in the platform.


# Customer Support

Premium customers can get support by [filing a ticket](https://flowfuse.com/support). We offer
support for the FlowFuse application and your account, any issues relating to
Node-RED such as your flows or a 3rd party node should be raised in the
[community forum](https://community.FlowFuse.com){rel="&#x22;nofollow&#x22;"}.


# Quick Start Guide

This guide provides a streamlined process for setting up and running the FlowFuse platform using [Docker](https://docs.docker.com/get-started/){rel="&#x22;nofollow&#x22;"} and [Docker Compose](https://docs.docker.com/compose/){rel="&#x22;nofollow&#x22;"}.

The Docker Compose file deploys the following services:

- **FlowFuse Platform**: Includes the core application, MQTT broker, and file server for storage
- **Database:** A pre-configured database for storing platform data
- **Proxy Server:** A pre-configured proxy server for managing HTTP traffic

For a full installation guide, including how to setup FlowFuse in a production environment, please refer to the dedicated page for [running FlowFuse on Docker](https://flowfuse.com/docs/install/docker).

## Prerequisites

Before you begin, ensure you have [Docker](https://docs.docker.com/engine/install/){rel="&#x22;nofollow&#x22;"} and [Docker Compose](https://docs.docker.com/compose/install/){rel="&#x22;nofollow&#x22;"} (in `2.23.1` version or higher) installed on your system (either as a standalone binary or as a Docker plugin).

## Step 1: Prepare your domain

FlowFuse requires a domain name to work properly — it uses subdomains to run each Node-RED instance separately, so `localhost` won't work here.

If you own a domain (e.g., `example.com` or `flowfuse.example.com`), create an **A record** pointing to your server's IP address, and another **A record** for the wildcard subdomain (e.g., `*.example.com` or `*.flowfuse.example.com`) pointing to the same address. That's all the setup needed.

If you don't have a domain yet and just want to try FlowFuse locally, see [setting up an alternative to DNS](https://flowfuse.com/docs/install/dns-setup#no-local-dns-server).

## Step 2: Download files

```bash
curl -L -o docker-compose.yml https://github.com/FlowFuse/docker-compose/releases/latest/download/docker-compose.yml
curl -L -o .env https://raw.githubusercontent.com/FlowFuse/docker-compose/refs/heads/main/.env.example
```

## Step 3: Provide domain name

Edit the downloaded `.env` file with the editor of your choice and update the `DOMAIN` variable with your domain.

You can use `sed` to update the `DOMAIN` variable in the `.env` file:

```bash
sed -i.bak 's/^DOMAIN=.*/DOMAIN=example.com/' .env
```

## Step 4: Start the Application

Run the following command to deploy FlowFuse:

```bash
docker compose up -d
```

This downloads the necessary Docker images, runs initial setup, and starts all services in detached mode.

## Step 5: Complete the application Setup

Open your web browser and navigate to `http://forge.<your-domain>/setup` (e.g., `http://forge.example.com/setup`). You will be redirected to the setup page where you can create your admin account and set up your instance.
For detailed information about first setup and configuration, follow [this guide](https://flowfuse.com/docs/install/first-run).

## Cleanup

To stop and remove the FlowFuse application, run the following command:

```bash
docker compose down -v
```

## Troubleshooting

If you encounter any issues, please check the following:

1. Ensure all prerequisites are correctly installed
2. Verify your DNS settings are correct and have propagated
3. Check the Docker logs for any error messages:
   ```bash
   docker compose logs
   ```

For more detailed information or advanced configuration options for running FlowFuse on Docker, please refer to our [full documentation](https://flowfuse.com/docs/install/docker).


# Upgrading FlowFuse

If you are upgrading an existing FlowFuse installation, this page will list any
particular requirements needed to upgrade to a given level.

If you are upgrading across multiple versions, make sure you check the requirements
for each version you are upgrading across.

Note that we do not support downgrading FlowFuse to previous levels once an upgrade
has been performed.

## General guideline

Details of how to upgrade can be found for each deployment model:

- [LocalFS](https://flowfuse.com/docs/contribute/local#upgrade)
- [Docker](https://flowfuse.com/docs/install/docker#upgrade)
- [Kubernetes](https://flowfuse.com/docs/install/kubernetes#upgrade)

To upgrade the version of Node-RED your Instances run (for example, moving to
Node-RED 5.0), see [Upgrading the Node-RED version](https://flowfuse.com/docs/upgrade/nodered-version).

### Upgrading to 2.31.2

#### Kubernetes: MQTT broker is now EMQX

From Helm chart v2.78.0 (FlowFuse 2.31.2), the chart deploys [EMQX](https://www.emqx.io/){rel="&#x22;nofollow&#x22;"}
as the platform MQTT broker, replacing Mosquitto. The migration happens automatically as
part of upgrading the chart; it is not possible to stay on Mosquitto when using the Helm
chart. If the broker is enabled, the
[EMQX Operator](https://docs.emqx.com/en/emqx-operator/latest/getting-started/getting-started.html){rel="&#x22;nofollow&#x22;"}
must be installed on the cluster before upgrading, otherwise the upgrade will fail.

See [MQTT Broker configuration](https://flowfuse.com/docs/install/configuration#mqtt-broker-configuration)
for which platform features depend on the broker.

### Upgrading to 2.6.0

#### Required AWS EKS configuration change

This release introduces the new Embedded Editor which integrates the Node-RED editor with the FlowFuse dashboard when using Node-RED 4.0. This has required some changes to be made on how certain HTTP headers are passed between the NGINX Ingress controller and AWS NLB.

The following configuration change must be applied otherwise users will not be able to login to Node-RED 4.0 instances.

The following configuration needs to be added in the values passed to the ingress-nginx helm chart. See [full configuration](https://flowfuse.com/docs/install/kubernetes/aws/#nginx-ingress){rel="&#x22;nofollow&#x22;"} for the reference.

```text
controller:
   config:
      use-proxy-protocol: true
   service:
      annotations:
         service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled=true
   externalTrafficPolicy: Cluster
```

The Proxy Protocol feature will be enabled only on newly created Target Groups.
To enable the Proxy Protocol on an existing Target Group, manual intervention is required. For detailed instructions, please refer to the [official AWS documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#enable-proxy-protocol){rel="&#x22;nofollow&#x22;"}.

#### Persistent Storage

As part of this release there is a new option for Persistent File Storage for Kubernetes based deployments.
This change removes the need to use the customised File Nodes and the FlowFuse File Server by mounting a
Persistent Volume into the Pods running the instances.

To enable this feature the following needs to be created

- A Kubernetes StorageClass that points to storage provider that can
  dynamically provision new Persistent Volumes. e.g. the [AWS EFS CSI driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver){rel="&#x22;nofollow&#x22;"}
- Pass the following values to the FlowFuse Helm Chart
  ```text
  forge:
    persistentStorage:
      enabled: true
      storageClass: '<name of StorageClass>'
      size: '5Gi'
  ```
  Where size is the default size for the volume.

Details for how to setup a AWS EFS backed StorageClass can be found on the aws-efs-csi-driver [site](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/efs-create-filesystem.md){rel="&#x22;nofollow&#x22;"}.

### Upgrading to 2.0.0

> **⚠️** Breaking changes introduced!

Together with new application features, this **release 2.0.0 introduces breaking changes** in Flowfuse Helm chart.
If you are managing your local Flowfuse instance using our [Helm Chart](https://github.com/FlowFuse/helm/tree/main/helm/flowfuse){rel="&#x22;nofollow&#x22;"}, please refer to the [upgrade](https://flowfuse.com/docs/install/kubernetes#upgrade) section of the Kubernetes installation guide or the Helm Chart [README.md](https://github.com/FlowFuse/helm/blob/main/helm/flowfuse/README.md#upgrading-chart){rel="&#x22;nofollow&#x22;"} for more details.

### Upgrading to 1.10

Endpoint Rate Limiting is now available to FlowFuse. This is disabled by default, but can be enabled by setting the `rate_limits.enabled` config setting to `true`.
The documentation for this is available [here](https://flowfuse.com/docs/install/configuration#rate-limiting-configuration).

The [TeamType concept](https://flowfuse.com/docs/user/concepts#team-type) was expanded in this release.
It is used to control what Instance Types are available for different teams, as
well as any additional limits that should be applied. When creating new Instance
Types, they must now be [manually enabled](https://flowfuse.com/docs/admin/introduction#managing-instance-types)
for the Team Types on the platform.

### Upgrading to 1.5

The main change in this release was a change in our terminology around the individual
Node-RED instances. We have introduced the [Application concept](https://flowfuse.com/docs/user/concepts#application)
as a way to group individual [Node-RED instances](https://flowfuse.com/docs/user/concepts#instance) (what we previously called Projects).

The term 'Project' is being phased out. You may still see it crop up, such as
in some of the external APIs, but we're working our way through removing it.

### Upgrading to 1.3

To enable the Team Library and FlowFuse-based Authentication of HTTP routes each
Node-RED instance will need to be updated to the [latest Stack](https://flowfuse.com/docs/user/changestack).

#### Persistent Context added

The new Persistent Context feature is available to projects when running with a
[premium license](https://flowfuse.com/docs/upgrade/open-source-to-premium).

This feature requires additional configuration to be added to the File Server component
that was introduced in FlowFuse 1.1.

Details of how to configure this can be found at the following links:

- [LocalFS](https://flowfuse.com/docs/install/file-storage#localfs)
- [Docker and Kubernetes](https://flowfuse.com/docs/install/file-storage#configuring)

### Upgrading to 1.1

#### File Server added

This release introduces a system for supporting persistent file storage when running on
Docker or Kubernetes (it will also work with LocalFS, but is not required as projects
have access to the hosts filesystem).

Details of how to configure this can be found at the following links:

- [LocalFS](https://flowfuse.com/docs/install/file-storage#localfs)
- [Docker and Kubernetes](https://flowfuse.com/docs/install/file-storage#configuring)

### Upgrading to 0.8

#### MQTT Broker added

This release introduces an MQTT Broker into the FlowFuse platform used to communicate
between devices and the core platform.

For LocalFS users, they will need to manually setup the broker and ensure it is
properly configured. The documentation for this is available [here](https://flowfuse.com/docs/contribute/local#setting-up-mosquitto-optional)

#### LocalFS Users

With the 0.8 release we have updated the version of the SQLite3 module used by the localfs
container driver. We are moving from v5.0.2 to v5.0.8.

There appears to be a clash with the bcrypt module when doing an in place upgrade of the
SQLite3 module that gives an error similar to the following:

```bash
npm ERR! path /opt/share/projects/flowforge/sqlite-test/node_modules/sqlite3
npm ERR! command failed
npm ERR! command sh -c node-pre-gyp install --fallback-to-build
npm ERR! sh: line 1: node-pre-gyp: command not found
```

If you see this then the simplest fix is to remove the `node_modules` directory and reinstall
the modules.

#### Project Nodes

This release adds support for the new Project Link nodes that can be used to send
messages between projects seamlessly.

These nodes require the MQTT Broker to be properly configured.

To deploy flows using these nodes to a Device will require the Device to be running
the latest 0.2.0 release. They will also need to have their credentials regenerated
once the MQTT Broker has been added.

### Upgrading to 0.7

The 0.7 release introduces the [ProjectType concept](https://flowfuse.com/docs/user/concepts#instance-type).

After upgrading to 0.7, an administrator must perform the following tasks before
users will be able to create new projects:

1. Create a Project Type.
   1. On the Administrator Settings -> Project Types page, click 'Create project type'.
   2. Provide a name and description. If you have billing enabled, copy in the default
      Stripe Product/Price IDs from your runtime settings file.
   3. Click 'create'
2. Assign your existing stacks to that type
   1. On the Administrator Settings -> Stacks page, edit each existing stack via
      the drop-down menu in the table.
   2. As a one-time action, set its Project Type to the one just created.
   3. Click 'save'. This will update the stack *and* all existing projects to
      be associated with the new Project Type


# Upgrading the Node-RED version

A new major version of Node-RED - such as Node-RED 5.0 - does **not** arrive
through an in-editor or in-platform "update" button. The version of Node-RED an
Instance runs is defined by its [Stack](https://flowfuse.com/docs/user/concepts#stack). To move to a
new major version you add it as a new Stack, then point your Instances at it.

This page uses the move to **Node-RED 5.0** as an example, but the same steps
apply to any major Node-RED version upgrade.

## Why there's no update button

The notification and one-click upgrade you may have seen applies to new *versions
of an existing Stack* (see [Managing Stacks](https://flowfuse.com/docs/admin/introduction#managing-stacks)).
Crossing a major Node-RED version is different: you create a new Stack that pins
the new container, rather than upgrading the existing Stack in place. This keeps
the two versions side by side so you can move Instances over at your own pace.
It also ensures major version upgrades are not automatically applied by the
Scheduled Maintenance feature.

## Before you start

- You will need access to **Admin Settings**.
- Add the new Node-RED version as a **distinct new Stack** rather than editing your
  existing Stack. Keeping them separate means your current Instances stay on their
  existing version until you choose to move them, and you can switch back from an
  Instance's settings if needed.

## Create the new Stack

1. Go to **Admin Settings → Stacks**.
2. Click **Create Stack**.
3. Set the **Container Location** to the image for the new Node-RED version. The
   exact value depends on your deployment model - see the deployment-specific
   guides below. For Node-RED 5.0 on Docker or Kubernetes this is
   `flowfuse/node-red:2.31.2-5.0.x`; the full list of pre-built tags is on
   [Docker Hub](https://hub.docker.com/r/flowfuse/node-red/tags){rel="&#x22;nofollow&#x22;"}.
   (tags are of the form [FlowFuse Version] - [Node-RED Version] )
4. Save the Stack. It is now available when you create or migrate Instances.

For the details of how the Container Location is specified for each deployment
model, see:

- [Local Stacks](https://flowfuse.com/docs/contribute/local/stacks)
- [Docker Stacks](https://flowfuse.com/docs/install/docker/stacks)
- [Kubernetes Stacks](https://flowfuse.com/docs/install/kubernetes/stacks)

## Use the new Stack

### For a new Instance

Select the new Stack when you create the Instance. It starts on the new Node-RED
version right away.

### For an existing Instance

Move the Instance onto the new Stack by following
[Changing the Stack](https://flowfuse.com/docs/user/changestack): open the Instance's **Settings**
tab and use **Change Instance Stack** to select the new Stack. The Instance
restarts on the new Stack.


# Upgrading to FlowFuse Enterprise

For self-managed FlowFuse installations without a license you can unlock more
features with a enterprise license. As an admin a license can be uploaded to
FlowFuse in the admin panel, under the settings tab. When a license is uploaded
a restart of the `forge` app is required.

After the forge application has restarted, the Node-RED runtimes need to be
updated to leverage these features. As restarting Node-RED might need to be
coordinated, FlowFuse will not automatically restart all instances.

## Reusing FlowFuse licenses

A single license may only be applied to one FlowFuse platform at any time. Running multiple FlowFuse platforms with the same license key is against the terms of the subscription.

A license may be reused on another FlowFuse platform if the original platform is no longer running. For example, if the FlowFuse platform is reinstalled onto new hardware, the license from the original install can be reused.


# Bill of Materials

The Application Bill of Materials (BoM) provides a comprehensive overview of all instance dependencies for each application. This feature gives you visibility and control to monitor, manage, and analyze the components your applications rely on.

## Accessing the Bill of Materials

The BoM is located in the **Dependencies** tab of each application.

![bom.png](https://flowfuse.com/docs/user/images/bom.png){dataZoomable=""}

## Search Functionality

Use the integrated search to efficiently find devices and instances assigned to your application. Search by:

- Instance or device name
- Package name
- Specific dependency
- Dependency version

## Prerequisites

### FlowFuse Cloud

- Instance Stack with launcher version **2.9.0 or higher**
- **Enterprise Team Type** required

### Self-Hosted

- Available only with **Enterprise license**


# Changing the Stack

[Stacks](https://flowfuse.com/docs/user/concepts#stack) define various aspects of how Node-RED instances run - including the version of Node-RED being used.

FlowFuse allows you to change the stack an instance is using - providing a way
to upgrade Node-RED.

**Note:** Stacks are created by Administrators and made available to the teams
and users of the platform.

When an Administrator creates a new version of a Stack your instance is using,
the platform will notify you that there is a new version available.

To change an instance's stack:

1. Go to the instance's page and select the **Settings** tab.
2. Click the **Change Instance Stack** button.
3. You will be prompted to select the new stack.
4. Click **Change Stack**

Your instance will now be restarted on the new stack.

**Note:** Changing the stack causes Node-RED to be stopped and restarted. This
will require a short downtime of the flows.


# FlowFuse Concepts

FlowFuse makes it easy to create, manage, and scale Node-RED instances. The platform introduces a few core concepts to help you organize and work with it effectively. Throughout the platform, you'll also see ⓘ icons that you can click on to get pop-up explanations for different features and terms.

## Table of Contents

- [FlowFuse Concepts](https://flowfuse.com/#flowfuse-concepts)
  - [Table of Contents](https://flowfuse.com/#table-of-contents)
  - [Team](https://flowfuse.com/#team)
    - [Team Type](https://flowfuse.com/#team-type)
  - [Application](https://flowfuse.com/#application)
    - [DevOps Pipeline](https://flowfuse.com/#devops-pipeline)
  - [Instance](https://flowfuse.com/#instance)
    - [Hosted Instance](https://flowfuse.com/#hosted-instance)
    - [Remote Instance](https://flowfuse.com/#remote-instance)
    - [Instance Configuration](https://flowfuse.com/#instance-configuration)
    - [Instance Type](https://flowfuse.com/#instance-type)
    - [Stack](https://flowfuse.com/#stack)
    - [Blueprint](https://flowfuse.com/#blueprint)
    - [Template](https://flowfuse.com/#template)
    - [Snapshot](https://flowfuse.com/#snapshot)
      - [Hosted Instance Snapshot](https://flowfuse.com/#hosted-instance-snapshot)
      - [Remote Instance Snapshot](https://flowfuse.com/#remote-instance-snapshot)
    - [Assigning Remote Instances to Hosted Instances](https://flowfuse.com/#assigning-remote-instances-to-hosted-instances)
      - [How It Works](https://flowfuse.com/#how-it-works)
      - [Assignment Rules](https://flowfuse.com/#assignment-rules)
      - [When to Use Instance Assignment vs DevOps Pipelines](https://flowfuse.com/#when-to-use-instance-assignment-vs-devops-pipelines)
  - [Device](https://flowfuse.com/#device)
    - [Device Agent](https://flowfuse.com/#device-agent)
    - [Fleet Mode vs Developer Mode](https://flowfuse.com/#fleet-mode-vs-developer-mode)
    - [Provisioning Tokens](https://flowfuse.com/#provisioning-tokens)
  - [Device Groups](https://flowfuse.com/#device-groups)

## Team

Teams are how FlowFuse organizes users on the platform. Each team can have multiple members and each user can be a member of multiple teams.

The users in a team can have different roles that determine what they are [able to do](https://flowfuse.com/docs/user/team#role-based-access-control). In FlowFuse Cloud, each team has its own billing plan, managed via Stripe.

### Team Type

The platform can be configured to provide different types of teams. These can be used to apply limits on what teams of a given type can do. For example, a particular team type may be restricted to certain types of [Node-RED instances](https://flowfuse.com/#instance), or how many members the team can have.

## Application

**Introduced in FlowFuse 1.5**

To organize your Node-RED instances, they are grouped within Applications. With the 1.5 release, each Application has a single Node-RED instance. With the 1.6 release, an application can have multiple Node-RED instances.

Applications provide logical organization of related instances, support for DevOps pipeline workflows, simplified device group management, application-level audit logging, and clear organizational boundaries for managing multiple instances and devices.

With FlowFuse's Granular RBAC, Applications can now also act as an authorization boundary. This means user roles and permissions can be managed at the application level, providing finer control over access to instances, snapshots, and devices within a given application.

### DevOps Pipeline

**Introduced in FlowFuse 1.8**

DevOps Pipelines allow you to manage staged development environments, pushing from your Development instances to Production once you have stable and well-tested flows. You can find out how to implement DevOps Pipelines [here](https://flowfuse.com/docs/user/devops-pipelines).

## Instance

**This was called a Project before FlowFuse 1.5**

Within your Application, you can have one or more instances of Node-RED. FlowFuse supports two types of instances based on where they run.

| Feature       | Hosted Instance                                           | Remote Instance (Device)                         |
| ------------- | --------------------------------------------------------- | ------------------------------------------------ |
| Where it runs | On FlowFuse-managed infrastructure (cloud or self-hosted) | On user-provided hardware (Edge, VM, Pi, PLC)    |
| Provisioning  | Automatic via the FlowFuse UI                             | Manual installation of the FlowFuse Device Agent |
| Lifecycle     | Fully managed by FlowFuse                                 | Managed by FlowFuse via the Device Agent         |
| Common Use    | Core logic, APIs, dashboards, development, testing        | Local data processing, IO, edge control          |

### Hosted Instance

A **Hosted Instance** is a Node-RED environment that runs within the FlowFuse infrastructure, whether in the cloud or on a self-hosted FlowFuse platform. These instances run on FlowFuse-managed infrastructure and benefit from automatic scaling and high availability. They are accessed via HTTPS with TLS/SSL encryption, making them ideal for centralized data processing and transformation, dashboard hosting, cloud service integration, and development or testing environments.

When running in Docker or Kubernetes (such as FlowFuse Cloud), the instance names are used as the hostname to access the instance. This means that the names must be DNS safe (made up of a-z, 0-9 and -) and not start with a number. Currently, it is not possible to change an instance name after it has been created.

### Remote Instance

A **Remote Instance** refers to a Node-RED environment that is managed by FlowFuse but runs on external infrastructure—be it a PLC, Gateway, local PC, or even a server in a different network. Remote instances used to be referred to as Devices within the FlowFuse platform, and in some parts of the platform this terminology is still used. See the [Device](https://flowfuse.com/#device) section for more details.

These instances run on user-provided infrastructure such as edge devices, on-premises servers, or industrial equipment while being managed centrally through the FlowFuse platform. They are ideal for edge computing, local data processing, and environments with limited connectivity. Remote instances require FlowFuse Device Agent installation to connect to the platform.

### Instance Configuration

Both hosted and remote instances are customized versions of Node-RED that include various FlowFuse plugins to integrate with the platform. A number of the standard Node-RED settings are exposed for customization, and they can be preset by applying a Template when creating the instance.

When an instance is being created, the user can select a blueprint to use.

### Instance Type

When you create a Node-RED instance, you can pick its type from the list the platform Administrator has made available. For example, each type could provide a different amount of memory or CPU allocation. If the platform has billing enabled, each type may have a different monthly price associated with it.

### Stack

A Stack describes the properties of the Node-RED runtime. This can include the version of Node-RED, memory, and CPU allocation. The specific details will depend on how and where FlowFuse is running.

Stacks are created and owned by the platform Administrator. When a User comes to create a new Node-RED instance, they choose from the available stacks associated with the chosen Instance Type. The stack determines the Node-RED version, memory, and CPU usage for your instance, ensuring compatibility and optimal performance for your use case.

For details on how to administer and manage Stacks, please see the [Administering FlowFuse](https://flowfuse.com/docs/admin/introduction#managing-stacks) docs.

### Blueprint

Blueprints are pre-built Node-RED instances designed for industrial applications. They include ready-to-use flows along with all node configurations and the required nodes, as well as environment settings, allowing the instance to be deployed with minimal modification.

### Template

A Template describes the properties of Node-RED itself. It is how many of the settings a user familiar with Node-RED would be used to modifying in their settings file. But it can also be used to customize the palette of nodes that are pre-installed, provide a set of default flows and change the look and feel of the editor.

A template can also specify [Environment Variables](https://flowfuse.com/docs/user/envvar) which can then have their values customized for each Node-RED instance, or have their values locked to prevent any changes. In the current release of FlowFuse, Templates are created by the Administrator. As well as defining the values, they also get to choose whether instances can override any of the settings for themselves.

### Snapshot

Snapshots are point-in-time backups that work differently depending on the instance type.

#### Hosted Instance Snapshot

A snapshot is a point-in-time backup of a hosted Node-RED instance. It captures the flows, credentials, and runtime settings. Snapshots can be created and deleted on the FlowFuse Platform, or using the [FlowFuse Node-RED Tools plugin](https://flowfuse.com/docs/migration/node-red-tools). The platform also allows you to roll an instance back to a previous snapshot.

A user can create an hosted instance snapshot and then mark it as the *target* snapshot for remote instance. The platform will then deploy that snapshot to all of the devices assigned to the instance. Snapshots can be set as targets for DevOps pipeline stages. Auto snapshots are available for automatic backup scheduling. If an auto snapshot is set as a target or assigned to a pipeline stage, it will not be automatically cleaned up, so you may have more than 10 auto snapshots in that case.

#### Remote Instance Snapshot

Similar to instance snapshots, a device snapshot is a point-in-time backup of a Node-RED instance running on a remote device. It captures the flows, credentials, and runtime settings. The difference is that local changes made on a device during developer mode are pulled into the FlowFuse platform and stored as a snapshot. The dashboard also allows you to see and manage these snapshots. With devices assigned to an application, a user can create a device snapshot from the remote device.

### Assigning Remote Instances to Hosted Instances

**Note:** This is a legacy feature that predates DevOps Pipelines. For new deployments, consider using [DevOps Pipelines](https://flowfuse.com/#devops-pipeline) instead, which provide more flexible and powerful deployment workflows.

Instance assignment establishes a parent-child deployment relationship between a hosted instance and remote instances. When assigned, the hosted instance becomes the source of truth and automatically pushes snapshots to the remote instance. You can only push nodes and flows that are supported by both Hosted and Remote Instances. For more information on how this works, see [How Instance Assignment Works](https://flowfuse.com/docs/user/concepts#how-it-works).

#### How It Works

Instance assignment creates a parent-child deployment relationship with the following behavior:

- **Hosted Instance (Parent)**: Acts as the deployment controller and source of truth for snapshots
- **Remote Instance (Child)**: Receives and applies snapshot updates from the parent
- **Deployment Flow**: When you set a [Target Snapshot](https://flowfuse.com/docs/user/snapshots/#instance-owned-devices) on the hosted instance, all assigned remote instances automatically restart on that snapshot
- **One-Way Relationship**: Changes flow exclusively from the hosted instance to remote instances, ensuring consistent deployments across your fleet

#### Assignment Rules

FlowFuse enforces specific constraints on instance assignment:

- Remote instances can be assigned to hosted instances
- Remote instances cannot be assigned to other remote instances
- Hosted instances cannot be assigned to any other instances

#### When to Use Instance Assignment vs DevOps Pipelines

Instance assignment suits straightforward scenarios where you need to push snapshots from a single hosted instance directly to one or more remote instances. It works well for maintaining existing deployments or when you simply need one hosted instance deploying to multiple remote instances without staging environments.

DevOps Pipelines are recommended for most deployment workflows. They support staged environments for testing changes in development before promoting to production, enable deployment to device groups for easier fleet management, and offer more flexibility aligned with modern development practices. If you're setting up a new deployment process, use DevOps Pipelines.

## Device

The FlowFuse platform can be used to manage Node-RED applications running on remote devices. A Device is essentially a **Remote Instance** that runs a software agent to connect back to the platform and receive updates.

Users must [install the agent](https://flowfuse.com/docs/device-agent/install/overview) on the devices. Devices are registered to a Team and then assigned to an individual Node-RED instance or a FlowFuse application within that team. A user can create an [instance snapshot](https://flowfuse.com/#hosted-instance-snapshot) and then mark it as the *target* snapshot for devices. The platform will then deploy that snapshot to all of the devices assigned to the instance. With devices assigned to an application, a user can create a [device snapshot](https://flowfuse.com/#remote-instance-snapshot) from the remote device.

### Device Agent

The FlowFuse Device Agent is the software that connects your hardware to FlowFuse and manages how Node-RED runs on it. It receives snapshots from FlowFuse, installs the required Node-RED version and nodes, and ensures the device always runs the assigned snapshot. It maintains a secure connection so FlowFuse can monitor the device and send updates remotely. Read more about the [Device Agent](https://flowfuse.com/docs/device-agent/introduction).

### Fleet Mode vs Developer Mode

**Fleet Mode**
When in this mode, the device runs only the assigned target snapshot. It automatically updates whenever the target snapshot changes, and the Node-RED editor is disabled to prevent any local modifications. This keeps all devices consistent across the fleet.

**Developer Mode**
When in this mode, the device ignores the target snapshot and stops receiving updates. A secure tunnel opens so you can access the Node-RED editor and make changes directly on the hardware. When you exit Developer Mode, all local edits are discarded and the device reloads the current target snapshot.

### Provisioning Tokens

Provisioning tokens can be created to allow Remote Instances to automatically join a team and to be auto assigned to an application or an instance if required.

## Device Groups

**Introduced in FlowFuse 1.15**

Device groups allow you to organize your devices into logical groups. These groups can be the target of [DevOps Pipelines](https://flowfuse.com/#devops-pipeline), greatly simplifying the deployments to one or hundreds of devices.

Device groups provide logical organization of devices by location, function, environment, or other criteria. They enable simplified mass deployments through DevOps pipelines, allow you to target specific device groups for staged rollouts, and let you manage subsets of devices independently.

Read more [about Device Groups](https://flowfuse.com/docs/user/device-groups).


# Custom Hostnames

FlowFuse allows you to point a custom subdomain at your instances, such as `dashboard.example.com`.

This feature is available to:

- FlowFuse Cloud Enterprise teams
- Self-hosted FlowFuse Enterprise, running version 2.5 or later with the kubernetes driver

## Configuring a custom hostname

The Custom Hostname option is available under the General Settings tab of your Instance.

Currently, FlowFuse only supports configuring a subdomain such as `dashboard.example.com`. Top level domains cannot be used.

1. Enter your custom subdomain and click save.
2. You will be shown a dialog to confirm the change, as this will require restarting your Instance to apply.
   It also provides information on how to configure your DNS provider.
3. Using your DNS provider, create a `CNAME` record for your chosen subdomain that points at the endpoint provided
   in the dialog.

**Note**: it is important to configure the Instance's Custom Hostname *before* you make the DNS changes. Making
the DNS changes without configuring your Instance may allow someone else to configure their instance to use
your subdomain.

For FlowFuse Cloud, the `CNAME` should point to `custom-loadbalancer.flowfuse.com`. For self-hosted users,
use the information provided in the dialog.

If you also use CAA DNS entries to control which Certificate Authorities can issue certificates for your domains,
you will need to add a record allowing LetsEncrypt to issue certificate. Please see details [here](https://letsencrypt.org/docs/caa/){rel="&#x22;nofollow&#x22;"}.
The platform will issue certificates using the `http-01` validation method.


# Custom Node Packages

FlowFuse has access to the wide range of Node-RED nodes listed in the
[public catalogue](https://flows.nodered.org){rel="&#x22;nofollow&#x22;"}. But occasionally there
will be the need for a custom node for a situation that is specific
to your Team.

If you decide to [develop](https://nodered.org/docs/creating-nodes/){rel="&#x22;nofollow&#x22;"} your
own nodes, you will need somewhere to host both the node and a Node-RED
catalogue file. FlowFuse has two solutions for this:

1. FlowFuse Hosted Nodes - Use the private NPM registry hosted by FlowFuse to store and manage your custom npm packages.
2. Third-Party NPM Registries - If you already have a private npm registry, you can enable access to these in your Instance's settings.

## FlowFuse Hosted Nodes

If you want to create a Node-RED node for private use by Instances in your
FlowFuse Team then you can publish them to the FlowFuse Custom Node Registry
(available to Enterprise level teams on FlowFuse Cloud).

### Publishing Nodes

After developing your node you can publish it to your Teams Custom Nodes
registry with the following steps

#### Authenticating

Before publishing to the registry you need to authenticate. This step should
only need to be done once.

The credentials can be found by navigating to the "Custom Nodes" tab under
the Team Library and clicking on the "Publish" button.

![Publish Custom Package](https://flowfuse.com/docs/user/images/publish-custom-package.png){dataZoomable=""}{style="max-width: 600px;"}
*Screenshot fo the "Publish Custom Package" dialog shown in the FlowFuse UI*

```text
npm login --registry=https://registry.flowfuse.cloud
```

#### Packaging

There are steps required to ensure your node is correctly packaged for the
FlowFuse Custom Nodes registry

1. Make sure the package name contains the correct scope prefix e.g.
   `@flowfuse-[team id]/node-name`. The correct prefix will be shown on the in
   the FlowFuse application
2. Add a `publishConfig` section with a `registry` entry

e.g. for a Team with ID `6Rag1kQj4k`

```json
{
    "name": "@flowfuse-6Rag1kQj4k/bar",
    "version": "0.0.1",
    "description": "...",
    "publishConfig": {
        "registry": "https://registry.flowfuse.cloud"
    },
    ...
}
```

#### Publishing

In the same directory as the `package.json` file run the following command

```text
npm publish
```

Once published you should see the Node listed in the "Custom Nodes" section
of the Team Library.

![Screenshot of the "Custom Nodes" view in the Team Library](https://flowfuse.com/docs/user/images/custom-node-library.png){dataZoomable=""}{style="max-width: 850px;"}
*Screenshot of the "Custom Nodes" view in the Team Library*

### Installing Nodes

Any packages uploaded to the Team Library will be published to your Instances
under a custom catalogue with the name "FlowFuse Team [team name] Catalogue"

![Node-RED Custom Catalogue](https://flowfuse.com/docs/user/images/custom-catalogue.png){dataZoomable=""}{style="max-width: 600px;"}
*Screenshot of the contents of a FlowFUse catalogue appearing in the "install" tab of the Node-RED Palette Manager*

## 3rd Party NPM Registries or Private npmjs.org packages

The following features are available to Enterprise users of FlowFuse
Cloud.

### NPM Registries

If you have already published packages to an existing NPM Registry then you
can enable access to this by adding the required values to a \`.npmrc" file
in the Instance Settings.

This can include authentication tokens to access private packages.

![.npmrc file](https://flowfuse.com/docs/user/images/instance-settings-npmrc.png){dataZoomable=""}{style="max-width: 600px;"}
*Screenshot from the FlowFuse platform, showing the input for defining an .npmrc file*

### Node-RED Catalogues

In order to be able to install packages in the Node-RED editor they need to
in a Node-RED Catalogue file that is loaded from a HTTPS URL. You can
supply a list of Catalogue URLs in the Instance Settings.

![Node Catalogues](https://flowfuse.com/docs/user/images/instance-settings-catalogues.png){dataZoomable=""}{style="max-width: 600px;"}
*Screenshot of the listed Node Catalogues configured on an Instance*


# Dashboards

Any hosted instance running the [FlowFuse Dashboard](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"} can be viewed directly inside FlowFuse, without opening a separate browser tab.

*This does not apply to Remote Instances (devices) - Dashboards are only listed and viewable here for hosted instances.*

## Team Dashboards

Click **Dashboards** in the Team navigation to see every hosted instance in the Team that has a Dashboard installed, regardless of which Application it belongs to.

![The Team Dashboards page listing every instance with a Dashboard installed, across all Applications](https://flowfuse.com/docs/user/images/dashboard-team.png){dataZoomable=""}

The list shows each instance's name, status, the Application it belongs to, and when its flows were last updated. Click a row to open that instance's Dashboard.

Members with the **Dashboard Only** role land on this page, scoped to only the instances they have access to.

## Application Dashboards

Each Application has its own **Dashboards** tab, showing only the Dashboards belonging to instances within that Application.

![The Dashboards tab on an Application page, listing Dashboards for instances in that Application](https://flowfuse.com/docs/user/images/application-dashboard.png){dataZoomable=""}

## Instance Dashboard Tab

An individual hosted instance's page has a **Dashboard** tab, for viewing its Dashboard without leaving the instance's context.

![The Dashboard tab on an individual instance's page](https://flowfuse.com/docs/user/images/dashboard-instance-tab.png){dataZoomable=""}

## Viewing a Dashboard

Opening a Dashboard displays it embedded inside FlowFuse. A drawer alongside it lists every other Dashboard available in the current scope (Team or Application), with a search box to find one by name. Click any entry in the drawer to switch to that Dashboard directly.

![The embedded Dashboard view with the switcher drawer open, listing other available Dashboards](https://flowfuse.com/docs/user/images/dashboard-drawer.png){dataZoomable=""}

Use the icon in the top-right of the drawer to collapse or reopen it.

To open a Dashboard in its own browser tab instead, use the **Dashboard** button's dropdown arrow on an instance's page and select **Open Direct URL**.

## Requirements

- The instance must be **running** for its Dashboard to be viewable.
- The instance must have the [FlowFuse Dashboard](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"} node installed and configured in its flows. Instances without a Dashboard configured do not appear in these lists.


# Groups

**Navigation**: Team > Application > Groups

## Overview

![Groups UI](https://flowfuse.com/docs/user/images/groups.png){dataZoomable=""}

Groups help you organize and manage multiple devices that run the same [snapshot](https://flowfuse.com/docs/user/snapshots) configuration. By grouping devices logically, you can deploy updates to dozens or even hundreds of devices simultaneously through [DevOps Pipelines](https://flowfuse.com/docs/user/devops-pipelines).

### Key Features

**Automatic Updates**

- Devices added to an active group automatically receive the current pipeline snapshot
- Devices removed from an active group have their snapshot cleared

**Group-Level Environment Variables**

- Set environment variables at the group level that apply to all member devices
- Device-specific variables take precedence over group variables
- Variables are merged at runtime without modifying device settings
- Updates to group variables trigger automatic device restarts

### Requirements

- FlowFuse 1.15+ (Enterprise Tier)
- FlowFuse Cloud (Enterprise Tier)
- FlowFuse 2.10+ for Group Environment Variables

## Creating a Group

![Create Group](https://flowfuse.com/docs/user/images/create-device-group.png){dataZoomable=""}

1. Navigate to your Application
2. Select the **Groups** tab
3. Click **Add Group**
4. Enter a descriptive name for your group
5. (Optional) Add a description to help distinguish between groups
6. Click **Create**

## Managing Group Membership

### Adding and Removing Devices

![Edit Group Members](https://flowfuse.com/docs/user/images/ui-device-group-member-edit.png){dataZoomable=""}

1. Click the group you want to modify from the table
2. Click **Edit**
3. Review the two lists:
   - **Available Devices** (left): Devices assigned to your application that can be added
   - **Group** (right): Devices currently in the group
4. To add devices: Check the boxes next to devices in the Available list, then click **Add Devices**
5. To remove devices: Check the boxes next to devices in the Group list, then click **Remove Devices**
6. Click **Save**
7. Review the confirmation prompt and click **Confirm** to apply changes

**Note**: If a device doesn't appear in the Available list, it's likely already assigned to another group.

### How Snapshots Are Affected

**When Adding a Device**

If the group has an active pipeline snapshot, newly added devices will automatically be updated to that snapshot.

**When Removing a Device**

If the group has an active pipeline snapshot and the device is currently running it, removing the device will clear its snapshot, effectively resetting it to a blank state.

**Clearing Group Snapshots**

You can remove the target snapshot from a group in the group settings. This will also clear the snapshot from all devices in the group.

## Environment Variables

Group-level environment variables follow these rules:

- **Precedence**: Device variables override group variables
- **Scope**: Variables are merged at runtime only; device settings remain unchanged
- **Removal**: Removing a device from a group removes the group's variables from that device
- **Updates**: Changing group variables triggers a restart of all devices in the group


# DevOps Pipelines

**Navigation**: `Team > Application > Pipelines`

![Overview of a DevOps Pipeline in FlowFuse](https://flowfuse.com/docs/user/images/ui-devops-pipelines.png){dataZoomable=""}

In FlowFuse it is possible to configure a DevOps pipeline for your Node-RED instances.
DevOps Pipelines allow you to easily deploy from one instance to another, most
commonly used for having an unstable/experimental "Development" instance, and a more stable
"Production" instance.

The pipeline then allows you to move your full flow and configuration along from "Development"
to "Production" once it's ready.

You can configure this in FlowFuse from the Application screen. Note you will need to have created
any Instances you wish to include in the Pipeline before being able to add them to a Pipeline.

## Creating a Pipeline

1. Select the Application you want to configure a Pipeline for.
2. Ensure an instance is created for each stage you plan to create, e.g. development, QA, and production.
   1. For the instance you want to duplicate go to the **Settings** tab
   2. Click **Duplicate Instance** and provide the necessary details
3. Select the "DevOps Pipelines" tab
4. Select "Add Pipeline"
5. Name your pipeline appropriately (this can be changed later)
6. Select "Add Stage"
7. Define your Stage's name, select the [Stage Type](https://flowfuse.com/#stage-types) and select an [Action](https://flowfuse.com/#actions).
8. Click "Add Stage"
9. Repeat 5. - 7. for as many stages as you need.

See [Pipeline Stage details](https://flowfuse.com/#pipeline-stage-details) below for more info.

## Running a Pipeline Stage

![Running a pipeline stage by clicking the play icon on the source stage](https://flowfuse.com/docs/user/images/ui-devops-run.png){dataZoomable=""}

Each stage currently is deployed manually. To do so, click the "play" icon on the source stage. In the example above,
it will push from the "Development" stage to the "Production" stage.

**Environment Variables*&#x2A; - When pushing to a next stage, &#x2A;**only your environment variable keys
will be copied over***. Values must be set on the next Stage's Instance explicitly.

**Instance Settings** - None of your Instance Settings will be copied over (e.g. Editor, Palette or Security Settings).

This ensures a split between your staging environments.

## Pipeline Stage details

- Stages of a pipeline are executed from left to right.
- Actionable stages have a play button that will push from that stage to the next stage.
- Every stage, except the last one, is effectively a source stage that can be pulled *from*.
- Every stage, except the first one, is a target stage that can be pushed *to*.
- You cannot currently insert a Stage into the middle of a Pipeline, only at the end.

### Stage Types

There are four types of stage to chose from:

1. **[Instance](https://flowfuse.com/docs/user/concepts#hosted-instance)** - a single Node-RED instance.
2. **[Device](https://flowfuse.com/docs/user/concepts#remote-instance)** - a single remote instance.
3. **[Device Group](https://flowfuse.com/docs/user/concepts#device-groups)** - a group of remote instances.
4. **Git Repository**- a remote Git repository.
   - This stage supports GitHub, Azure DevOps, and any other Git server accessible over HTTPS (for example GitLab, Bitbucket, Gitea, or a self-hosted instance).

### Actions

![Selecting an action for a pipeline stage](https://flowfuse.com/docs/user/images/ui-devops-select-action.png){dataZoomable=""}

The action defines what happens when the stage is deployed.
The available actions depend on the stage type selected for the stage.
These are listed below.

#### Instance stage actions

- **Create new instance snapshot** - A new snapshot of the instance will be created and pushed to the next stage.
- **Use latest instance snapshot** - The latest existing snapshot of the instance will be pushed to the next stage.
- **Prompt to select instance snapshot** - You will be prompted to choose which snapshot to push to the next stage.

#### Device stage action

- **Use active snapshot** - The active snapshot of the device will be pushed to the next stage.
- **Use latest device snapshot** - The latest snapshot of the device will be pushed to the next stage.
- **Prompt to select device snapshot** - You will be prompted to choose which snapshot to push to the next stage.

#### Device Group stage

When a Device Group stage is triggered, it will push the current active snapshot of the group to the next stage.

#### Git Repository stage

Git Repository stages can be used to push and pull snapshots to and from a remote Git repository. FlowFuse supports GitHub, Azure DevOps, and any other Git server that is accessible over HTTPS, for example GitLab, Bitbucket, Gitea, or a self-hosted instance.

> This feature is available to Enterprise tier teams on FlowFuse Cloud, and to Enterprise licensed self-hosted installations from version 2.32 onwards. Support for generic HTTPS Git servers (anything other than GitHub and Azure DevOps) requires version 2.32 or later.

##### Adding a Git token

Before you can create a Git Repository stage, you need to add a token that grants FlowFuse access to your repository. Tokens are managed per team, under `Team > Team Settings > Integrations`.

1. Go to **Team Settings** and open the **Integrations** tab.
2. In the Git integration section, click **Add Token**.
3. In the **Add Git Personal Access Token** popup, choose the tab that matches your Git server (**GitHub**, **Azure DevOps**, or **Other**) and follow the instructions for that provider (below).
4. Give the token a **Name**, complete the required fields, and click **Add**.

![Add Git Personal Access Token popup with tabs for GitHub, Azure DevOps, and Other providers](https://flowfuse.com/docs/user/images/generic-git-provider.png){dataZoomable=""}

###### GitHub

1. Open GitHub Personal Access Tokens Settings.
2. Click on **Generate a new token**.
3. Select the **Only select repositories** option and pick which repositories to grant access to.
4. Expand the **Repository permissions** section and ensure the **Contents** option is set to **Read and write**.
5. Click on **Generate token**.
6. This will be the only time GitHub shows you the token value. Copy the token into the **Token** field.

###### Azure DevOps

1. Open `https://dev.azure.com/[org-name]/_usersSettings/tokens` to create a new Personal Access Token.
2. Click the **+ New Token** button.
3. Give the token a name and set the **Expiry** date.
4. Select **Custom defined** for the Scopes.
5. Check **Read & Write** in the **Code** section.
6. Hit **Save**.
7. This will be the only time Azure shows you the token value. Copy the token into the **Token** field.

###### Other

Use this tab to connect to any Git server (GitLab, Bitbucket, Gitea, or a self-hosted instance) over HTTPS.

1. Create a Personal Access Token (or App Password) on your Git server with read & write access to the repository.
2. Enter the **Username** associated with that token.
3. Paste the token value into the **Token** field.
4. **CA Certificate (optional)**: only needed for self-hosted servers that use a private certificate authority. Paste the certificate (in PEM format, including the `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` lines) into this field so that FlowFuse can trust the connection. No changes to your infrastructure are required.

##### Configuring the stage

When adding a Git Repository stage, select the token you created and enter the repository URL (for example `https://github.com/your-org/nodered-flows.git`). The stage can be configured with the branch to push/pull from as well as the filename to use for the snapshot.

If a filename is not configured, it will generate the filename when pushing to the repository based on the name of Instance, Device
or Device Group that provided the snapshot. The provided filename can include directory structures, allowing the snapshot to be stored in a subdirectory of the repository.

When pulling from a repository, if the stage has not previously been used to push to the repository, the filename is a required property.

It is also possible to configure the stage with different branches for the push and pull actions. This enables a Git-based review process as part of the pipeline; using a Pull Request process to review and approve the changes before merging between the two branches.

#### Deploy to Devices

This option is only applicable when the Stage Type is an Instance.

When a pipeline stage with this action is deployed to, the same snapshot will be deployed to all devices connected to the defined instance.

## Protected Instances

It is now possible to mark an instance as Protected. This means that all team members (including Owners) only have Read Only access to the Node-RED Editor
and updates to the flows can only be made by a Team Owner running a DevOps pipeline that targets the instance.

Protected mode is activated under Instance > Settings > Protect Instance

![The Protect Instance setting under Instance Settings](https://flowfuse.com/docs/user/images/protected-instance.png){dataZoomable=""}

A Protected Instance will be marked by a status badge next to it's running state. Click on this badge will take you to the Settings page.

![Protected status badge shown next to the instance running state](https://flowfuse.com/docs/user/images/protected-instance-pill.png){dataZoomable=""}


# Environment Variables

Environment Variables allow you to manage variables used in your Node-RED flows from the FlowFuse application, you can read more on how to access environment variables inside Node-RED [in the Node-RED Docs](https://nodered.org/docs/user-guide/environment-variables){rel="&#x22;nofollow&#x22;"}.

An Environment Variable consists of a name and a value.

## Editing

You can edit the environment variables from the `Settings` tab of an instance, select the `Environment` option from the side menu.

Changes will only take effect when the Node-RED instance is restarted.

## Template provided variables

The [Template](https://flowfuse.com/docs/user/concepts#template) may include some predefined environment
variables that are automatically applied. The template may lock some of those
variables to prevent an individual instance from changing them.

Variables provided by the template cannot be deleted, however if they are editable,
their value can be set to blank.

## Node-RED instance variables

You can create additional variables for an individual Node-RED instance clicking the `Add variable` button.

You can import variables from a `.env` file using the `Import .env` button.

You can delete a variable using the trash can icon.

The image below shows an instance with the following environment variables:

- `policy_item_locked` - added by the template, locked
- `policy_item_editable` - added by the template, editable
- `FF_INSTANCE_ID` - provided by the platform, locked
- `FF_INSTANCE_NAME` - provided by the platform, locked
- `FF_PROJECT_ID` - provided by the platform, locked, depreciated
- `FF_PROJECT_NAME` - provided by the platform, locked, depreciated
- `INSTANCE_VAR` - added to the instance, editable

![](https://flowfuse.com/docs/user/images/project-envvar.png){width="500"}

## Standard environment variables

Standard environment variables are set for all Node-RED instances running
within the platform:

- `FF_INSTANCE_ID` - The unique identifier of the instance
- `FF_INSTANCE_NAME` - The name of the instance as set in FlowFuse
- `FF_INSTANCE_URL` - The full URL of the instance (e.g. `https://my-instance.flowfuse.cloud`)

In addition, the following variables are set when running on a device:

- `FF_DEVICE_ID` - The unique identifier of the device
- `FF_DEVICE_NAME` - The name of the device as set in FlowFuse
- `FF_DEVICE_TYPE` - The device type label assigned in FlowFuse
- `FF_SNAPSHOT_ID` - The unique identifier of the snapshot currently deployed to the device
- `FF_SNAPSHOT_NAME` - The name of the snapshot currently deployed to the device

When deploying the same set of flows out to multiple devices, these variables can
be used by the flows to identify the specific device being run on.

NOTE: `FF_SNAPSHOT_NAME` will not be immediately updated when the current snapshot is edited.
It will only be updated when the snapshot is changed or a setting that causes the device to
be restarted is changed.


# Chat Interface

The FlowFuse Expert chat interface is where you actively engage the AI: asking questions, building flows directly on your canvas, and querying live operational data. While other FlowFuse Expert features (like inline code completions and next-node prediction) work passively in the Node-RED editor, the chat interface is where you direct Expert and see it act on your behalf.

> Team owners can disable all AI features, including the chat interface, from the team settings page. If AI has been disabled for your team, the Expert panel will not be available.

## Opening the Chat Interface

To open the chat, first open your Node-RED instance using the **Open Editor** button. This launches Immersive Mode, where the Expert panel is available alongside your canvas.

While in Immersive Mode you also have access to all [instance settings](https://flowfuse.com/docs/user/instance-settings/) from a drawer that sits beside the canvas. You can manage environment variables, snapshots, the palette, and other settings without leaving the editor. Use the eye icon at the top of the drawer to move it left or right, pin or unpin it, or toggle fullscreen mode.

> **Note:** Note: As of v2.29, the FlowFuse Expert panel opens automatically whenever you enter the FlowFuse platform or an instance. If you close the panel, your preference is saved — Expert will remain closed on your next visit so it doesn’t get in your way. To open or close the panel while within the editor, click the FlowFuse drawer button in the top-left corner of the editor.

!["Chat interface of FlowFuse Expert alongside the Node-RED editor"](https://flowfuse.com/docs/user/images/assistant/flowfuse-expert-drawer.png){dataZoomable=""}

## Chat Modes

The chat interface operates in two distinct modes. You can switch between them using the **Mode Selector** at the top of the Expert panel.

::div
---
style: "display: grid; grid-template-columns: repeat(2, 1fr); gap: 12px; margin:
  20px 0;"
---
[
Support Mode
](https://flowfuse.com/#support-mode){.assistant-feature}[
Insights Mode](https://flowfuse.com/#insights-mode){.assistant-feature}
::

### Support Mode

**Support mode** is for flow-building assistance. Use it when you need help understanding, building, or debugging your Node-RED flows. Expert draws on its knowledge of Node-RED, your installed palette, and the context of your current flows to answer questions, explain and debug flows, and, when agentic flow building is enabled, build flows directly on your canvas.

Typical use cases in Support mode:

- "How do I convert data to CSV for writing to file & do you have any flow examples?"
- "Explain what this flow is doing"
- "Why is this node outputting a number instead of a string?"
- "Is `node-red-contrib-string` node installed on this instance?"
- "Build a flow that reads from Modbus and publishes each tag value to MQTT"

#### Building Flows on the Canvas

Expert can act on your requests directly by adding tabs, placing and wiring nodes, and configuring node properties on the canvas, rather than only describing what you should do yourself.

To use it, describe what you want to build in the chat input, the same way you would ask a question. Expert will start working immediately, and you can follow along via real-time status updates in the chat panel as each step completes. When it finishes, the result is live on your canvas. You can continue refining it through chat by asking Expert to adjust a configuration, add a node, or change a topic path, or you can edit the canvas directly as normal.

![FlowFuse Expert building and configuring a flow directly on the Node-RED canvas](https://flowfuse.com/docs/user/images/assistant/flowfuse-expert-building-flow.gif){dataZoomable=""}

Some prompts that work well:

- "Create a flow that reads Modbus registers from `192.168.1.10` every 5 seconds and publishes the values to MQTT on `factory/line3/temperature`"
- "Build an OEE dashboard tab with downtime reason buttons and a shift target gauge"
- "Add a shift handover screen that shows the last 5 alarms and a notes input field"
- "Set up a flow that polls an HTTP endpoint every minute and sends an alert if the response status is not 200"

The more specific your prompt, the closer the result will be to what you need. Include node names, topic paths, endpoints, or field names where you have them. Expert will use them directly rather than substituting placeholders.

> **Availability:** This feature is available on **FlowFuse Cloud** for all tiers, and from v2.32, to Self-Hosted Enterprise tiers. For Self-Hosted Enterprise tiers it requires a configuration for your instance. [Contact us](https://flowfuse.com/contact-us/?subject=FlowFuse%20Expert%20Application%20Building){rel="&#x22;nofollow&#x22;"} to get access.

#### Staying in Control of What Expert Does

When Expert builds on your canvas, you stay in control of what it does and when. Three features let you steer it before and during a build: it can ask clarifying questions, propose a plan for your approval, and request permission before running individual actions.

> **Availability:** Clarifying questions, plan mode, and tool permissions are available to FlowFuse Cloud and self-hosted users from v2.32.

##### Clarifying Questions

Rather than guessing when a request is ambiguous, Expert can ask you a few questions before it starts. It presents up to four questions in a single turn, each as its own option group, either single-select or multi-select depending on the question. You answer all of them together and submit once, and Expert uses your answers to build exactly what you intended. You can edit an answered question and resubmit if you change your mind, up until you send a new message.

![The Expert asking grouped clarifying questions before building, each with selectable options](https://flowfuse.com/docs/user/images/assistant/follow-up-questions.png){dataZoomable=""}

You can control how often Expert asks from the **Follow-up questions** setting in the Expert settings dialog, choosing whether it asks all its questions **all at once** or **one at a time**.

##### Plan Mode

Plan mode lets you review Expert's approach before it changes anything on your canvas. Turn it on using the **plan mode** toggle in the composer. While it is enabled, Expert responds to your request with a proposed plan instead of acting on it.

The plan is shown as its own card with four actions:

- **Approve:** Expert exits plan mode and carries out the plan.
- **Edit:** the plan text is loaded into the composer so you can adjust it directly and resubmit.
- **Request changes:** describe what you'd like changed in your own words, and Expert proposes an updated plan.
- **Reject:** the plan is abandoned and nothing is built.

![A plan card in the Expert, showing the proposed plan with Approve, Edit, Request changes, and Reject actions](https://flowfuse.com/docs/user/images/assistant/plan-mode.png){dataZoomable=""}

Once you send a newer message, an earlier plan card is disabled so you can't act on a stale plan.

##### Controlling What Expert Can Do

You decide which actions Expert is allowed to take on your behalf, and which require your approval first. These cover both the flow-building actions Expert runs on your canvas and the platform actions it can take across FlowFuse outside the editor. Each action, such as reading a flow, writing nodes to the canvas, or creating an instance, carries an action type of **Read**, **Write**, or **Delete**, and each is governed by a permission.

**Approving actions in chat.** When an action is set to require approval, Expert pauses and shows an approval card in the chat before running it. The card shows the friendly name of the action, its type (Read / Write / Delete), and the exact parameters of the call as formatted JSON, so you can see precisely what Expert is about to do. You can then choose:

- **Allow:** run this action once.
- **Always allow:** run this action, and don't ask again for it for the rest of this chat.
- **Deny:** skip this action; Expert adapts and explains what it did instead.
- **Always deny:** skip it and don't ask again for it for the rest of this chat.

![FlowFuse Expert pausing for approval mid-build, showing the Adding Nodes action awaiting your decision](https://flowfuse.com/docs/user/images/assistant/expert-tool-approval-card.png){dataZoomable=""}

Expert waits as long as you need, with no timeout on the decision. Stopping the chat while a card is open cancels the pending action (treated as a denial). "Always allow" and "Always deny" choices apply only to the current conversation and reset when you use **Start Over** or refresh. If you want to keep one, click **Make permanent** to save that choice for future chats.

Once you approve an action, the card collapses to show what was decided, and the build continues.

![The chat after actions have been approved, each card showing its action type and that it is allowed for the current chat](https://flowfuse.com/docs/user/images/assistant/expert-tool-approval-chat.png){dataZoomable=""}

**Configuring permissions in settings.** You can set your team's permissions ahead of time from the Expert settings dialog. To open it:

1. Open the FlowFuse Expert panel and select **Support** mode.
2. Click the settings (gear) icon at the top-right of the composer.

Permissions are saved per user, for the team you currently have active. If you switch to another team, your settings there are kept separately, so you can maintain a different policy per team without losing your choices when you switch back.

![The Expert settings dialog showing follow-up question cadence and the tool permission defaults for each action type](https://flowfuse.com/docs/user/images/assistant/expert-tool-permissions-settings.png){dataZoomable=""}

For each action type you set a **default** for all Read actions, all Write actions, and all Delete actions, choosing between **Always allow**, **Ask**, and **Always deny**. You can then override individual actions where you want different behaviour; an override stays in place until you reset it. Each default shows how many actions are "set individually", with a **Reset** control to return those actions to the default.

The settings split actions into two groups: **Flow Building Tools**, the actions Expert takes on your canvas inside the editor, and **FlowFuse Platform Tools**, the actions it takes across the wider FlowFuse platform, such as listing your applications and instances, checking an instance's status or logs, and creating a new instance. Which group is shown first depends on where you are: flow-building tools lead inside the editor, and platform tools lead in the app. Flow-building tools only run inside an instance editor, so open one to let the Expert use them, though you can set their permissions here at any time.

**Role-based limits.** Permissions respect your team role. Read-only team members cannot enable or trigger actions that write or delete, and will see why they are unavailable. This is enforced by Expert itself, not just hidden in the interface.

**Auditability.** Every action Expert takes on the platform is recorded in the [Audit Log](https://flowfuse.com/docs/user/logs#ai-agents-and-api-activity), alongside the tool it called and the user it was acting on behalf of.

**Example permission setups.** A few common ways to configure this:

- **Balanced (the default):** Read is set to *Always allow*, Write and Delete to *Ask*. Expert reads your flows freely and checks with you before changing or removing anything.
- **Fast building session:** set Write to *Always allow* so Expert builds without interrupting you, while leaving Delete on *Ask* so removals still need a nod. You can also grant a single tool *Always allow* from its approval card to skip repeat prompts for just that action for the rest of the chat.
- **Review-only / locked down:** set Delete to *Always deny* and Write to *Ask*, so Expert can propose and build step by step but can never remove anything.

For example, if you ask Expert to "add three nodes" with Write set to *Ask*, it pauses on the first *Adding Nodes* call and shows you the payload. Choose **Allow** to let just that call through, or **Always allow** so the remaining node additions in this chat don't prompt you again.

**Flow-building actions reference.** The flow-building actions available today, grouped by action type. New actions are added over time and some are gated to your instance's Expert version, so your list may differ slightly.

| Action type | What it covers             | Actions                                                                                                                                                                                                                                |
| ----------- | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Read**    | View only, no changes      | Describing Node Type, Describing Property, Getting Flow, Getting Nodes, Getting Palette, Listing Config Nodes, Listing Node Types, Listing Nodes, Listing Subflows, Listing Tabs, Searching Canvas, Selecting Nodes, Showing Workspace |
| **Write**   | Create or change resources | Adding Nodes, Adding Subflow, Adding Tab, Arranging Nodes, Creating Subroutine, Managing Groups, Opening Palette Manager, Setting Links, Setting Wires, Updating Nodes, Updating Tab                                                   |
| **Delete**  | Remove resources           | Removing Nodes, Removing Tab                                                                                                                                                                                                           |

**Platform actions reference.** The actions in the FlowFuse Platform Tools group, for working with your platform outside the editor. These are read and write only. There are no delete actions.

| Action type | What it covers             | Actions                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
| ----------- | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Read**    | View only, no changes      | List Applications, Get Application, Get Application Hosted Instances, Get Application Remote Instances, Get Application Instances Status, Get Application Audit Log, List Teams, Get Team, Get Hosted Instance, Get Hosted Instance Status, Get Hosted Instance Logs, Check Hosted Instance Name Availability, List Team Remote Instances, Get Remote Instance, Get Remote Instance Status, List Hosted Instance Snapshots, List Remote Instance Snapshots, List Hosted Instance Types, List Stacks, List Templates, List Blueprints, Open Hosted Instance, Open Hosted Instance Editor |
| **Write**   | Create or change resources | Create Application, Create Hosted Instance, Create Remote Instance, Assign Remote Instance To Application, Create Hosted Instance Snapshot, Create Remote Instance Snapshot                                                                                                                                                                                                                                                                                                                                                                                                             |

#### Context: What the Expert Can See

Support mode becomes significantly more helpful when the Expert has context about your environment. Context is not automatic, you choose what to share with the Expert depending on what you need help with.

::div
---
style: "display: grid; grid-template-columns: repeat(2, 1fr); gap: 12px; margin:
  20px 0;"
---
[
Palette Context
](https://flowfuse.com/#palette-context){.assistant-feature}[
Flow Context
](https://flowfuse.com/#flow-context){.assistant-feature}[
Debug Context](https://flowfuse.com/#debug-context){.assistant-feature}
::

##### Palette Context

To add Palette Context, click the **Resource Selector** button (paperclip icon) in the chat interface and select **Palette**. Once added, the Expert has access to information about the nodes installed in your Node-RED instance - including installed packages and their versions.

This allows you to ask questions like:

- "Is my palette up to date?"
- "What version of node-red-dashboard is installed?"
- "Do I have a node available for reading from a PostgreSQL database?"

The Expert can use palette context to tailor its suggestions - for example, recommending nodes you actually have installed rather than suggesting ones that are not available.

![Palette Context discussion with the FlowFuse Expert.](https://flowfuse.com/docs/user/images/assistant/palette-context.gif){dataZoomable=""}

##### Flow Context

To add Flow Context, select the flow you want the Expert to reference from the flow tabs in the Node-RED editor. The selected flow is then added as context for the Expert to read and reason about.

This makes it possible to ask questions directly about your flows without having to copy and paste JSON or describe your configuration manually.

This allows you to ask questions like:

- "What does this flow do?"
- "Why does this flow output a number instead of a string?"
- "Is there something wrong with this flow? I don't seem to get an output from the debug node!"

Flow Context is what makes the Expert genuinely useful as a debugging and code review tool - it can see the same flow you're looking at and reason about it directly.

![FlowFuse Context discussion with the FlowFuse Expert.](https://flowfuse.com/docs/user/images/assistant/flow-context.gif){dataZoomable=""}

##### Debug Context

To add Debug Context, you have 2 options:

1. Add individual log entries by clicking the ➕ button that appears over your debug message
2. Click the **Resource Selector** button (paperclip icon) in the chat interface and select **Add Debug Logs**.

Once added, the Expert has access to the messages and output currently captured in your Node-RED debug panel.

This allows the Expert to reason directly about the data or errors you are getting from your nodes at runtime, not just the structure of the flow itself.

This allows you to ask questions like:

- "Why is this debug output a number instead of a string?"
- "What does this error message in the debug panel mean?"
- "Is the payload structure here what my downstream node expects?"

Debug Context is especially useful in combination with Flow Context - together they give the Expert both the structure of your flow and the actual data it is producing, making debugging significantly more effective.

![Debug Context discussion with the FlowFuse Expert.](https://flowfuse.com/docs/user/images/assistant/expert-debug-context.gif){dataZoomable=""}

#### Resetting Context

If the Expert starts giving unexpected or inconsistent answers, it may be due to accumulated context from earlier in the conversation influencing its responses. Use the **Start Over** button to clear the conversation and start fresh with a clean context.

### Insights Mode

**Insights mode** connects the Expert to your live data via &#x2A;*Model Context Protocol (MCP)**. Use it when you want to query, analyze, or interact with real-world data - not just your Node-RED flows.

In Insights mode, you first select an MCP Server that you've built using [FlowFuse MCP Server Nodes](https://flowfuse.com/node-red/flowfuse/mcp/){rel="&#x22;nofollow&#x22;"}. The Expert can then use the tools and resources exposed by that server to answer questions against your live operational data. If you haven't built an MCP Server yet, see the guide on [building an MCP Server using FlowFuse](https://flowfuse.com/blog/2025/10/building-mcp-server-using-flowfuse/){rel="&#x22;nofollow&#x22;"}.

As of v2.32, Insights mode also reaches your **remote instances** at the edge, not just hosted instances. Point the Expert at a remote instance and ask about its live machine or operational data in plain language, with no dashboard to build and no query to write.

> **Note:** Insights on remote and self-hosted instances relies on a change to how data is routed through the platform in v2.32. Remote instances need Device Agent 4.0.0 or newer, and existing hosted instances on FlowFuse Cloud need to update to Launcher 2.23.0 or newer to keep working.

Typical use cases in Insights mode:

- You have an MCP Resource named `production_lines_facilities_list`that returns a list of your production lines, their facility names and the facility types (stamping, assembly, packaging etc)
  - You can ask: "List all stamping facilities on our production lines"
- You have added an MCP Tool named `get_production_live_state`
  -You can ask: "Tell me which of any of my assembly facilities are running and at what speed"
- You have added an MCP tool named `get_production_oee`that
  - You can ask: "Show me the worst 3 OEE results for all production line facilities"

> **Note:** Insights mode is currently in Beta. Capabilities are actively being expanded.

**To switch to Insights mode:**

1. Open the FlowFuse Expert panel
2. Use the **Mode Selector** to switch from "Chat" to "Insights"
3. Select the MCP Server you want to query
4. Ask your question

## Writing Better Queries

The quality of Expert's responses depends heavily on how your prompt is phrased, whether you are asking a question or requesting Expert to build something on the canvas. The more specific and contextual your prompt, the more accurate and actionable the result.

Here are some common patterns to improve your prompts:

### Be specific about what you're referring to

Vague references like "it", "this", or "that" require the Expert to guess what you mean. Name the thing explicitly.

| Less effective         | More effective                   |
| ---------------------- | -------------------------------- |
| "Is it up to date?"    | "Is my palette up to date?"      |
| "What does this mean?" | "What does this log entry mean?" |
| "Why did this happen?" | "Why did this error log occur?"  |

### Describe the actual problem, not just a symptom

If something isn't behaving as expected, describe what you expected versus what you got.

| Less effective       | More effective                                                 |
| -------------------- | -------------------------------------------------------------- |
| "This doesn't work"  | "My flow should output a string but it is outputting a number" |
| "The node is broken" | "The HTTP Request node is returning a 401 status code"         |

### Include relevant details upfront

The Expert works best when it doesn't have to ask clarifying questions. Include relevant context - the node type, the message property, the protocol, or the error - in your initial query.

| Less effective                    | More effective                                                                          |
| --------------------------------- | --------------------------------------------------------------------------------------- |
| "How do I connect to a database?" | "How do I connect to a PostgreSQL database using the node-red-contrib-postgresql node?" |
| "How do I format this?"           | "How do I format a Unix timestamp as an ISO 8601 string in a Function node?"            |

### Ask one question at a time for complex topics

If you have multiple questions, consider asking them separately so the Expert can give a focused answer to each rather than a broad response that covers everything superficially.

*See also: [Node-RED Embedded AI](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/) for AI features built directly into the Node-RED editor.*

## Keeping Expert Up to Date

When a newer version of FlowFuse Expert is available, a banner appears in the chat area to let you know. You can update with a single click directly from the notification, without leaving your current workflow.

![FlowFuse Expert Update Banner](https://flowfuse.com/docs/user/images/assistant/ff-expert-update-banner.gif){dataZoomable=""}


# FlowFuse Expert

FlowFuse Expert is the AI built into FlowFuse and the Node-RED editor. It is not a generic AI assistant bolted onto the side of your workflow, it understands your flows, your installed nodes, your live data, and your environment in real time.

**FlowFuse Expert is automatically installed and available in all hosted and remote instances running within or connected to FlowFuse**, no manual installation or configuration required. For self-hosted Enterprise customers, FlowFuse Expert can be enabled on request. [Contact us](https://flowfuse.com/contact-us/){rel="&#x22;nofollow&#x22;"} to get it set up on your infrastructure.

> **Note:** On self-hosted installations, FlowFuse Expert requires an Enterprise license and the platform's EMQX-based MQTT broker with the Team Broker capability enabled in the platform configuration (see [MQTT Broker configuration](https://flowfuse.com/docs/install/configuration#mqtt-broker-configuration)); installations running without EMQX cannot enable Expert.

## Managing AI Features

**Team owners** can enable or disable all AI features for their team from the team settings page. When disabled, the Expert chat panel with all AI feature will get removed for that team. Running instances need to be restarted for the change to take full effect.

**Self-Hosted Enterprise admins** have two additional controls:

- Disable AI across the entire platform via the `ai.enabled` [configuration option](https://flowfuse.com/docs/install/configuration/#ai-configuration). This overrides all team-level settings.
- Configure which AI features are available on a per-team-type basis from the Admin Panel. See [Managing Team Types](https://flowfuse.com/docs/admin/introduction/#managing-team-types) for details.

## What FlowFuse Expert Can Do

FlowFuse Expert works in two distinct ways inside your environment.

### Chat Interface

The Chat Interface is a conversational AI panel built into the FlowFuse Platform and accessible directly within the Node-RED editor. With agentic flow building enabled, you can describe what you want to build and Expert will build it on your canvas for you. It can also answer questions, debug flows, and query live operational data via MCP.

The Chat Interface supports two modes:

- **Support**: flow-building assistance, including asking questions, debugging, and building flows on the canvas. Expert can ask clarifying questions, propose a plan before it acts, and ask for your approval before running actions, and it can also take actions across the FlowFuse platform such as looking up your instances and creating new ones
- **Insights**: query live operational data via MCP tools and resources exposed by your own MCP servers, on both hosted and remote instances

[Learn more about the Chat Interface](https://flowfuse.com/docs/user/expert/chat/)

### AI in Node-RED

FlowFuse Expert brings AI assistance directly into the Node-RED editor itself. It works where you already are - inside node editors, on the canvas, without requiring you to open a separate panel.

AI features within the Node-RED editor include inline code completions, flow autocomplete, function builder, flow explainer, JSON generation, and CSS and HTML generation for FlowFuse Dashboard.

> **Note:** FlowFuse Expert's in-editor AI features can also be installed as a plugin into Node-RED instances running outside of FlowFuse, using the `@flowfuse/nr-assistant` package from the Node-RED Palette Manager. This requires a FlowFuse Cloud account but does not require a paid subscription for the current release. The Chat Interface is exclusive to FlowFuse and cannot be installed externally.

[Learn more about AI in Node-RED](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/)

## Data Privacy

No data from FlowFuse is used by third-party AI service providers for training models.

Some features utilize the OpenAI API, and as such some data is sent to OpenAI to process requests. In accordance with the [OpenAI Terms of Service](https://help.openai.com/en/articles/5722486-how-your-data-is-used-to-improve-model-performance){rel="&#x22;nofollow&#x22;"} no data is used for training of future models. OpenAI will retain data sent via its APIs for 30 days for abuse monitoring, after which it is permanently deleted.


# AI in Node-RED

FlowFuse Expert brings AI assistance directly into the Node-RED editor itself. Unlike the [Chat Interface](https://flowfuse.com/docs/user/expert/chat/), which is a conversational panel you open separately, FlowFuse Expert's in-editor AI works where you already are - inside node editors, on the canvas, and in the palette.

> **Note:** FlowFuse Expert can also be installed as a plugin into Node-RED instances running outside of FlowFuse, using the `@flowfuse/nr-assistant` package from the Node-RED Palette Manager. This requires a FlowFuse Cloud account but does not require a paid subscription for the current release.

To enable the latest features, ensure your instance is running the latest Stack. &#x2A;*For FlowFuse Cloud instances, FlowFuse Expert (`@flowfuse/nr-assistant`) is automatically updated to the latest version.**

Team owners can disable all AI features, including the in-editor AI, from the team settings page. When AI is disabled, the `@flowfuse/nr-assistant` plugin will not be loaded on new deployments. Running instances will need to be restarted for the change to take full effect.

## Features

::div
---
style: "display: grid; grid-template-columns: repeat(4, 1fr); gap: 12px; margin:
  20px 0;"
---
[
Flow Autocomplete
](https://flowfuse.com/#flow-autocomplete){.assistant-feature}[
Inline Code Completions
](https://flowfuse.com/#inline-code-completions){.assistant-feature}[
Flow Explainer
](https://flowfuse.com/#flow-explainer){.assistant-feature}[
Function Builder
](https://flowfuse.com/#function-node-creation){.assistant-feature}[
Function Code Generation
](https://flowfuse.com/#function-code-generation){.assistant-feature}[
JSON Generation
](https://flowfuse.com/#json-generation){.assistant-feature}[
CSS & HTML Generation](https://flowfuse.com/#css-and-html-generation-for-flowfuse-dashboard){.assistant-feature}
::

1. **Flow Autocomplete:** Automated, intelligent suggestions for which node should be added next in your flow
2. **Inline Code Completions:** Inline code completions for Function node, Tables Query node and FlowFuse Dashboard `ui-template` node
3. **Flow Explainer:** Get detailed explanations of the selected nodes in your flow
4. **Function Node Creation:** Create a new function node directly, driven by natural language
5. **Function Code Generation:** Within the scope of an existing function node, ask the assistant to write code for you
6. **JSON Generation:** In-editor JSON generation within the JSON editor for all typed inputs and JSON editors
7. **CSS and HTML Generation:** In-editor CSS and HTML generation for FlowFuse Dashboard `ui-template` nodes

### Flow Autocomplete

![Recording of the flow autocomplete in-action, with up/down keys used to toggle suggestions and tab to move to the next suggestion](https://flowfuse.com/docs/user/images/assistant/node-autocomplete.gif){dataZoomable="" width="700px"}*Recording of the flow autocomplete in-action, with up/down keys used to toggle suggestions and tab to move to the next suggestion*

FlowFuse Expert runs a trained, in-browser machine learning model that provides intelligent suggestions for which node should be added next in your flow.

You can accept the suggestion by clicking it or by pressing the `Tab` key. You can also toggle through suggestions by pressing the `Up` and `Down` keys.

### Inline Code Completions

Mimicking the familiar code assistant in your IDE, FlowFuse Expert provides inline code completions for Function nodes, Tables Query nodes, and FlowFuse Dashboard `ui-template` nodes.

![inline code completions](https://flowfuse.com/docs/user/images/assistant/inline-completion.png){dataZoomable="" width="450px"}*A simple example of inline code completions for a Function node*

This feature accelerates the writing of custom code and queries by providing intelligent suggestions without having to leave the editor, lowering the barrier to entry for non-technical users.

Using comments is optional - the assistant will do its best to understand the context of the code and provide suggestions based on the surrounding code. However, writing comments does help to frame the request in a way that is more likely to produce accurate results.

### Flow Explainer

FlowFuse Expert adds a button to the Assistant menu that will explain what the selected nodes do. To use this feature, select one or more nodes on the canvas and click the "Explain Flows" button in the Assistant menu.

### Function Node Creation

![FlowFuse Expert dialog](https://flowfuse.com/docs/user/images/assistant/dialog-function-node-builder.png)*Screenshot showing the FlowFuse Expert dialog for creating a function node*

Use natural language to request a new function node be added to your Node-RED flow. This is useful when you want to quickly add a function node without having to drag it from the palette and write the code yourself.

If your instance supports external modules, you can ask for a function node that uses them and they will be added to the function node setup automatically. If your function node requires multiple outputs, FlowFuse Expert will set the correct number of outputs accordingly.

### Function Code Generation

FlowFuse Expert adds a code lens to the function node editor that allows you to generate code directly within the editor.

![inline code lens](https://flowfuse.com/docs/user/images/assistant/function-node-inline-code-lens.png){dataZoomable=""}

This is useful when you want to quickly add or rewrite code within an existing function node without generating a full new function node from scratch.

### JSON Generation

FlowFuse Expert adds a code lens to the JSON editor that allows you to generate JSON directly within the Monaco editor.

![json generation](https://flowfuse.com/docs/user/images/assistant/json-prompt.png){dataZoomable="" width="700px"}*Screenshot showing a FlowFuse Expert prompt for JSON generation*

This is useful when you want to quickly generate JSON for a prototype or to test a piece of functionality in your flows.

![json generation](https://flowfuse.com/docs/user/images/assistant/json-results.png){dataZoomable="" width="700px"}*Screenshot showing the result of the above FlowFuse Expert prompt*

### CSS and HTML Generation for FlowFuse Dashboard

FlowFuse Expert adds a code lens to the FlowFuse Dashboard `ui-template` node that allows you to generate CSS and HTML directly within the code editor. It is aware of the context of the node and will generate suitable CSS and HTML components for Vuetify and the FlowFuse Dashboard.

## Installing in External Node-RED Instances

> **Note:** FlowFuse Cloud instances have FlowFuse Expert automatically installed. Manual installation is only needed for Node-RED instances running outside of FlowFuse. Only the in-editor AI features can be installed externally - the Chat Interface is exclusive to FlowFuse.

To install the plugin in your own Node-RED instance:

1. Use the Node-RED Palette Manager to install the package `@flowfuse/nr-assistant`
2. Restart Node-RED
3. Click the FlowFuse Expert icon in the header
4. Follow the prompts to connect to your FlowFuse Cloud account
5. Once connected, you will be able to use all FlowFuse Expert features

### FlowFuse Expert for self-hosted customers

If you are self-hosting FlowFuse with an Enterprise license, get in touch with [support](https://flowfuse.com/support) who will be able to help get you set up to use FlowFuse Expert locally.


# FlowFuse Tables

::div{.ff-callout.ff-callout--warning}
Warning

  :::div{.ff-callout__content}
  This feature is currently in [the beta state](https://flowfuse.com/handbook/engineering/releases/#beta-release){rel=""nofollow""}.
  :::
::

From FlowFuse v2.20.0 Teams (Enterprise teams only) can create a relational database to use to store data.

You can create a database by selecting the Tables entry in the left hand menu

![Screenshot of FF Tables create database menu](https://flowfuse.com/docs/user/images/tables/create-database.png){dataZoomable=""}*Screenshot of FF Tables create database menu*

Once you have created a database you can use the wizard to create some tables. The wizard offers a subset of the most used column types and has the option to set default values and generate sequences for ids.

![Screenshot of create tables wizard](https://flowfuse.com/docs/user/images/tables/create-table-wizard.png){dataZoomable=""}*Screenshot of create tables wizard*

Once the tables have data in them then the first 10 rows will be displayed in the Explorer tab.

![Screenshot of Tables Explorer](https://flowfuse.com/docs/user/images/tables/tables-ui-screenshot.png){dataZoomable=""}*Screenshot of Tables Explorer*

## Query Nodes

FlowFuse Node-RED instances come with a Query Node that will be enabled if running in a Team with a FlowFuse Tables database enabled. This node will automatically import the required credentials to connect to the database.

![Screenshot of Node-RED query node](https://flowfuse.com/docs/user/images/tables/tables-query-node.png){dataZoomable=""}*Screenshot of Node-RED query node*

## Postgres Clients

You can connect any Postgres Client to the FlowFuse Tables database using the information on the Credentials tab

![Screenshot of credentials](https://flowfuse.com/docs/user/images/tables/credentials.png){dataZoomable=""}*Screenshot of credentials*


# FlowFuse File Nodes

Node-RED instances running within FlowFuse Cloud with Launcher version before 2.7.0
include a modified set of nodes that make it possible to store files safely regardless of
the environment.
Cloud based instances can read and write to persistent storage using these nodes.
Edge devices will store files on its local filesystem.

There are two nodes in the File Node collection:

- `file` - A file node for writing to persistent storage
- `file in` - A file node for reading from persistent storage

## FlowFuse 2.7.0 and later

With the release of FlowFuse v2.7.0 a new Persistent Storage feature was enabled.

This allows the default Node-RED File Nodes to work safely by mounting a volume to
ensure files are persisted across all restarts of the Instance.

On Docker, Kubernetes self hosted instances and FlowFuse Cloud the volume is mounted
on `/data/storage`. The Current Working Directory for the Node-RED process is set to
this directory, this means that if you do not specify a path in a node it will created
or read from this directory.

For LocalFS builds a `storage` directory is created in the Instance User Directory,
this means that if FlowFuse is installed in `/opt/flowfuse` the directory will be at
`/opt/flowfuse/var/projects/<project-id>/storage`

## Templates

On FlowFuse Cloud before v2.7.0 the Default Template had an explicit exclusion for
`10-file.js` to ensure that the replacement FlowFuse File Nodes were loaded. This
Template was renamed to "Default v1" to differentiate it. If your instance is using
this version of the template then it will need modifying to allow access to the
default Node-RED File Nodes to make use of the new Persistent Storage. Please
contact FlowFuse support to arrange this, they will also be able to migrate any
files stored in the old service.

## Usage

Simply drop the file nodes into your flows as you would with the regular file nodes in Node-RED.

**Example:** Write string to a file, then read from the file

:iframe{allow="clipboard-read; clipboard-write" height="100%" src="https://flows.nodered.org/flow/7f93fbbf67f9dc4e81bfbeb2b921881e/share" style="border: none;" width="100%"}

There are more helpful built-in examples on the **Import Examples** dialog in Node-RED.

## Deployment Considerations

When a snapshot is deployed to a device, the original Node-RED file nodes are used and
any files will be stored on the device's local filesystem.


# High Availability mode

High Availability mode allows you to run multiple copies of your Node-RED instance,
with incoming work distributed between them.

The following requirements apply:

- FlowFuse 1.8+ running with an EE license and the kubernetes driver
- FlowFuse Cloud

Within FlowFuse Cloud it is currently free to use for all teams, but will
become a chargeable feature in a future release.

## Restrictions

- Enabling or disabling HA mode requires a restart of the Instance.
- When in HA mode, two copies of the flows are run.
- Flows cannot be directly modified in an HA Instance; the editor is disabled.
  A [DevOps Pipeline](https://flowfuse.com/docs/user/devops-pipelines) should be created to deploy new flows to the instance.
- Any internal state of the flows is not shared between the HA copies.
- The [FlowFuse Persistent Context](https://flowfuse.com/docs/user/persistent-context) is not synchronised
  between the HA copies
- The logs view show combined logs of all copies. An identifier indicates which replica the log message originates from. You have the possibility to filter the messages.

More details of these restrictions are available below.

## Setting up High Availability mode

To make full use of the HA mode you will need two separate Node-RED instances.

The first will be your development instance. This is where you can build and test
your flows.

The second will be your HA 'production' instance. This instance will run multiple
copies of the flows and get updated from the development instance using a DevOps
Pipeline between the two instances.

To enable HA mode on your production instance, open the [settings page](https://flowfuse.com/docs/user/instance-settings) for your
instance and go to the High Availability section. Click the 'Enable HA mode' button
and confirm the choice in the dialog.

Once enabled the instance will be restarted to apply the settings. Once enabled,
the editor will no longer be available.

## Editing an HA instance

As the editor is disabled for an HA instance the flows cannot be directly modified.

There are two options for updating the flows on an HA instance.

### Disabling HA mode

If you disable HA mode via the setting page, after the instance has been restarted
the editor will be available and changes can be made. However, this will mean a
period of downtime whilst the instance is brought in and out of HA mode.

### DevOps Pipeline

Create a [DevOps pipeline](https://flowfuse.com/docs/user/devops-pipelines) from a 'development' Instance to push updates to your HA
instance.

This allows you to free develop your flows in one instance and when you are happy
with the results, use the pipeline to push the changes over to the HA instance.

## Building HA-ready flows

Whilst FlowFuse can help run multiple copies of your flows, and provide the
necessary load balancing between those copies, it still requires the flows to
have been created with HA in mind.

This guide provides some things to consider when building HA-ready flows. We'll
continue to expand on this as we gather more feedback from our users.

There are two things to consider - how state is managed and how work is distributed
between the copies.

### Managing state

The most well-suited flows for HA are those that do not depend on local state being
maintain between individual messages coming into the flow. This is because, in an HA
instance, the messages are distributed between the copies - none of them get to see
every message.

When state is required, it needs to be stored somewhere that all instances can
access it - for example an external database service.

FlowFuse provides a [persistent context](https://flowfuse.com/docs/user/persistent-context) option - however
this includes a local caching layer that means it doesn't fully synchronize between
the instances in real time. This is something we'll be working on for a future iteration
of the feature, as it will require some changes in Node-RED to unlock its full potential.

There is also the state that is implicitly maintained within the nodes of a flow.
For example, the Smooth node can be used to calculate a running average value of
messages passing through it. The node does that by keeping in memory the recent
values so it can recalculate the average with each update. In an HA instance,
the node will only be calculating the average for the messages it sees.

### Routing work

When HA is enabled, all HTTP traffic directed at the instance will be load-balanced
between the copies automatically.

It gets a little more complicated where flows connect out to external systems to
pull in work - for example, when using MQTT.

MQTT includes a feature called [Shared Subscriptions](https://www.hivemq.com/blog/mqtt5-essentials-part7-shared-subscriptions/){rel="&#x22;nofollow&#x22;"}
that allows a broker to distribute messages between a group of subscribers. This
provides the load balancing needed for an HA instance - but the flow must be configured
to use the appropriate shared subscription topics, as well as to not set a ClientID on the connection to avoid conflicts between the connections.

The [Project Nodes](https://flowfuse.com/docs/user/projectnodes) have been updated to support shared subscriptions
automatically when running in HA mode.

There are lots of other nodes that can be used to trigger flows, whether by
listening for events on an API, connecting to locally attached hardware and many
things in between. Typically, those that are more cloud-aligned, such as messaging
systems like Kafka and AMQP will have very well established ways of doing load
balancing.


# HTTP Access Tokens

When a FlowFuse instance is secured with [FlowFuse User Authentication](https://flowfuse.com/docs/user/instance-settings#flowfuse-user-authentication),
only users who are in the same FlowFuse team can access the dashboard and HTTP endpoints
created within Node-RED.

In some cases, it is also necessary to provide secure access to the endpoints for other applications to use.
This is where the HTTP Access Tokens can be used.

With the FlowFuse User Authentication option enabled on the Instance's Security settings tab, the table of access
tokens is shown.

### Creating an access token

To create a token, click the Add Token button. Given your token a name and an optional expiry date, then click create.

You will be shown the token value - this is the only time it will be shown so make a note of it before closing the dialog.

![](https://flowfuse.com/docs/user/images/bearer-token-dialog.png)

### Using an access token

The token can be used when making an HTTP request to the Node-RED instance by providing it in the `Authorization` http header as
a bearer token.

For example, if a Node-RED instance has a flow deployed that includes an `HTTP In` node listening on `/token-demo`, the following
`curl` command can be used to access it:

```shell
curl -H "Authorization: Bearer ffhttp_FKc_S4qlTBV1H411hmhneHcSJ6F_FGNQLPYbnoD3-B0" \
   https://example.flowfuse.cloud/token-demo
```

To access it from another Node-RED instance, you can use the `HTTP Request` node by enabling the 'Use authentication'
option, selecting 'bearer authentication' and providing the token:

![](https://flowfuse.com/docs/user/images/bearer-token-nr-request.png)

### Remote Instances

HTTP Access Tokens can also be used to secure HTTP endpoints served by Node-RED flows running on Remote Instances (devices). This requires [Device Agent v4](https://flowfuse.com/docs/device-agent/introduction) or later. On self-hosted FlowFuse, it also requires FlowFuse v2.32 or later.


# Instance Settings

The Instance Settings allow you to customize many aspects of your Node-RED runtime.

To access them, click on an instance from the FlowFuse platform and select the **Settings** tab. The instance view also includes other tabs such as Overview, Devices, Version History, Assets, and Node-RED Logs.

You can also access all the same settings from within the immersive Node-RED editor. The settings drawer sits alongside the canvas without overlapping it, so you can adjust environment variables, manage snapshots, update the palette, and make other changes without leaving your flow.

You can customize the drawer layout using the eye icon at the top of the drawer, which lets you move it from right to left, pin or unpin it, and toggle fullscreen mode.

![Instance settings drawer](https://flowfuse.com/docs/user/images/instance-settings.png)

Instance Settings are split into a number of sections:

- [Instance Settings](https://flowfuse.com/#instance-settings)
  - [General](https://flowfuse.com/#general)
    - [Change Stack](https://flowfuse.com/#change-stack)
    - [Copy Instance](https://flowfuse.com/#copy-instance)
    - [Import Instance](https://flowfuse.com/#import-instance)
    - [Suspend Instance](https://flowfuse.com/#suspend-instance)
    - [Delete Instance](https://flowfuse.com/#delete-instance)
  - [Environment](https://flowfuse.com/#environment)
  - [High Availability](https://flowfuse.com/#high-availability)
  - [Editor](https://flowfuse.com/#editor)
  - [Security](https://flowfuse.com/#security)
    - [None](https://flowfuse.com/#none)
    - [Basic Authentication](https://flowfuse.com/#basic-authentication)
    - [FlowFuse User Authentication](https://flowfuse.com/#flowfuse-user-authentication)
  - [Palette](https://flowfuse.com/#palette)
  - [Alerts](https://flowfuse.com/#alerts)

## General

This section includes several actions you can take on the instance:

### Change Stack

The Stack determines the version of Node-RED being used. If a new stack
is available, you can use this option to update your stack.

### Copy Instance

This allows you to create a copy of the instance in your team.

### Import Instance

This allows you to take existing Node-RED flow and credential files and import them
into your instance.

### Suspend Instance

This stops the instance entirely.

### Delete Instance

If you're sure you don't want the instance anymore, this allows you to delete
it. You cannot undo deleting an instance. Devices assigned to the instance will be
unassigned from the instance and available to be reassigned to a new instance.

## Environment

This allows you to manage the environment variables. More information
on working with environment variables is available [here](https://flowfuse.com/docs/user/envvar).

## High Availability

This allows you to manage the HA settings of the instance. High Availability
is a Preview Feature. More information is available [here](https://flowfuse.com/docs/user/high-availability).

## Editor

This covers many options to customize the Node-RED editor. This includes:

- Disabling the editor entirely
- Modifying the paths the editor and dashboard are served on
- Choosing which code editor to use in your Node-RED nodes
- Setting a custom title for the editor
- Choosing a light or dark theme for the editor
- Controlling the runtime timezone
- Controlling the use of node modules in function nodes

## Security

This allows you to modify the security settings of the runtime. In particular
this covers the security applied to any HTTP routes served by the runtime.

### None

The default option is not to apply any security - so any HTTP In nodes, or Node-RED
Dashboard can be accessed by anyone.

### Basic Authentication

You can optionally enable Basic Authentication, with a single hardcoded username
and password.

### FlowFuse User Authentication

Alternatively, with a licensed instance of FlowFuse, you can require anyone accessing
those routes to be logged into FlowFuse. The hosted pages or API endpoints are only
available for FlowFuse users who have access to the team on FlowFuse and the cloud
instance.

If using FlowFuse user Authentication you can also generate HTTP Bearer tokens that
can be used to access APIs hosted in Instances with HTTP-in/HTTP-response nodes.

More information on using HTTP Access Tokens can be found [here](https://flowfuse.com/docs/user/http-access-tokens).

## Palette

This allows you to manage what extra nodes are installed inside Node-RED, as well
as any restrictions you want to apply to the Palette Manager within Node-RED.

It includes the option to add extra Node-RED Catalogue URLs and a `.npmrc` file
that will be deployed to the instance. Details of the `.npmrc` format can be found
[here](https://docs.npmjs.com/cli/v9/configuring-npm/npmrc){rel="&#x22;nofollow&#x22;"}

## Alerts

Alerts are a feature designed to provide email notifications based on specific Auditlog events. This functionality ensures prompt awareness and response to critical events.

Users can configure alerts for the following Auditlog events:

- Node-RED has crashed
- Node-RED has been placed in Safe Mode

When configuring alerts, you can choose the recipients of these notifications:

- Team Owners
- Team Members
- Both Owners and Members


# FlowFuse Node-RED Instance States

The following list describes the possible states a hosted or remote Node-RED instance can find itself in.

## Stable States

- **running**: Instance is fully operational. Flows are deployed and executing normally.
- **suspended**: Instance resources are freed and flows are paused. Can be resumed without redeploying.
- **stopped**: Instance is not executing any flows and is intentionally shut down.
- **error**: Instance cannot operate normally due to a critical configuration or runtime issue. Requires user intervention.
- **crashed**: Instance terminated unexpectedly due to repeated runtime errors or failures.
- **rollback**: A previous working version of the instance has been restored due to deployment failure or manual revert.
- **warning**: Instance is running but has non-critical issues (e.g., node failures, resource limits close to threshold).
- **safe**: Running in safe mode after multiple crashes. Editor works, flows are not started until a deploy action is triggered.
- **protected**: Editor is disabled. Deployment can only occur via pipeline or controlled automation.
- **connected**: Instance has established a successful connection to its runtime environment and is reachable.

## Transitional States

- **loading**: Instance UI or resources are being prepared (initial startup or page load).
- **installing**: Required packages, dependencies, or container layers are being installed.
- **starting**: Flows and runtime services are initializing.
- **stopping**: Flows and runtime services are shutting down gracefully.
- **restarting**: Instance is stopping and then immediately starting again, typically after a deployment or configuration update.
- **suspending**: Instance flows are being paused and resources deallocated before entering suspended state.
- **importing**: An external project or configuration is being applied to the instance.
- **pushing**: Changes are being uploaded to the runtime or container registry.
- **pulling**: Artifacts or project content are being fetched from a registry or pipeline source.


# Getting Started with FlowFuse

This guide will help you learn how to use the FlowFuse platform to quickly create new Node-RED applications after a successful [installation](https://flowfuse.com/docs/install/introduction) or [sign-up](https://app.flowforge.com/account/create){rel="&#x22;nofollow&#x22;"} for FlowFuse Cloud.

## Creating a Node-RED Instance

### Your First Hosted Instance

Your first Node-RED instance should be automatically created upon your initial login to FlowFuse.

![Instance created initial login](https://flowfuse.com/docs/user/images/getting-started/ff-home-initial-login.png){dataZoomable=""}

**Accessing the Node-RED Editor:**

To access the Node-RED Editor, simply click on the option shown in the image below marked with a red box:

![Open Editor Shortcut](https://flowfuse.com/docs/user/images/getting-started/open-editor-shortcut.png){dataZoomable=""}

Alternatively, you can click on that instance and then you will find the "Open Editor" button at the top right:

![Open Editor](https://flowfuse.com/docs/user/images/getting-started/Open-Editor.png){dataZoomable=""}

### Creating Additional Instances

For utilizing various other FlowFuse features (e.g., DevOps Pipelines), it's highly beneficial to create a second Node-RED instance. A second Node-RED instance is included in the Trial Phase of FlowFuse Cloud.

**From the Home Page:**

1. Click on the "Add Instance" button shown in the image below
2. Enter the name you want for your instance
3. Select your application in which you want to create it
4. Select the instance type
5. Select the Node-RED version from the dropdown
6. Click "Next" and [select the blueprint](https://flowfuse.com/#selecting-a-blueprint) you want to use

![Add Instance](https://flowfuse.com/docs/user/images/getting-started/ff-home-after-initial-login-add-instance.png){dataZoomable=""}

**From the Applications Page:**

Alternatively, you can go to your applications from the left sidebar by clicking "Applications," select your application—in our example, "Demo's Application"—and click "Add Instance," then follow the same process.

[Learn more about Instances](https://flowfuse.com/#working-with-instances)

### Your First Remote Instance

A remote instance allows you to run Node-RED on your own hardware while managing it through FlowFuse.

**Adding a Remote Instance:**

1. Click on "Remote Instances" from the left sidebar
2. Click "Add Remote Instance"
3. Enter a name for your instance and select the device type
4. Select your application and click "Add"

![Add Remote Instance](https://flowfuse.com/docs/user/images/getting-started/add-remote-instance.png){dataZoomable=""}

![Add Remote Instance Form](https://flowfuse.com/docs/user/images/getting-started/instance-add-form.png){dataZoomable=""}

**Installing the Device Agent:**

FlowFuse will show you a device configuration window with installation options:

- **One-Line Install** (Recommended): Automatically installs Node.js (if needed), the device agent, and registers your device
- **NPM Installation**: Manual installation instructions for Windows, Mac, or Linux

![Device Configuration Window](https://flowfuse.com/docs/user/images/getting-started/device-configuration-window-2.gif){dataZoomable=""}

Follow the steps in the window to connect your device—it takes less than a minute.

[Learn more about Device Agent](https://flowfuse.com/docs/device-agent/introduction)

**Accessing Your Remote Instance:**

Once registered, you can manage your remote Node-RED instance through FlowFuse:

To start building flows:

1. Enable "Developer Mode" from the top right
2. Click "Open Editor"

![Developer Mode](https://flowfuse.com/docs/user/images/getting-started/developer-mode.png){dataZoomable=""}

![Open Editor](https://flowfuse.com/docs/user/images/getting-started/open-editor-remote-instance.png){dataZoomable=""}

### Selecting a Blueprint

When creating a new Node-RED instance, you have the option to choose a blueprint tailored for specific use cases. For example, our "ANDON Operator Terminal" blueprint can be selected, and it will automatically configure the Node-RED instance, install necessary nodes, sparing you the need to start from scratch. Click "Create Instance" from the top-right to complete the process.

While these templates are powerful out-of-the-box, they're also fully customizable, allowing you to tweak them to suit your unique requirements. Ultimately, blueprints speed up the learning curve for new users and expedite the solution-building process for experienced ones.

![Blueprint selection](https://flowfuse.com/docs/user/images/getting-started/blueprint-selection.png){dataZoomable=""}

**NOTE**: *Some blueprints may only be available on certain tiers*

## Creating Your First Flow

FlowFuse published an [eBook on Node-RED development](https://flowfuse.com/ebooks/beginner-guide-to-a-professional-nodered/){rel="&#x22;nofollow&#x22;"}, which is a great resources when you're new
to Node-RED. You can also read our [blog post on creating your first flow](https://flowfuse.com/blog/2023/01/getting-started-with-node-red/){rel="&#x22;nofollow&#x22;"}.

## Creating Your First DevOps Pipeline

DevOps Pipelines enable you to link multiple Node-RED instances together in a deployment pipeline.

1. **Add a Pipeline**: Select your application and click `Add Pipeline`. :br![Add Pipeline](https://flowfuse.com/docs/user/images/getting-started/Add-Pipeline.png)
2. **Name Your Pipeline**: Enter a suitable name.
3. **Add Stages**: You can now add stages to your pipeline. In our example, we add a Development Stage and a Production Stage.
4. **Execute the Pipeline**: It is now easy to execute the pipeline with one click, promoting your recently created flow to your Production Node-RED instance. :br![Execute Pipeline](https://flowfuse.com/docs/user/images/getting-started/devops-pipeline-w-stage.png)

[Learn more about DevOps Pipelines](https://flowfuse.com/docs/user/devops-pipelines/)

## Working with Devices

FlowFuse supports managing Node-RED on your own hardware.

- [Getting started with Devices](https://flowfuse.com/docs/device-agent/introduction)

## Working with Teams

- [Team management](https://flowfuse.com/docs/user/team/) - How to add and remove users from a team.
- [Role based access control](https://flowfuse.com/docs/user/team/#role-based-access-control) - Which privileges are granted to different roles.

## Working with Files and Context

FlowFuse supports reading and writing persistent files and persistent context.

- [Working with Files](https://flowfuse.com/docs/user/filenodes)
- [Working with the Static Asset Service](https://flowfuse.com/docs/user/static-asset-service)
- [Working with Context](https://flowfuse.com/docs/user/persistent-context)

## Working with Instances

- [Dashboards](https://flowfuse.com/docs/user/dashboards) - View and switch between your Node-RED Dashboards from one place.
- [Instance States](https://flowfuse.com/docs/user/instance-states) - List of states an instance can be in.
- [Snapshots](https://flowfuse.com/docs/user/snapshots) - Create point-in-time backups of your Node-RED instances.
- [Environment Variables](https://flowfuse.com/docs/user/envvar) - How to manage Environment Variables in your Node-RED instances.
- [Change Project Stack](https://flowfuse.com/docs/user/changestack) - How to change an instance stack, for example to upgrade Node-RED.
- [Logs](https://flowfuse.com/docs/user/logs) - The Logs available in the FlowFuse application.
- [Project Link Nodes](https://flowfuse.com/docs/user/projectnodes) - Custom nodes for sending messages between Node-RED instances and devices.
- [MQTT Nodes](https://flowfuse.com/docs/user/mqtt-nodes) - Custom nodes for zero config MQTT integration with the team broker.
- [Instance Settings](https://flowfuse.com/docs/user/instance-settings) - Settings available for Node-RED instances.
- [Shared Team Library](https://flowfuse.com/docs/user/shared-library) - Share flows easily between different Node-RED instances in your team.
- [Node-RED Tools Plugin](https://flowfuse.com/docs/migration/node-red-tools) - A plugin for Node-RED that lets you work with your flows outside of FlowFuse.
- [High Availability mode](https://flowfuse.com/docs/user/high-availability) - Run multiple copies of your instance for scaling and availability.
- [FlowFuse Expert](https://flowfuse.com/docs/user/expert/) - A Node-RED plugin powered by AI, trained on FlowFuse content, that helps you code faster, build flows, and debug with context-aware guidance.

## Working with MQTT

- [Team Broker](https://flowfuse.com/docs/user/teambroker) - Working with the FlowFuse bundled MQTT Broker

## Working with Custom Nodes

- [Custom Nodes](https://flowfuse.com/docs/user/custom-npm-packages) - Publishing Custom Node-RED Nodes

## Working with FF Tables

- [FF Tables](https://flowfuse.com/docs/user/ff-tables) - Databases


# Logs

FlowFuse presents log information in several different places depending on what you are interested in.

## Node-RED Logs

The Node-RED logs are available for all instances running within the platform.

They will contain information such as nodes being added and errors relating to your flows.

The log information is kept back to the last time the instance container was restarted, you can view older information on the `Load earlier...` link at the top of the log.

![](https://flowfuse.com/docs/user/images/projectlog.png){width="500"}

Node-RED logs can also be output from the Containers/Pods that run Instances on Docker or Kubernetes. This is enabled by the `forge.logPassthrough` option. More details can be found in the [Configuration](https://flowfuse.com/docs/install/configuration) documentation.

## Audit Log

The Audit Log tab on the application and instance views shows key events that have happened.

The events include:

- User logging into the editor
- Flows being updated
- Nodes installed
- Snapshots being created
- Resource utilization warnings

This log contains all events since the instance was created. You can view older data using the `Load More...` link at the bottom of the log.

![](https://flowfuse.com/docs/user/images/projectactivity.png){width="500"}

### Resource utilization warnings

If the CPU or memory usage exceeds 75% for more than 5 minutes, a warning will be displayed in the Audit Log, indicating that measures such as upgrading the instance are recommended.

## Team Audit Log

From the Team page the Audit Log shows events relating to the management of the team.

This includes:

- Applications/Instances being created or deleted
- Users being added/removed from the team

This log contains all events since the team was created. Tou can view older data using the `Load More...` link at the bottom of the log.

![](https://flowfuse.com/docs/user/images/teamauditlog.png){width="500"}

### AI Agents and API Activity

For actions performed through FlowFuse Expert or the FlowFuse platform API, both this log and the instance/application-level [Audit Log](https://flowfuse.com/#audit-log) show an icon indicating how the action was performed:

- A sparkle icon means the action was performed by FlowFuse Expert on the user's behalf. Hovering over the icon shows the name of the tool that was called.
- A terminal icon means the action was performed through the FlowFuse API using a [Personal Access Token](https://flowfuse.com/docs/user/user-settings#personal-access-tokens).

Actions performed directly through the FlowFuse UI do not show an icon.

These logs provide visibility into supported FlowFuse Expert and API actions only.


# FlowFuse MQTT Nodes

Node-RED instances running within FlowFuse include a set of nodes that make it
simple to securely connect and send or receive messages between MQTT clients
in your team or externally connected clients via the [Team Broker](https://flowfuse.com/docs/user/teambroker/#getting-started-with-team-broker).

The nodes are very similar to the Node-RED MQTT nodes, but without the need
to configure any settings for your broker, making integration seamless.

### Nodes

There are two nodes in this collection:

- `MQTT In` - subscribes to fixed or dynamic topics
- `MQTT Out` - publishes messages to fixed or dynamic topics

The `MQTT In` node receives messages from the topic defined in the node's
configuration or the `msg.topic` property if it is set.

The `MQTT Out` node sends the `msg.payload` value to the topic defined in the node's
configuration or the `msg.topic` property if it is set.

See the built-in help on the Node-RED sidebar for more information about using these nodes.

### GitHub

The nodes are published under an Apache-2.0 license and available on [GitHub](https://github.com/FlowFuse/nr-mqtt-nodes){rel="&#x22;nofollow&#x22;"}.


# FlowFuse Persistent Context

Some Node-RED flows require the ability to persist context values between restarts and FlowFuse stack updates. By default, context data in Node-RED is ephemeral, meaning it does not survive restarts or stack updates. With FlowFuse's paid plans, however, you can enable **persistent context storage**, ensuring that your context values persist across restarts, upgrades, and more.

## Usage

In Node-RED with FlowFuse, you now have two context store options:

1. **Memory Context**: This is the default ephemeral context. Values stored in memory are not persistent and will be lost when Node-RED restarts or the Node-RED stack is updated.
2. **Persistent Context**: This allows context values to persist even when Node-RED restarts, updates.

The amount of persistent storage available to you depends on the FlowFuse plan you're subscribed to. FlowFuse offers different storage sizes for each plan, allowing you to select the appropriate level of storage for your needs. For detailed information on storage options, please refer to the [pricing page](https://flowfuse.com/pricing/){rel="&#x22;nofollow&#x22;"}.

### How to Use FlowFuse Persistent Context

Using persistent context in Node-RED is similar to using memory context, with the key difference being that you specify the storage type for your context data. Here’s how to use persistent context it:

#### Using Persistent Context in Nodes

When configuring persistent context in different nodes (e.g., Change, Inject, or Switch nodes), you can select the type of context storage to use. By default, the context type is set to **Memory**, but you can change it to **Persistent** to store values across restarts.

- **Change Node, Inject Node, Switch Node**: :br
  When you configure these nodes to store or access context data, you’ll notice a storage option at the right corner. By default, it will be set to **Memory**. To make the context **persistent**, simply switch the selection to **Persistent**.

![Persistent Store Option in Change Node](https://flowfuse.com/docs/user/images/variables-in-node-red-change-node-persistent-store-option.gif)

#### Using Persistent Context in Function Nodes

In **Function nodes**, you interact with context data using the `set` and `get` methods. These methods allow you to specify where the context data should be stored or accessed from.

- **Setting Context**:
  To set a persistent context value, use the `set` method with three arguments. The third argument specifies the context store, which should be set to **persistent**. For example:
  ```javascript
  context.set('myKey', 'myValue', 'persistent');
  ```

This argument is optional and defaults to memory. This means that if you leave it empty, it will use memory as the context store.

- **Getting Context**:

When retrieving persistent context, use the `get` method with two arguments. The second argument is optional and specifies the context store (either memory or persistent).

Example:

```javascript
var value = context.get('myKey', 'persistent');
```

If you don't specify the store, it defaults to memory.

For more detailed information, refer to the article [Understanding Node, Flow, Global, and Environment Variables in Node-RED](https://flowfuse.com/blog/2024/05/understanding-node-flow-global-environment-variables-in-node-red/){rel="&#x22;nofollow&#x22;"}.


# FlowFuse Project Nodes

Node-RED instances running within FlowFuse include a set of nodes that make it
very quick and easy to securely send and receive messages between different
instances in a team.

The nodes act in a similar way to the Node-RED Link nodes, but by allowing the
links to extend between different instances, they open up a wide range of
possibilities. Remote instances can take part too, with the limitations described
below.

For example, a single Node-RED instance may contain a set of utility flows that
you want to reuse in other instances. Rather than copy the flows around, the
Project Nodes allow you to easily call those flows and get the result back. The
flows stay in one place, so a change to them applies to every caller at once,
with the trade-offs covered in [Limitations](https://flowfuse.com/#limitations).

The project nodes are only available in the Enterprise tier of FlowFuse.

### Nodes

There are three nodes in this collection:

- `Project In` - listens for messages being broadcast by other Node-RED instances, or for
  messages being sent just to this instance
- `Project Out` - sends messages to other Node-RED instances
- `Project Call` - sends messages to other Node-RED instances and waits for a response

The nodes send the whole `msg` object. Due to the way the nodes
encode messages, there are some data types that do not get sent. For example,
the `msg.req`/`msg.res` properties used by the core HTTP nodes will not be sent.
Instead, they are temporarily removed from the message and re-attached when the
message is received back.

Each node is configured with a topic on which it either sends or receives messages
on. This is similar in concept to MQTT topics - although the nodes do not currently
support using MQTT wildcards in their topics.

The Project Out nodes can either broadcast messages on a topic to anyone listening,
or they can send messages on a topic to a specific other instance.

The Project In nodes do the opposite - they can either listen for messages being
broadcast, or for messages sent directly to them.

The Project Call node can be used to send a message to another Project In node
and then wait for a response, with a built-in timeout if it doesn't arrive.
The response is sent back using a Project Out node configured to respond to the call
node.

### Limitations

**Only hosted instances can be addressed directly.** The list of targets and sources
offered by the nodes is the hosted instances in your team. This applies to the
`Project Out` node when sending to a specific instance, the `Project In` node when
listening to a specific source, and the `Project Call` node's target.

**A remote instance can send, but cannot be sent to.** Flows on a remote instance can
use `Project Out` and `Project Call` to reach a hosted instance, and can receive
broadcasts. They cannot be named as a target, so shared logic being called by others
has to live on a hosted instance. A remote instance assigned to an application cannot
receive direct messages at all, and can only listen for broadcasts.

**Calls need the target to be up.** The `Project Call` node waits for the default
timeout of 30 seconds, then logs an error that can be caught with a Catch node. The
target instance must be running and have a `Project In` node listening on the same
topic. Because every call travels through the platform's broker, logic called this
way is unavailable to a caller whose connection to the platform is down.

**Load is shared only in HA mode.** The instance holding the called flows serves every
caller from a single Node-RED runtime. In [High Availability mode](https://flowfuse.com/docs/user/high-availability)
the nodes automatically switch to MQTT shared subscriptions, so calls are distributed
between the copies.

### GitHub

The nodes are published under an Apache-2.0 license and available on [GitHub](https://github.com/FlowFuse/nr-project-nodes){rel="&#x22;nofollow&#x22;"}.


# Role-Based Access Control

Role-based access control (RBAC) determines what actions users can perform within FlowFuse. By assigning roles to team members, you control who can create, modify, view, or delete resources.

## RBAC Levels

FlowFuse provides role-based access control at two levels:

1. **Team-Level RBAC** - Defines default permissions across all team resources
2. **Application-Level RBAC** - Overrides team-level permissions for specific applications

## Team-Level RBAC

Team-level roles establish baseline permissions for all resources within a team. Every team member is assigned one of four roles.

### Roles

**Owner**:br
Full administrative control over the team, including managing settings, members, and all resources.

**Member**:br
Can develop and manage flows, create snapshots, and modify environment variables. Cannot manage team settings or create/delete applications and instances.

**Viewer**:br
Read-only access to view flows, instance details, and snapshots. Cannot make any modifications.

**Dashboard Only**:br
Restricted access limited to viewing dashboards and HTTP endpoints only.

### Permissions

The table below shows which actions each role can perform.

| Action                            | Owner | Member | Viewer | Dashboard Only |
| --------------------------------- | ----- | ------ | ------ | -------------- |
| **Team Management**               |       |        |        |                |
| Manage Team Settings              | ✓     | -      | -      | -              |
| View Team Audit Log               | ✓     | -      | -      | -              |
| Invite User                       | ✓     | -      | -      | -              |
| Change User Role                  | ✓     | -      | -      | -              |
| Remove User from Team             | ✓     | §1     | §1     | §1             |
| **Applications**                  |       |        |        |                |
| Create Application                | ✓     | -      | -      | -              |
| Delete Application                | ✓     | -      | -      | -              |
| Modify Application Settings       | ✓     | -      | -      | -              |
| View Application Logs             | ✓     | ✓      | ✓      | -              |
| **Instances**                     |       |        |        |                |
| Create Instance                   | ✓     | -      | -      | -              |
| Delete Instance                   | ✓     | -      | -      | -              |
| Copy Instance                     | ✓     | -      | -      | -              |
| View Instance Details             | ✓     | ✓      | ✓      | -              |
| Start, Stop, Suspend Instance     | ✓     | -      | -      | -              |
| Modify Instance Settings          | ✓     | -      | -      | -              |
| Modify Environment Variables      | ✓     | ✓      | -      | -              |
| Manage Assets                     | ✓     | ✓      | -      | -              |
| View Node-RED Logs                | ✓     | ✓      | ✓      | -              |
| Access Dashboard or HTTP Endpoint | ✓     | ✓      | ✓      | ✓              |
| **Flows**                         |       |        |        |                |
| Access Flow Editor                | ✓     | ✓      | ✓      | -              |
| Modify Flows                      | ✓     | ✓      | -      | -              |
| **Snapshots**                     |       |        |        |                |
| Create Snapshot                   | ✓     | ✓      | -      | -              |
| Restore Snapshot                  | ✓     | ✓      | -      | -              |
| Set as Device Target              | ✓     | ✓      | -      | -              |
| View Snapshots                    | ✓     | ✓      | ✓      | -              |
| Download Snapshot                 | ✓     | ✓      | -      | -              |
| Upload Snapshot                   | ✓     | -      | -      | -              |
| Delete Snapshot                   | ✓     | -      | -      | -              |
| **Devices**                       |       |        |        |                |
| View Devices                      | ✓     | ✓      | ✓      | -              |
| Modify Device Settings            | ✓     | -      | -      | -              |
| Modify Environment Variables      | ✓     | ✓      | -      | -              |
| Assign to/Remove from Application | ✓     | -      | -      | -              |
| Assign to/Remove from Instance    | ✓     | -      | -      | -              |
| Delete Device                     | ✓     | -      | -      | -              |
| Bulk Move Devices                 | ✓     | -      | -      | -              |
| Bulk Delete Devices               | ✓     | -      | -      | -              |
| **Team Library**                  |       |        |        |                |
| Add an Item                       | ✓     | ✓      | -      | -              |
| Modify an Item                    | ✓     | ✓      | -      | -              |
| Delete an Item                    | ✓     | ✓      | -      | -              |
| **Team Broker**                   |       |        |        |                |
| Create Client                     | ✓     | ✓      | -      | -              |
| Delete Client                     | ✓     | ✓      | -      | -              |
| List Clients                      | ✓     | ✓      | -      | -              |

**Notes:**

- §1 Users in any role can remove themselves from a team
- Platform Administrators have owner-level access to all teams but cannot access the Flow Editor

### Managing Team-Level Roles

Team Owners can manage member roles from the **Team Members** page.

#### Setting Roles When Inviting Members

When inviting a new team member:

1. Navigate to the Team Members
2. Click **Invite Member**

![Invite team member popup](https://flowfuse.com/docs/user/images/invite-members.png){dataZoomable=""}

3. Enter the user's username or email address
4. Select the initial role (Owner, Member, Viewer, or Dashboard Only)

![Select role while inviting](https://flowfuse.com/docs/user/images/invite-popup.png){dataZoomable=""}

5. Send the invitation

The invited user will have the assigned role once they accept the invitation.

#### Changing Existing Member Roles

To change a team member's role:

1. Navigate to the Team Members page
2. Locate the user whose role you want to change
3. Click the three-dot icon next to their username
4. Select **Change Role**

![Change member role](https://flowfuse.com/docs/user/images/change-role.png){dataZoomable=""}

5. Choose the new role from the popup (similar to the invitation process)
6. Confirm the change

**Note:** An Owner can only change their own role if at least one other Owner exists on the team.

## Application-Level RBAC

Application-Level RBAC enables you to control permissions at the individual application level within a team. This allows different team members to have different permission levels for different applications without creating multiple teams.

This is an Enterprise lisenced feature for Self Hosted Users and requires an Entprise Team on FlowFuse Cloud.

### Overview

Team-level roles define default permissions across all resources. :br
Application-level roles override these defaults for specific applications.

When you assign an application-level role to a team member, it takes precedence over their team-level role **only** for that application. Their team-level role applies to all other applications.

### Available Roles

Application-level roles follow the same structure:

- **Owner** – Full control over the application
- **Member** – Can develop and manage flows, create snapshots, modify environment variables
- **Viewer** – Read-only access
- **Dashboard Only** – Can only view dashboards and HTTP endpoints

### Permission Hierarchy

1. If a user has an application-level role, that determines their permissions for the application.
2. If not, their team-level role applies.
3. Team Owners always have full access to all applications.

**Example:**:br
A team-level *Member* is assigned *Viewer* permissions for one production application. They can only view flows in that application, but retain normal Member permissions for all others.

### Configuring Application-Level Roles

Team Owners can configure application-level roles:

1. Navigate to the application
2. Open **Application Settings** → **User Access**
3. Click the three-dot icon next to the user and select **Edit Permission**

![Application user access settings](https://flowfuse.com/docs/user/images/application-rbac.png){dataZoomable=""}

4. In the popup, assign the desired application-level role

![Application RBAC popup](https://flowfuse.com/docs/user/images/application-rbac-popup.png){dataZoomable=""}

5. Changes apply immediately

To remove an application-level assignment, simply clear the role. The user will fall back to their team-level role for that application.


# Shared Team Library

Node-RED allows you to import and export **flows** and **functions** to a local library. This is helpful
for saving pieces of flow that you want to reuse.

With FlowFuse Premium, each Node-RED instance has access to a Team Library that makes
it very easy to share flows and functions without having to manually copy them around.

For example, you may have a standard set of flows that you want each Node-RED instance
to include. By exporting them to the Team Library, you can quickly import them wherever
you want to use them.

A short video is available on [how to use this feature](https://www.youtube.com/watch?v=B7XK3TUklUU){rel="&#x22;nofollow&#x22;"}.

### Exporting flows

To export flows to the library within the Node-RED editor:

1. Select the nodes to be included
2. Open the Export Dialog (`Main Menu -> Export`, or `Ctrl/Cmd-E`)
3. Select the `Team Library` tab
4. Enter a name for the library entry
5. Click Export

### Importing flows

To import flows within the Node-RED editor:

1. Open the Import Dialog (`Main Menu -> Import`, or `Ctrl/Cmd-I`)
2. Select the 'Team Library' tab
3. Select the flow to import
4. Click Import
5. Place the imported nodes within your flows

![](https://flowfuse.com/docs/user/images/shared-lib-import.png)

### Viewing Team Library

It is possible to explore your Team Library within FlowFuse by clicking "Library" in your Team options.

You can inspect the contents of any `.json` flow file, or `.js` function file here too.


# Snapshots

## Introduction

A Snapshot is a point-in-time backup of a Node-RED instance. It captures:

1. The flows
2. Credentials
3. Environment variables
4. NPM packages, with locked versions
5. Runtime settings.

## In this document

- [Application Snapshots Overview](https://flowfuse.com/#application-snapshots-overview) - An overview of all snapshots belonging to an application and the available actions
- [Instance Snapshots Overview](https://flowfuse.com/#instance-snapshots-overview)- An overview of all snapshots belonging to an instance
  - [Snapshots](https://flowfuse.com/#snapshot-list) - A list of all snapshots belonging to an instance and the available actions
  - [Timeline](https://flowfuse.com/#timeline-view) - A visual timeline of instance changes and snapshots interleaved
- [Device Snapshots Overview](https://flowfuse.com/#device-snapshots-overview) - An overview of all snapshots belonging to a device and the available actions
- [Create a snapshot](https://flowfuse.com/#create-a-snapshot) - Create a snapshot of a device or an instance
- [Restore Snapshot](https://flowfuse.com/#restore-a-snapshot) - Apply a snapshot to the runtime of a device or an instance
- [Edit a snapshot](https://flowfuse.com/#edit-a-snapshot) - Edit the name and description of a snapshot
- [Upload a snapshot](https://flowfuse.com/#upload-a-snapshot) - Upload a snapshot to a device or an instance
- [Download a snapshot](https://flowfuse.com/#download-a-snapshot) - Download a snapshot to your local machine
- [Delete a snapshot](https://flowfuse.com/#delete-a-snapshot) - Delete a snapshot
- [Set Device Target (instance)](https://flowfuse.com/#instance-owned-devices) - Set a snapshot as the target for all devices belonging to an instance
- [Creating a Snapshot from a device](https://flowfuse.com/#creating-a-snapshot-from-a-device) - Create a snapshot from the device overview page
- [Creating a Snapshot from within a device](https://flowfuse.com/#creating-a-snapshot-locally) - Create a snapshot from within Node-RED
- [Auto Snapshots](https://flowfuse.com/#auto-snapshots) - Automatically create snapshots when flows are deployed
- [Previewing Snapshots](https://flowfuse.com/#previewing-snapshots) - Preview the flows of a snapshot

## Snapshot Views:

### Application Snapshots Overview

All snapshots belonging to the instances and devices of an application are gathered and presented in a single list where you can perform the following actions:

- [Edit a snapshot](https://flowfuse.com/#edit-a-snapshot) - Edit the name and description of a snapshot
- [View Snapshot](https://flowfuse.com/#previewing-snapshots) - Preview the flows of a snapshot
- [Compare Snapshot](https://flowfuse.com/#comparing-snapshots) - Compare the snapshot with another snapshot
- [Download Snapshot](https://flowfuse.com/#download-a-snapshot) - Download the snapshot to your local machine
- [Delete Snapshot](https://flowfuse.com/#delete-a-snapshot) - Delete the snapshot

![Application Snapshots](https://flowfuse.com/docs/user/images/snapshots/application-snapshots.png)*Screenshot showing Applications Snapshot list*

### Instance Snapshots Overview

Snapshots belonging to an instance are presented as a list or a visual timeline:

#### Snapshot List

Snapshots belonging to an instance are gathered and presented in a single list where you can perform the following actions:

- [Upload Snapshot](https://flowfuse.com/#upload-a-snapshot) - Upload a snapshot to the instance
- [Create Snapshot](https://flowfuse.com/#create-a-snapshot) - Create a snapshot of the instance
- [Restore Snapshot](https://flowfuse.com/#setting-a-device-target-snapshot) - Restore the snapshot to the instance
- [Edit Snapshot](https://flowfuse.com/#edit-a-snapshot) - Edit the snapshot name and description
- [View Snapshot](https://flowfuse.com/#previewing-snapshots) - Preview the snapshot flows
- [Compare Snapshot](https://flowfuse.com/#comparing-snapshots) - Compare the snapshot with another snapshot
- [Download Snapshot](https://flowfuse.com/#download-a-snapshot) - Download the snapshot to your local machine
- [Set as Device Target](https://flowfuse.com/#setting-a-device-target-snapshot) - Set the snapshot as the device target snapshot
- [Delete Snapshot](https://flowfuse.com/#delete-a-snapshot) - Delete the snapshot

![Instance Snapshots](https://flowfuse.com/docs/user/images/snapshots/instance-snapshots.png)*Screenshot showing Instance Snapshot list*

#### Timeline View

The timeline view shows a visual representation of changes made to an instance with
available snapshots interleaved to signify when they were created.

Any snapshots displayed inline on the timeline will have the same actions available as in the Snapshot List view above.

![Visual Timeline](https://flowfuse.com/docs/user/images/snapshots/instance-timeline.png)*Screenshot showing Instance Visual Timeline*

### Device Snapshots Overview

Snapshots belonging to a device are presented in a single list where you can perform the following actions:

- [Upload Snapshot](https://flowfuse.com/#upload-a-snapshot) - Upload a snapshot to the instance
- [Create Snapshot](https://flowfuse.com/#create-a-snapshot) - Create a snapshot of the instance
- [Restore Snapshot](https://flowfuse.com/#setting-a-device-target-snapshot) - Set the snapshot as the devices target snapshot
- [Edit Snapshot](https://flowfuse.com/#edit-a-snapshot) - Edit the snapshot name and description
- [View Snapshot](https://flowfuse.com/#previewing-snapshots) - Preview the snapshot flows
- [Compare Snapshot](https://flowfuse.com/#comparing-snapshots) - Compare the snapshot with another snapshot
- [Download Snapshot](https://flowfuse.com/#download-a-snapshot) - Download the snapshot to your local machine
- [Delete Snapshot](https://flowfuse.com/#delete-a-snapshot) - Delete the snapshot

![Device Snapshots](https://flowfuse.com/docs/user/images/snapshots/device-snapshots.png)*Screenshot showing Device Snapshot list*

## Snapshot Actions

### Create a snapshot

To create a snapshot:

1. Go to the device or instance's page and select the **Snapshots** tab.
2. Click the **Create Snapshot** button.
3. You will be prompted to give the snapshot a **name** and optional **description**.
4. Click **Create**

The list of snapshots will update with the newly created entry at the top.

### Restore a snapshot

To restore a snapshot:

1. Go to the desired device or instance page and select the **Snapshots** tab.
2. Open the dropdown menu to the right of the snapshot you want to restore and
   select the **Restore Snapshot** option.
3. You will be asked to confirm - click **Confirm** to continue.

### Edit a snapshot

To edit a snapshot:

1. Go to the instance's page and select the **Snapshots** tab.
2. Open the dropdown menu to the right of the snapshot you want to edit and
   select the **Edit Snapshot** option.
3. Update the name and description as required.
4. Click **Update**

NOTE:
Changes made to a snapshot will not be immediately reflected in the Node-RED runtime already running this snapshot.

### Upload a snapshot

A snapshot can be uploaded to an device or instance from your local machine.

To upload a snapshot:

1. Go to the desired instance or device overview page and select the **Snapshots** tab.
2. Click the **Upload Snapshot** button.
3. Select the snapshot file from your local machine.
4. Update the name and description if required.
5. Select the components to upload:
   - **Flows**: Include the snapshots flows
   - **Credentials**: Include the snapshots flows credentials (visible only if the snapshot contains credentials)
   - **Environment Variables**: Include environment variables in the snapshot
     - **Keys and Values**: Include the keys and values of the environment variables
     - **Keys Only**: Include only the keys of the environment variables
6. If the snapshot contains credentials and the `Credentials` component is checked,
   you will be asked to enter a Secret. This will be used to later decrypt any credentials in the snapshots flows.
7. Click **Upload**

### Download a snapshot

A snapshot can be downloaded to your local machine for backup or sharing.

To download a snapshot:

1. Go to the desired application, instance or device overview page and select the **Snapshots** tab.
2. Open the dropdown menu to the right of the snapshot you want to download and
   click the **Download Snapshot** option to open the download dialog.
3. Select the required components to download.
   - **Flows**: Include the snapshot flows
   - **Credentials**: Include the snapshot flows credentials
   - **Environment Variables**: Include environment variables in the snapshot
     - **Keys and Values**: Include the keys and values of the environment variables
     - **Keys Only**: Include only the keys of the environment variables
4. Enter a secret to encrypt any credentials in the snapshot (optional, depends on components selected).
5. Click **Download**

### Delete a snapshot

To delete a snapshot:

1. Go to the instance's page and select the **Snapshots** tab.
2. Open the dropdown menu to the right of the snapshot you want to delete and
   select the **Delete snapshot** option.
3. You will be asked to confirm - click **Delete** to continue.

*Note:* If the snapshot is the current **Device Target** snapshot, this will
cause any connected devices to stop running the snapshot when they next check in.

### Setting a Device Target snapshot

Snapshots are used to identify a version of the Node-RED instance that should be pushed
out to any connected devices. This allows you to develop your flows in FlowFuse
and only push out to the devices when it is ready.

#### Instance owned devices

To set the **Device Target** of an instance owned device:

1. Go to the instance's page and select the **Snapshots** tab.
2. Open the dropdown menu to the right of the snapshot you want to set as the
   device target and select the **Set as Device Target** option.
3. You will be asked to confirm - click **Set Target** to continue.

This will cause the snapshot to be pushed out to any connected devices the
next time it checks in.

#### Application owned devices

To set the **Device Target** of an application owned device:

1. Go to the devices's page and select the **Snapshots** tab.
2. In the list of snapshots available, a "Restore Snapshot" button will be displayed
   for each snapshot as you hover over it.
3. You will be asked to confirm - click the **Confirm** button to set it as the target snapshot.

This will cause the snapshot to be pushed out to the device the
next time it checks in.

### Creating a Snapshot from a device

It is possible to create a Snapshot from a device that is connected to the platform.
The device must be set to Developer Mode for this to work.
See [Working with Devices](https://flowfuse.com/docs/device-agent/deploy) for
more information.

### Creating a Snapshot locally

Using the [Node-RED Tools Plugin](https://flowfuse.com/docs/migration/node-red-tools) it is also possible to create
Snapshots in a local copy of Node-RED and push them back into your FlowFuse
managed Node-RED instances.

For more information, see the [Node-RED Tools Plugin guide](https://flowfuse.com/docs/migration/node-red-tools).

### Auto Snapshots

FlowFuse can automatically create snapshots whenever flows are deployed
to the instance. This is useful for tracking changes, and rolling back.

FlowFuse will label these snapshots as "Auto snapshot - yyyy-mm-dd hh\:mm\:ss".
A limit of 10 auto snapshots will be kept, with the oldest being deleted when a new one is created.

Devices can optionally disable auto snapshots, in the developer mode tab. This can be helpful to
avoid excessive data usage when a device is in the field or on a cellular connection.

NOTE: This feature is only available to Enterprise tier teams

### Previewing Snapshots

From any Snapshots tab, you can preview the flows of a snapshot by selecting the Snapshot's actions,
and selecting "View Snapshot".

![Screenshot to show the available "Actions" for a given Snapshot](https://flowfuse.com/docs/user/images/snapshots-actions.png)*Screenshot to show the available "Actions" for a given Snapshot*

![Screenshot to an example flow preview for a Snapshot in FlowFuse](https://flowfuse.com/docs/user/images/snapshots-preview.png)*Screenshot to an example flow preview for a Snapshot in FlowFuse*

### Comparing Snapshots

From any Snapshots tab, you can compare two snapshots by selecting the Snapshot's action, then selecting "Compare Snapshots". This will open a dialog where you choose a second snapshot to compare with.

The comparison view has three panels:

- **Left sidebar**— lists every node that differs between the two snapshots. Each entry shows a node-type badge (config node, tab, or regular node) and one of three statuses:
  - **Added** — the node exists in the newer snapshot but not the older one
  - **Deleted** — the node existed in the older snapshot but has been removed
  - **Changed** — the node exists in both snapshots but one or more properties differ
- **Flow canvas** — highlights the selected node and scrolls to it automatically, giving a visual indication of where the change is in your flow
- **Right panel** — shows the property and code changes for the selected node. Use the **Prev / Next** buttons to step through changes one at a time

Selecting an entry in the sidebar highlights the corresponding node on the canvas. The highlight clears automatically when you select a different entry.

There are two types of diff shown in the right panel:

- **Property diffs** — each changed property is shown with the old and new value side by side, with red `-` for removed and green `+` for added

![Screenshot showing property-level diff with old and new values displayed side by side](https://flowfuse.com/docs/user/images/snapshots/snapshot-diff-prop-change.png)*Screenshot showing property-level diff with old and new values displayed side by side*

- **Code diffs** — for multiline properties such as function and template nodes, changes appear as a line-level diff with red `-` for removed lines and green `+` for added, in the same format as a git diff. Use the **Prettify** and **Wrap** toggles to make large or nested values easier to read

![Screenshot showing a code diff for a function node with red and green line-level changes](https://flowfuse.com/docs/user/images/snapshots/snapshot-diff-code-change.png)*Screenshot showing a code diff for a function node with red and green line-level changes*

Not every difference between two snapshots is meaningful. Computed layout properties such as group node `w` and `h` values are automatically excluded because they are recalculated by Node-RED and do not reflect intentional edits. Position-only changes (nodes that moved on the canvas but had no property edits) can be hidden when you want to focus on substantive changes.


# Static asset service

Our platform now includes a Static Asset Service, enabling you to manage files seamlessly within your hosted Node-RED instances.

## What is Static asset service?

The Static Asset Service allows you to store files permanently within your FlowFuse Instances. Files that you upload, generate, or modify will remain accessible even after your session ends or the application restarts.

## Prerequisites

### FlowFuse Cloud

- A Instance Stack with a launcher version of 2.8.0 or greater.
- Enterprise Team Type.

### Self-Hosted

This feature is available only on self-hosted Enterprise licensed versions of FlowFuse.

### Limitations

- Uploaded file sizes must not exceed 5MB.
- Unsupported characters (dependent on the operating system):
  - empty paths (eg: `/`, `//` or `\`, `\\`)
  - special chars: `*`, `:`
- Team permissions required: owner / member

## Getting Started

If the prerequisites are met, you will be able to use the Static Asset Service capabilities of FlowFuse Instances from two locations:

- Instance Assets tab within the **Instance Details** page.
  ![Instance Details Page](https://flowfuse.com/docs/user/images/assets-tab-instance.png){dataZoomable=""}
- Instance Assets tab within the **Immersive Editor**.
  ![Immersive Editor](https://flowfuse.com/docs/user/images/assets-tab-editor.png){dataZoomable=""}

The following steps assume that you have navigated to one of these locations and have the assets tab opened.

### Files

#### Uploading a File

To upload a file, click the 'Upload' button, select your desired file, and click confirm. This will upload the file to the current storage folder.

*Note: Uploading a file with the same name as an existing one will overwrite the existing file.*

#### Deleting a File

Navigate to the file you want to delete, click on the kebab menu (three vertical dots) associated with the file, select 'Delete File,' and confirm when prompted.

#### Renaming a File

Currently, this feature is not supported. To rename a file, upload the file with the desired name and delete the old one from the instance's Persistent Storage.

*Caution: Renaming a file will also affect any linked files or relative paths to that file in the Node-RED instance.*

### Folders

#### Creating a Folder

To create a folder, click the 'New Folder' button, enter your desired folder name, and click confirm. This will create the folder inside the current directory.

#### Deleting a Folder

Navigate to the folder you want to delete, click on the kebab menu associated with the folder, select 'Delete Folder,' and confirm when prompted.

*Caution: Deleting a folder that contains files or other folders will permanently delete all nested files and folders.*

#### Renaming a Folder

Navigate to the folder you want to rename, click on the kebab menu, select 'Edit Folder,' and confirm the new name when prompted.

*Caution: Renaming a folder will also affect any linked files or relative paths of nested files or directories in the Node-RED instance.*

#### Folder Navigation

You can navigate through folder structures by clicking on any folder and return by using the Working Directory Breadcrumbs located at the top of the Search Files input.

#### Folder Visibility

Following the 2.9.0 release, you can set the folder's visibility using the Visibility selector found in the Navigation section.
This means that users can set the visibility of their uploaded files to public and make them accessible outside the node-red instance itself.

When setting a folder's visibility to public you are required to set a static file path on which the files will be served by your instance.

![static-assets-visibility-selector.png](https://flowfuse.com/docs/user/images/static-assets-visibility-selector.png){dataZoomable=""}

![static-assets-select-static-path.png](https://flowfuse.com/docs/user/images/static-assets-select-static-path.png){dataZoomable=""}

![static-assets-public-visibility.png](https://flowfuse.com/docs/user/images/static-assets-public-visibility.png){dataZoomable=""}

Considerations:

- Visibility and static path maps can be set on folders only.
- Any change in visibility settings require an instance restart in order for the changes to take effect.

### How to use

The following video is a quick demonstration on how to use assets inside a FlowFuse Node RED Instance:

:video[
Your browser does not support the video tag.]{controls="true" width="800"}


# Teams

Teams are groups of users that collaborate on their Node-RED applications.

## Managing Teams

### Creating a New Team

Users can create new teams. Creating a team requires a name and a unique url. The user who creates the team is added as its "owner".

**Note:** Administrators might not [allow all users to create teams](https://flowfuse.com/docs/admin/introduction#admin-settings). FlowFuse Cloud does allow any user to create a new team.

### Adding Team Members

Each user with "owner" permissions on a team can invite new members on the "Members" tab of the team page. Invitations can be sent to existing users on the platform by their username, or via email. Users have up to 7 days to accept, or decline, the invitation before it will expire.

When inviting a member, you can assign them an initial role (Owner, Member, Viewer, or Dashboard Only). This role can be changed later by team owners. For more details on managing roles, see [Role-Based Access Control](https://flowfuse.com/docs/user/role-based-access-control).

### Removing Team Members

Owners can remove a member from a team by clicking the dropdown menu next to the username and selecting `Remove from team`. The team member will no longer have access to any team data.

## Role-Based Access Control

FlowFuse uses role-based access control to manage what users can do within teams and applications. For detailed information about roles, permissions, and access control at both team and application levels, see the [Role-Based Access Control documentation](https://flowfuse.com/docs/user/role-based-access-control).


# Getting Started with Team Broker

When FlowFuse is deployed with an Enterprise license from v2.11.0 onwards comes with the option to enable a MQTT broker for each Team.

This is a single shared MQTT broker, but each team has their own separate topic space and the ability to provision credentials for clients. It removes the need to install and manage a broker of your own.

## Foreword

FlowFuse offers zero config MQTT integration with the Team Broker via the [FlowFuse MQTT Nodes](https://flowfuse.com/docs/user/mqtt-nodes/) that greatly simplifies the whole process by removing the need for manual configuration.

If you wish to continue using traditional MQTT clients, the below sections will guide you through the process of creating clients and connecting to the broker.

## Creating Clients

When creating clients you can specify a username, it will prepended to the the Team's id e.g. `alice` will become `alice@32E4NEO5pY`.

This username should also be used as the MQTT Client ID in order to connect to the broker. Examples of how to do this are in the [next section](https://flowfuse.com/#connecting-to-the-broker).

![Create Broker Client](https://flowfuse.com/docs/cloud/images/create-broker-client.png)

## Connecting to the Broker

The broker for FlowFuse Cloud is available on `broker.flowfuse.cloud` and supports the following connection types:

- MQTT on port `1883`
- MQTT over TLS on port `8883`
- MQTT over secure WebSockets on port `443`

For Self Hosted instances, please ask your Administrator for hostname and ports.

You can connect to the broker using any MQTT client, for example `mosquitto_sub`

```text
mosquitto_sub -u "alice@32E4NEO5pY" -i "alice@32E4NEO5pY" -P "password" -h broker.flowfuse.cloud -t "#"
```

Please note that username **must** also be used for the client id to connect to the team broker. This does mean that each
username/password can only be used with a single MQTT client at a time.

Or in Node-RED as follows

![Node-RED MQTT Client Connection](https://flowfuse.com/docs/cloud/images/node-red-mqtt-connection.png)

![Node-RED MQTT Client Security](https://flowfuse.com/docs/cloud/images/node-red-mqtt-security.png)


# User Settings

Access the FlowFuse User settings by clicking on your username in the top right corner.

![User Settings](https://flowfuse.com/docs/user/images/user-settings.png)

## Settings

In the Settings section, you can modify various characteristics of your personal user account:

- **Username**
- **Name**
- **E-Mail** (modifiable only if SSO is disabled)
- **Theme** - choose **Light**, **Dark**, or **System** for the FlowFuse interface. **System** follows your operating system setting and updates live when it changes. Your choice is saved per browser. This applies to the FlowFuse application only; the Node-RED editor and Dashboard manage their own themes separately.

Additionally, you can select a default Team, especially useful if your account is associated with multiple Teams.

## Teams

The Teams tab provides an overview of all teams associated with your User account. Here, you can also view and respond to open invitations.

## Security

### Change Password

Under the Security section, you have the option to change your password. For this, you need to enter your current and new password.

### Two-Factor Authentication

Two-factor authentication adds an extra layer of security to your account. It requires a second form of identification when logging in. Note that when signing in via your SSO provider, you will not be prompted for a two-factor authentication code.

To set up Two-factor authentication, click on `Enable two factor authentication` and follow the instructions.

### Personal Access Tokens

Personal Access Tokens are useful for interacting with [FlowFuse APIs](https://flowfuse.com/docs/api/){rel="&#x22;nofollow&#x22;"}. You can set these tokens to have a limited or unlimited lifespan. Tokens can be revoked at any time by removing them from your account. Remember, tokens with an expiry date will automatically delete upon reaching that date. It's important to note that the token value is only displayed once, at the time of creation. There is no way to retrieve the token value after this point.

### Creating a Token

1. Click **Add Token**.
2. Enter a name for the token.
3. Optionally, tick **Add Expiry Date** and choose a date.
4. Configure the token's scope (see below).
5. Click **Create**.

![Creating a new scoped Personal Access Token](https://flowfuse.com/docs/user/images/scoped-pat.png){dataZoomable=""}

### Scoping a Token

- **Read Only** - restricts the token to read-only operations. Write operations, such as creating, updating, or deleting resources, are denied.
- **Team Scope** - limits the token to specific Teams. If no Teams are selected, the token can access every Team you belong to, including Teams you join in the future. If specific Teams are selected, the token does not automatically gain access to any new Team you join later - you need to edit the token to add it.
- **Admin Access** - only shown if your account has admin privileges. A token does not carry admin privileges by default, even if your account does; this must be enabled explicitly for that token.

These restrictions can only narrow a token's access - a token can never do more than your own account is permitted to do.


# Introducing FlowFuse Inc.

When Dave and I first created [Node-RED](https://nodered.org){rel="&#x22;nofollow&#x22;"}, it was a tool to solve a
problem - allowing us to do our day job more effectively when building IoT solutions
for clients. That gave us the means and purpose to create a truly useful platform.

When it became an open source project, it quickly found an enthusiastic audience that
has seen the community grow beyond our imagination. From both individual users, to a wide
range of companies integrating it into their own products.

But with that growth, the question in my mind has always been how to take it further
and secure its long term future.

I wrote on the [project blog](https://nodered.org/blog/2020/10/13/future-plans){rel="&#x22;nofollow&#x22;"}
last year about the future plans of the project. A key piece of that is its sustainability -
how we can increase the commercial adoption of Node-RED and how we can get more people
contributing back.

An opportunity presented itself earlier this year that I believe will bring a
step-change to what the Node-RED project is able to achieve.

### Introducing FlowFuse Inc.

So today, I'm launching FlowFuse Inc - a new company whose mission is to build a low-coding development
platform fit for the enterprise with Node-RED at its heart.

Backed by [Sid Sijbrandij](https://www.linkedin.com/in/sijbrandij/){rel="&#x22;nofollow&#x22;"}, we have funding
in place to create a fully remote team dedicated to an open core model.

In the short term, this means helping to accelerate the plans already in place for
the Open Source project. Getting the 2.0 release done in the next few weeks, working on
long-standing features such as the Test framework and Flow Debugger.

Alongside that we'll also be building a platform around Node-RED that will make it easier
to adopt at scale and integrate into existing enterprise environments.

Node-RED remains a fully open source project, with its home at the OpenJS Foundation
and an open governance model that allows anyone to have a say in its development.

Our goal is to incorporate as much of our work directly into the core project as possible. Where we do create closed-source components, we will work with the community to ensure the right APIs and extension points are in the core for all to benefit from.

We will only be successful if the whole Node-RED community is successful.

For me personally, this is a really exciting next step. I never expected to turn my little side project into a full-time job and now into a company.

### Hiring soon!

We'll be hiring soon - so keep an eye out if you're interesting in getting involved.


# Welcome Ben

I'm excited to share the news that Ben Hardill ([@hardillb](https://twitter.com/hardillb){rel="&#x22;nofollow&#x22;"}) is joining FlowFuse as a Senior Engineer.

I've known Ben for many years, having worked together at IBM. He's been an active member
of the Node-RED community since the start of the project and he published one of
the very first [3rd party nodes](https://flows.nodered.org/node/node-red-node-geofence){rel="&#x22;nofollow&#x22;"}.

He is ever-present on Stack Overflow, to the point where I've long since stopped
rushing to respond to questions tagged with [`node-red`](https://stackoverflow.com/questions/tagged/node-red){rel="&#x22;nofollow&#x22;"}
in the full knowledge that he has usually beaten me to it.

More recently he's been doing some really interesting work exploring [multi-tenant Node-RED systems](https://www.hardill.me.uk/wordpress/2020/10/01/multi-tenant-node-red/){rel="&#x22;nofollow&#x22;"} - something we'll
be continuing at FlowFuse.

Welcome aboard Ben!


# Community News January 2022

Welcome to the first FlowFuse newsletter, we’re going to publish this as a regular roundup of what\`s happening with both FlowFuse and the wider Node-RED community, if you want to receive it via email, sign up for updates at the bottom of the page.

If you’ve got something that you’d like us to share please email <contact@flowfuse.com>.

[FlowFuse 0.1 Released](https://flowfuse.com/blog/2022/01/flowforge-01-released/):br
First up we are really pleased to ship the first version of our platform, this is a very early release but hopefully will give you an idea of the direction we’re going in.

[Node-RED 2.2](https://nodered.org/blog/2022/01/27/version-2-2-released){rel="&#x22;nofollow&#x22;"}:br
The next version of Node-RED has been released with new editor features, predefined environment variables and improvements to some of the core nodes. Checkout the blog post and change log for more details.

[Make your IoT data beautiful](https://blog.golioth.io/building-iot-dashboards-with-golioth-grafana-and-node-red){rel="&#x22;nofollow&#x22;"}:br
Ben Mawby wrote a guide on connecting Golioth's WebSocket endpoints to Grafana using Node-RED and InfluxDB

[Alexa Voice Service on Node-RED](https://www.sammachin.com/posts/alexaweb-reborn){rel="&#x22;nofollow&#x22;"}:br
Sam Machin rebuilt an app on Node-RED allowing you to talk to Alexa through the browser. And he has published a new [node](https://flows.nodered.org/node/@sammachin/node-red-alexa-voice-service){rel="&#x22;nofollow&#x22;"} to use the Alexa Voice Service within your own flows.

[New Team Members](https://flowfuse.com/blog):br
We welcomed 2 new members of the FlowFuse team this month [ZJ](https://flowfuse.com/blog/2022/01/welcome-zj/) joins as our CEO and [Steve](https://flowfuse.com/blog/2022/01/welcome-steve/) has come onboard to work on the Node-RED project

[We are Hiring](https://boards.greenhouse.io/flowfuse/jobs/4312861004){rel="&#x22;nofollow&#x22;"}:br
We're looking for the next member of our team, If you're a Node.JS developer and want to work with us take a look at the link.


# FlowFuse 0.1 released

For an open core company, we haven't been very open with what we're doing. That all
changes today with the release of FlowFuse 0.1 and making all of our repositories
public.

This is a significant step for the company as we look to build a platform around Node-RED.

The main question we get asked is: 'What is FlowFuse?" - which is a very reasonable
question to ask.

FlowFuse is a platform for managing Node-RED instances at scale. It lets you have
multiple users on the platform, organised into teams to provide proper access control
to individual Node-RED instances, or Projects as we call them.

With the 0.1 release, we have the basic building blocks of the platform in place.

- Add multiple users to the platform
- Create teams for those users
- Create Node-RED projects quickly and easily through the platform UI

For a more complete walk-through of the platform in this early release, you can
watch this video.

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: YYZDx8n17Ys
---
::

### Getting started with FlowFuse

The documentation provides a guide for [installing FlowFuse on a local server](https://github.com/FlowFuse/flowfuse/tree/main/docs){rel="&#x22;nofollow&#x22;"}.

We also have drivers for deploying to Docker Compose and Kubernetes based environments
to enable a larger scale of deployment. We'll have more documentation on those options
in the near future.

### Getting help

If you hit any problems with the platform, or have questions to ask, please do
raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.

That also includes if you have any feedback or feature requests.

### What's next?

With so much in the plan and lots of exciting features to come, we will have a
regular cycle of releases every four weeks. So you can expect the next release, 0.2,
on Thursday 17th February.

As we're only at 0.1 today, there is a lot still to do. We will be following the
principles of [Semantic Versioning](https://semver.org/){rel="&#x22;nofollow&#x22;"} with our releases,
but until we reach 1.0, there may be some disruptive changes along the way.

Sign up to the mailing list below if you want to hear more about the work we're
doing.


# Welcome Steve

We're continuing to grow the FlowFuse team with our latest hire; Steve McLaughlin
who is joining our development team.

Steve is a well known face in the Node-RED community. He is a regular contributor
to the community forum, always happy to help users with their questions.

He has published a number of very popular nodes, include [buffer-parser](https://flows.nodered.org/node/node-red-contrib-buffer-parser){rel="&#x22;nofollow&#x22;"},
[cron-plus](https://flows.nodered.org/node/node-red-contrib-cron-plus){rel="&#x22;nofollow&#x22;"} and
[image-tools](https://flows.nodered.org/node/node-red-contrib-image-tools){rel="&#x22;nofollow&#x22;"}.

He has also made some significant contributions to the core of Node-RED, such as
delivering MQTTv5 support and introducing the Monaco code editor into the heart
of the editor.

Steve joins us from a background in Industrial IoT in the automative manufacturing
space - experience and knowledge that will be invaluable as we look to growing the
FlowFuse platform.

Steve will be focussed on the Node-RED side of our activities - helping to continue
the ongoing development and growth of the open source project at the heart of what
FlowFuse is about.

Welcome aboard Steve!


# Welcome ZJ

This year the FlowFuse team will grow further, and I'm excited to announce our
newest addition to the team; Zeger-Jan van de Weg ([@ZJvandeWeg](https://twitter.com/ZJvandeWeg){rel="&#x22;nofollow&#x22;"}).
Zeger-Jan, also known as ZJ, is joining FlowFuse as CEO.

ZJ previously worked at GitLab where he helped build a vibrant open source
community and we're thrilled to have him to continue this with the Node-RED
community. Under his supervision the involvement of GitLab in the Git project
grew significantly, allowing Git and GitLab to be successful together. This aligns
well with our vision for FlowFuse:

> We will only be successful if the whole Node-RED community is successful.

As our first non-engineering hire, ZJ will be focussed on growing the business side
of FlowFuse, working on marketing and ongoing business development.

Welcome aboard ZJ!


# Announcing FlowFuse Cloud

As an open core company, anyone is free to [download and install](https://github.com/FlowFuse/flowfuse/tree/9219e81399eaf52fb0ee5573707a52f5520fbfdd/docs/install){rel="&#x22;nofollow&#x22;"}
our platform. In many cases this is a great solution, it
allows for custom setups in your own environment. We know this isn't for everyone
though, some people just want to start building with Node-RED without having to manage their servers.

We are excited to announce FlowFuse Cloud, a hosted
Node-RED as a service offering and today we are opening the waitlist.

Our waitlist captures your email, and we'll reach out to you on that address once your account is created.

### Starting operations

After having released v0.2 recently, we're now working on v0.3 that will include
a user flow for [billing](https://github.com/FlowFuse/flowfuse/issues/224){rel="&#x22;nofollow&#x22;"}.
When that work has been done and deployed people on the waitlist will slowly be invited to the platform.
Currently that's scheduled for April 1st, no joke, although it could happen either sooner
or later.
More details on the exact pricing will be availble nearer the time.

Once you are invited you will be able to;

- Create multiple Node-RED projects hosted on flowforge.cloud,
- Invite team members to collaborate on those projects,
- And many more features will automatically become availble with each new release.


# FlowFuse 0.2 released

Four weeks have passed since our initial release of FlowFuse, and we're happy
to release v0.2 today as we continue moving forward and evolve the platform.

There aren't lots of headline features in this release to tell you about as a lot
of the work has been on the internals, as well as responding to some of the early
feedback from the community.

Features like improving the test framework, and building a database migration
framework may not sound too exciting to the end user, but they are critical pieces
when build a platform that needs to be stable and easy to upgrade.

We've also been doing work to get our own instance of the platform running in the
Cloud - and figuring out how to automate as much of that as possible. Aside
from being a key way to test the platform, it helps validate the work we're doing
for when others come to run it in that way. It also lays the ground work for our
own cloud service we'll be sharing more about in the coming days.

The full change-log for the core of the platform is available [on GitHub](https://github.com/FlowFuse/flowfuse/blob/v0.2.0/CHANGELOG.md){rel="&#x22;nofollow&#x22;"}.
But with a further 15 repositories containing different components, each with its
own change-log, we're still thinking about how best to share a single view of the
updates.

### Getting started with FlowFuse

The documentation provides a guide for [installing FlowFuse on a local server](https://github.com/FlowFuse/flowfuse/tree/main/docs){rel="&#x22;nofollow&#x22;"}.

If you haven't played with FlowFuse 0.1 yet, here's a more complete walk-through
of the platform:

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: YYZDx8n17Ys
---
::

### Upgrading FlowFuse

If you installed FlowFuse 0.1 and want to upgrade, our documentation provides a
guide for [upgrading FlowFuse on a local server](https://flowfuse.com/docs/upgrade/).

### Getting help

If you hit any problems with the platform, or have questions to ask, please do
raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.

That also includes if you have any feedback or feature requests.

We also have a `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.

### What's next?

Our regular release cycle puts the next release on Thursday 17th March. We've
got some key features planned in this release around [Project Templates](https://github.com/FlowFuse/flowfuse/issues/141){rel="&#x22;nofollow&#x22;"} and [Stacks](https://github.com/FlowFuse/flowfuse/issues/285){rel="&#x22;nofollow&#x22;"} -
which will underpin how you can customise Node-RED within FlowFuse.

We'll also have some exciting news to share about our own hosted service you'll
be able to sign-up for.

Sign up to the mailing list below if you want to hear more about the work we're
doing.


# Using Node-RED to keep Solar PV afloat

[Krisnan Ravichandran](https://www.linkedin.com/in/krishnanravichandran/){rel="&#x22;nofollow&#x22;"} works
for [spb sonne](https://www.sbp.solar){rel="&#x22;nofollow&#x22;"}, a engineering consultancy for renewable
energy. Within the company he is part of the engineering effort on the
[Gömbhal](https://www.sbp.de/en/news/goembhal-sbp-sonnes-pioneering-floating-pv-system/){rel="&#x22;nofollow&#x22;"}
project, creating a floatation device for solar panels.

In this post, he shares his experiences of using Node-RED.

Currently there’s a prototype deployed in Hungary, while the company is located
in Stuttgart: “We’re remotely monitoring the installation. There are over 40
sensors that all connect to an ADAM-6717, Compact Intelligent Gateway. When the
data is acquired we leverage Node-RED flows that maintain the structure, monitor
performance, and provide reporting back to our offices.

Node-RED is embedded in the ADAM 6717, it was very new to me. I was already
experienced in programming, mainly Python, and within a month I felt very
comfortable and productive in Node-RED. Understanding programming is useful,
though not a necessity.

Building and improving flows I did on my own through trial-and-error, as well
as a lot of times through help on the [Node-RED Forum](https://discourse.nodered.org/){rel="&#x22;nofollow&#x22;"}.
The community is helpful and welcoming to new users. Now I maintain multiple
flows with very different purposes. Some track temperature,
irradiation wind-speed, direction, tilt and wave height; to ensure the floating
PV installation remains floating. Other sensors are connected to actuators
through flows that control pressure.

We do have some challenges; the ADAM 6717 contained an older version of Node-RED.
This raised questions around security and maintenance, as our Node-RED version
isn’t updated to a newer version in an easy manner. It also hampers training a
bit because documentation might reference an API or node for a flow that’s just
not the same on older versions.

However, I’d choose Node-RED again, it’s well known as well as easy to learn.
Furthermore I found it very versatile.”

---

Thanks to Krisnan for sharing his story. If you have a Node-RED story for us
to share, please get in touch via <contact@flowfuse.com>.


# Welcome Joe

Today we welcome Joe Pavitt ([@joepavitt3d](https://twitter.com/joepavitt3d){rel="&#x22;nofollow&#x22;"}) as
our new Head of UX & Design. This is a key role that will help deliver the awesome
user experience of the FlowFuse platform.

Joe has a passion for user experience, data visualisation and creativity in
technology. He joins us having been at IBM for 9 years where he specialised in
building bespoke, first of a kind experiences in IBM's Emerging Technology and
Research teams.

We worked together at IBM and I saw first-hand the range and quality of what he
can do. I was super pleased when he agreed to join us and I look forward to
seeing the real impact he'll have on what we're building.

Welcome aboard Joe!


# Community News February 2022

Welcome to the FlowFuse newsletter, a regular roundup of what\`s happening with both FlowFuse and the wider Node-RED community.

If you've got something that you'd like us to share please email <contact@flowfuse.com>.

[Announcing FlowFuse Cloud](https://flowfuse.com/blog/2022/02/announcing-flowforge-cloud/):br
We are excited to announce FlowFuse Cloud, a hosted Node-RED as a service offering and today we are opening the waitlist.

[FlowFuse 0.2](https://flowfuse.com/blog/2022/02/flowforge-02-released/):br
We continue to iterate with our 4 weekly releases of the FlowFuse platform.

[Node-RED 2.2.2](https://discourse.nodered.org/t/node-red-2-2-2-released/58606){rel="&#x22;nofollow&#x22;"}:br
The 2.2 release of Node-RED (last month) has received 2 maintenance releases to fix bugs with duplicate wires in the editor and MQTT.

[New Team Members](https://flowfuse.com/blog/2022/02/welcome-joe/):br
FlowFuse is now up to 6 people, Joe Pavitt has joined the team

[We still are Hiring](https://boards.greenhouse.io/flowfuse/jobs/4312861004){rel="&#x22;nofollow&#x22;"}:br
We're looking for the next member of our team, If you're a Node.JS developer and want to work with us take a look at the link.


# FlowFuse 0.3 released

The FlowFuse 0.3 release brings us closer to the launch of FlowFuse Cloud.
Find out more about what's in this new release.

This release of the FlowFuse platform brings some significant new features that
will underpin more of what is to come.

### Project Stacks & Templates

When we think about what a makes a Project inside FlowFuse, the simple answer
is Node-RED.

The more complete answer is: a version of Node-RED, a version of Node.js, some
memory, some CPU and a bunch of Node-RED settings to customise the instance.

In a platform like FlowFuse, it's important to have the tools to manage all
of these things.

This is where Project Stacks and Template come in.

A Project Stack defines the underlying characteristics of the Node-RED process -
or the container it is running in. For example, with our Local deployment model,
it defines the version of Node-RED to use and how much memory the process should
try to use. In our container based deployment models, the stack identifies the
container to use for the project, along with memory and CPU limits.

In a future release, this will be the way we will support upgrading the version
of Node-RED a project is using - and doing so in a well managed way. An Administrator
will be able to create a new Stack containing the new version of Node-RED.
Project owners will then be able to update their projects to use the new Stack -
at a time that is convenient to them.

A Project Template is more about how the Node-RED instance is configured - exposing
the options a user would traditional modify in their Node-RED settings file.
With this release, we're not exposing a lot of settings as the focus has been
more on the underlying Template concept. But it will be the basis for gradually
exposing more options for customisation in the future.

- [Epic #285 - Project Stacks](https://github.com/FlowFuse/flowfuse/issues/285){rel="&#x22;nofollow&#x22;"}
- [Epic #141 - Project Templates](https://github.com/FlowFuse/flowfuse/issues/141){rel="&#x22;nofollow&#x22;"}

### Billing Integration

With our open core philosophy, the heart of the FlowFuse platform is open source
and available under the Apache 2 license for anyone to use.

But the plan was always to have certain features that were licensed separately.

This release brings the first of those features - Stripe Billing Integration. This
feature brings the ability to require a Team to have a Stripe Billing agreement
in place and to be able to charge on a per-project basis within that Team.

Being able to charge is an important feature for any commercial platform, and
with our own FlowFuse Cloud launching soon, we needed to get this feature in
place today.

We've structured the code in the repository and updated the LICENSE file to make it
very clear what parts of the code base are *not* covered by the Apache 2 license.

- [Epic #224 - Billing](https://github.com/FlowFuse/flowfuse/issues/224){rel="&#x22;nofollow&#x22;"}

### Getting started with FlowFuse

The documentation provides a guide for [installing FlowFuse on a local server](https://github.com/FlowFuse/flowfuse/tree/main/docs){rel="&#x22;nofollow&#x22;"}.

If you haven't played with FlowFuse yet, here's a more complete walk-through
of the platform:

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: YYZDx8n17Ys
---
::

### Upgrading FlowFuse

If you installed FlowFuse 0.1 or 0.2 and want to upgrade, our documentation provides a
guide for [upgrading FlowFuse on a local server](https://flowfuse.com/docs/upgrade/).

### Getting help

If you hit any problems with the platform, or have questions to ask, please do
raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.

That also includes if you have any feedback or feature requests.

We also have a `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.

### What's next?

Our regular release cycle puts the next release on Thursday 14th April.

We're still in planning stage for the release, but we'll also be beginning to invite
people from the waiting list to sign-up to FlowFuse Cloud.

For more information, check out the [annoucement blog post](https://flowfuse.com/blog/2022/02/announcing-flowforge-cloud/).
You can also sign up to our general mailing list below if you want to hear more
about the work we're doing.


# Community News March 2022

Welcome to the FlowFuse newsletter, a regular roundup of what\`s happening with both FlowFuse and the wider Node-RED community.

If you've got something that you'd like us to share please email <contact@flowfuse.com>.

[New Website](https://flowfuse.com):br
Some of you may have noticed the new design on our website, this is the first step in our more refined corporate identity, the same look will be coming to the FlowFuse application [soon.](https://github.com/FlowFuse/flowfuse/issues/430){rel="&#x22;nofollow&#x22;"}.

[FlowFuse 0.3](https://flowfuse.com/blog/2022/03/flowforge-03-released/):br
The latest release introduced 2 new concepts, Templates and Stacks, with these we are starting to show the value of the FlowFuse platform allowing you to easily manage the Node-RED settings and versions used by your projects.

[Intro to JSON for Node-RED](https://www.opto22.com/support/resources-tools/videos/video-introduction-to-json-for-node-red/){rel="&#x22;nofollow&#x22;"}:br
Our friends over at Opto 22 published a handy guide to JSON and how it works in Node-RED, great introduction for new builders and a good refresher for seasoned pros.


# FlowFuse 0.4 released

This release of the FlowFuse adds a seemingly small, but significant new feature.

With [Node-RED 3.0 fast approaching](https://nodered.org/about/releases/){rel="&#x22;nofollow&#x22;"} we've been making sure we are ready to support this.

### Upgrading Node-RED

The goal of FlowFuse is to be the best way to run Node-RED at any scale, whether that's many users or many instances. Node-RED is a constantly developing as a platform and therefore part of running Node-RED is also upgrading the version you are running.

With the 0.4 release today we've made that super simple in FlowFuse. Last month we introduced the concept of [Project Stacks](https://flowfuse.com/docs/user/concepts/#stack). One of the key elements of a Stack was the version of Node-RED in use. Initially this may have seemed fairly basic, when you create a new project you usually want to use the latest version of Node-RED. However what happens when a new version is released and you have an existing project?
Now you can change the stack that a project is running on, which in turn will change the version of Node-RED. This is a simple process from the project settings, it only requires a short period of downtime while the project restarts on the new stack, typically around 10-15 seconds.

Our driver to get this feature into the 0.4 release is the approaching release of Node-RED 3.0, now we know that we can be ready to offer our users Node-RED 3.0 as soon as it is released.

We will also be making available the Beta's of Node-RED 3.0 within FlowFuse Cloud, this becomes a great way to test out the new features without having to touch your own environments.

- [Story #288 - Change Stacks](https://github.com/FlowFuse/flowfuse/issues/288){rel="&#x22;nofollow&#x22;"}
- [Docs](https://flowfuse.com/docs/user/changestack/)

### Environment Variables

Another key new feature we are introducing is the ability to set and manage environment variables within your projects.
Environment Variables are a key tool when building applications as they allow you to to separate the configuration of your system from the logic in the code. Even in Low-Code platforms this is an important design pattern. Environment variables are fully integrated into [Templates](https://flowfuse.com/docs/user/concepts/#template) that we introduced last month so they can be set both at the platform level or on an individual project.
Our plans for the next release will make these even more useful as we introduce the ability to [duplicate a project](https://github.com/FlowFuse/flowfuse/issues/271){rel="&#x22;nofollow&#x22;"} and then modify those variables for the new project.

- [Story #225 - Project Environment Variables](https://github.com/FlowFuse/flowfuse/issues/225){rel="&#x22;nofollow&#x22;"}
- [Docs](https://flowfuse.com/docs/user/envvar/)

### There's more

There are many more improvements in this release, such as the ability to [Set the timezone](https://github.com/FlowFuse/flowfuse/issues/239){rel="&#x22;nofollow&#x22;"} your project is running in, we've also been iterating on our billing experience as we've welcomed the first paying customers to FlowFuse Cloud.

Finally we're very happy that we've had our first external contribution to the code base, as an Open Core company we believe strongly that Open Source lives at the heart of everything we do.
We would like to say a big thank-you to [Fakorede Damilola Idris](https://fakocodes.netlify.app/){rel="&#x22;nofollow&#x22;"} for his work on fixing a [bug](https://github.com/FlowFuse/flowfuse/issues/424){rel="&#x22;nofollow&#x22;"} in the UI.

### Getting started with FlowFuse

The documentation provides a guide for [installing FlowFuse on a local server](https://flowfuse.com/docs/install/).

If you haven't played with FlowFuse yet, here's a more complete walk-through
of the platform:

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: YYZDx8n17Ys
---
::

### Upgrading FlowFuse

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading FlowFuse on a local server](https://flowfuse.com/docs/upgrade/#upgrading-flowfuse).

### Getting help

If you hit any problems with the platform, or have questions to ask, please do
raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.

That also includes if you have any feedback or feature requests.

We also have a `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.

### What's next?

Our regular release cycle puts the next release on Thursday 12th May.
We will be building on features in the last few releases around managing your projects and using templates, we're also setting the foundations of our work to [manage Node-RED on your own devices running at the Edge](https://github.com/FlowFuse/flowfuse/issues/446){rel="&#x22;nofollow&#x22;"}.

For more information, check out the [announcement blog post](https://flowfuse.com/blog/2022/02/announcing-flowforge-cloud/).

You can also sign up to our general mailing list below if you want to hear more
about the work we're doing.


# FlowFuse is accepting customers now

A year ago our CTO, Nick O'Leary, [introduced FlowFuse](https://flowfuse.com/blog/2021/04/first-deploy/).
Since then major milestones have been achieved. As we grow as a company, important
steps are taken. Today we make another very important step; we're accepting our
first customers.

A few weeks ago our product was nearly in a state where it could support customers,
when that was the case, we [opened up our waitlist](https://flowfuse.com/blog/2022/02/announcing-flowforge-cloud/).
The waitlist has been growing daily and now we're ready to start inviting those
users onto the platform. The first
lucky few users are being added today, and each working day for the foreseeable
future we'll continue onboarding users. New users will receive an email from our
team with their login details and can start creating new workflows with Node-RED
minutes after.

While the source code of FlowFuse is [available](https://github.com/FlowFuse/flowfuse){rel="&#x22;nofollow&#x22;"},
there's a chance you're unfamiliar with what has been built around Node-RED.
With FlowFuse, our intent is to build a platform to aid with colaboration of
flows in Node-RED. The first steps to our vision include a managed Node-RED
instance to connect virtually any online service. Multiple users will have
access to the same flows and can collaborate. Further, once Node-RED 3.0 has
been released, the platform will provide a pain-free way to upgrade and keep
your projects up to date. There's many more exciting features right around the
corner on our [roadmap](https://flowfuse.com/changelog/)


# Community News April 2022

Welcome to the FlowFuse newsletter, a regular roundup of what\`s happening with both FlowFuse and the wider Node-RED community.

If you've got something that you'd like us to share please email <contact@flowfuse.com>.

[FlowFuse 0.4](https://flowfuse.com/blog/2022/04/flowforge-04-released/):br
The next release has enabled us to offer multiple versions of Node-RED along with adding more features to help you configure your Node-RED projects.

[Node-RED 3.0.0-beta-1](https://discourse.nodered.org/t/node-red-3-0-0-beta-1-released/62124){rel="&#x22;nofollow&#x22;"}:br
The first beta for Node-RED 3.0.0 has been published, there's some exciting improvements on UI in the editor to make designing your flows even easier.

[Node-RED Beta on FlowFuse](https://flowfuse.com/blog/2022/05/node-red-3-beta-stack/):br
As promised in out 0.4 announcement, we've made the beta available to our users on FlowFuse as a separate stack, this is just one way that we're able to demonstrate the flexibility you get from running Node-RED on FlowFuse.

[Cisco & Node-RED](https://developer.cisco.com/meraki/build/exploring-meraki-and-spark-apis-with-node-red/){rel="&#x22;nofollow&#x22;"}:br
The team at Cisco DevNet published some great guides on using Node-RED to manage both your Meraki Access points and to integrate with WebEx Teams, they've also produced a handy [starter guide](https://blogs.cisco.com/developer/helloworldlowcodenodered01){rel="&#x22;nofollow&#x22;"} for those that are new to Node-RED

[Node-RED Con 2022](https://nrcon.nodered.org){rel="&#x22;nofollow&#x22;"}:br
Our friends in the Node-RED Japan User Group have run a number of successful Node-RED conferences over the last few years. This year, we're joining forces with them to bring the event to a wider audience. The [Call for Papers](https://www.papercall.io/nrcon2022){rel="&#x22;nofollow&#x22;"} is open now and we'd love to see your submissions.


# FlowFuse 0.5 released

The cycle continues with our next regularly scheduled release, bringing a fresh
new look to the platform.

Since joining the team, Joe has been hard at work bringing a more consistent
design language to what we're doing. This release brings a lot of his hardwork
to the platform itself.

There's more to be done on the individual pages of the platform, but this
gives us a solid framework to build on.

![](https://flowfuse.com/blog/2022/05/images/ff-05-dashboard.png)

- [Epic #430 - Rebrand Forage App](https://github.com/FlowFuse/flowfuse/issues/430){rel="&#x22;nofollow&#x22;"}

### Copying Projects

One of the usage scenarios we want to support is having an easy way to have separate
test and production environments. The previous release added the ability to configure
environment variables on individual projects.

This release unlocks the next piece of the puzzle - making it easy to copy flows
between projects.

The Project settings page has two new options:

- Copy Project lets you create a complete copy of the project.
- Export to existing project lets you copy over selected aspects of the project
  over to another project.

In both cases, you get to pick what parts of the project should be copied.

- [Epic #268 - Export Project](https://github.com/FlowFuse/flowfuse/issues/268){rel="&#x22;nofollow&#x22;"}
- [Story #271 - Duplicate Project](https://github.com/FlowFuse/flowfuse/issues/271){rel="&#x22;nofollow&#x22;"}
- [Story #272 - Export to Existing Project](https://github.com/FlowFuse/flowfuse/issues/272){rel="&#x22;nofollow&#x22;"}

### Improve Billing Information

We've been getting some great feedback from the users of FlowFuse Cloud. One of the
areas we identified as needing some more clarity was around the point users are
asked to setup their billing information.

- [Story #563 - Improve Information on billing](https://github.com/FlowFuse/flowfuse/issues/563){rel="&#x22;nofollow&#x22;"}

### Edge Devices

Whilst we always want to deliver new functionality to end users in each release,
sometimes bits of work don't fit naturally into a single four week iteration.

That's the case here with some of the preliminary work we've done to introduce
the idea of Edge Devices to the platform.

The goal here is to provide a way to easily deploy and manage Node-RED projects
on remote devices.

This release introduces a bunch of work to the core app and front-end to begin
introducing the concept of a Device. It includes the basic workflows for registering
a device on the platform and being able to assign it to a team.

The whole feature is hidden behind a feature flag so users on FlowFuse Cloud won't
see any of this quite yet.

The next release will introduce the Edge Agent piece of this - the bit that runs
on devices.

- [Epic #446 - Devices](https://github.com/FlowFuse/flowfuse/issues/446){rel="&#x22;nofollow&#x22;"}

### Upgrading FlowFuse

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading FlowFuse on a local server](https://flowfuse.com/docs/upgrade/#upgrading-flowfuse).

### Getting help

If you hit any problems with the platform, or have questions to ask, please do
raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.

That also includes if you have any feedback or feature requests.

We also have a `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.


# Node-RED 3.0 Beta Stack

The first beta of Node-RED 3.0 is here and FlowFuse is ready for you to try it out.

When we released [FlowFuse 0.4](https://flowfuse.com/blog/2022/04/flowforge-04-released/) last month we talked about allowing users to select the stack their project runs on.
Until now we've only offered one stack which has been the latest Node-RED release (2.2.2).

Yesterday the first beta of Node-RED 3.0 was [released](https://discourse.nodered.org/t/node-red-3-0-0-beta-1-released/62124){rel="&#x22;nofollow&#x22;"}, so as of today we have added a choice of stacks to FlowFuse Cloud. You can stick with the *Default* and use Node-RED 2.2.2 or if you want to try out the beta you can select *Node-RED-3.0.0-beta-1*.

:video{ariaLabel="Selecting the beta Stack" autoPlay="true" height="730" loop="true" muted="true" playsInline="true" preload="none" width="954"}

FlowFuse is the best way to run multiple Node-RED instances at different versions. Beta releases are exciting to try out, but you don't want to risk your production applications with an early upgrade. FlowFuse makes it easy to create a new project to try things out.

We'll continue to update the stack choice with each beta when they are released.


# FlowFuse open for everybody

FlowFuse wants to enable everyone to build workflows in Node-RED. Since announcing
[FlowFuse Cloud](https://flowforge.com/blog/2022/02/announcing-flowforge-cloud/){rel="&#x22;nofollow&#x22;"}
two months ago we've had a waiting list for users to sign up to. That allowed us
to control the pace we were bringing new users onto the platform, learning what
is needed to scale up our platform and continue to improve our first user experience.

Today we have removed the waiting list. Anyone can sign up to FlowFuse and start a
new Node-RED project in under a minute!

::div{.max-w-md.m-auto}
[Sign up](https://app.flowfuse.com/account/create){.ff-btn.ff-btn--primary}
::

## What we offer

Besides the sub minute time to start a new Node-RED project, there's many more
features our offering includes. Two we'd like to highlight.

To start our blog highlight reel: Collaboration. FlowFuse allows you to work
with a team on your flows. There's the ability to create multiple users, each
with their own credentials that can alter the flows on Node-RED, and it's
execution environment like for example the [environments variables](https://flowforge.com/docs/user/envvar/){rel="&#x22;nofollow&#x22;"}.

Furthermore, [stacks](https://flowforge.com/docs/user/changestack){rel="&#x22;nofollow&#x22;"}. These allow
a user to select the execution environment for their Node-RED project. For example; the
Node-RED version being used. Combined with the ability for one to copy a project
to a new stack, this allows FlowFuse users to copy their project to the Node-RED
3.0-beta stack to validate their solutions will continue to work on the new release
without disrupting their main project.

## Our roadmap

Currently we're working towards our 0.6 release. The main feature of this release
will be support for Devices. This will allow you to send a snapshot of a project
to a Node-RED instance running outside of the FlowFuse platform and update the flows
remotely. Remote devices will run our [agent](https://github.com/FlowFuse/device-agent){rel="&#x22;nofollow&#x22;"}
to communicate with the FlowFuse Cloud project.

While the first iteration will be considered an Alpha release, by shipping early and often, it lets us get
welcome feedback from our users and the wider community - helping to shape the future direction.
It also allows users to start validating the feature for their own proof of concept projects.

Over the next few months we're continuing to drive development of the platform
across a number of areas - including further improvements to the Device feature.
But also looking at new Enterprise-ready features, such as Single-Sign On integration
and more tools to make collaboration even easy.

We intend to grow our offering so that FlowFuse remains the best way to run
Node-RED.

Stay informed by registering for our newsletter!


# Community News May 2022

Welcome to the FlowFuse newsletter, a regular roundup of what\`s happening with both FlowFuse and the wider Node-RED community.

If you've got something that you'd like us to share please email <contact@flowfuse.com>.

[FlowFuse 0.5 AND 0.6](https://flowfuse.com/blog/2022/06/flowforge-06-released/):br
We've had two releases since our last newsletter, there are a lot of related features between them.
We introduced a new design for the forge application which aligns with the branding on our website.
We've added [Devices](https://flowfuse.com/docs/user/concepts/#device), allowing you to run and manage your Node-RED projects on your own hardware, this is ideal for applications that need to connect to either sensor data or specialist hardware deployed outside the cloud.
We added a new concept as part of this work, [Snapshots](https://flowfuse.com/docs/user/concepts/#snapshot) allow you to take a point in time copy of your project, today that can then be deployed to one or more devices but we have plans to expand this concept for things like [rolling back](https://github.com/FlowFuse/flowfuse/issues/587){rel="&#x22;nofollow&#x22;"} a project to a previous point in time.
[0.5](https://flowfuse.com/blog/2022/05/flowforge-05-released/) Introduced the capabilities of copying a project or certain parts of it, allowing for scenarios like having multiple environments for Development and Production.

[Node-RED 3.0.0-beta-3](https://discourse.nodered.org/t/node-red-3-0-0-beta-3-released/64027){rel="&#x22;nofollow&#x22;"}:br
The Node-RED 3.0 beta releases continue as the project is getting very close to the full release in the coming weeks, We'll be making it availble on FlowFuse cloud very soon.

[Creating custom node from subflow in Node-RED](https://kazuhitoyokoi.medium.com/creating-custom-node-from-subflow-in-node-red-ce52cc42bbba){rel="&#x22;nofollow&#x22;"}:br
One of the contributors to Node-RED, Kazuhito Yokoi wrote a nice tutorial on how to turn a subflow into a custom node.

[YouTube Channel](https://www.youtube.com/channel/UCbBzP8NZbv3WDtlt4UouA-g){rel="&#x22;nofollow&#x22;"}:br
Joe has been busy creating short videos to present FlowFuse and our key concepts, these will start to appear on our YouTube channel, so please like and subscribe!

[Visa Direct in Node-RED](https://www.42flows.tech/blog/why-have-we-decided-to-implement-visa-direct-api-for-node-red/){rel="&#x22;nofollow&#x22;"}:br
The folks over at 42flows use Node-RED in a financial and banking context, they've published an article about integrating with the Visa payments APIs

[Node-RED Con CFP](https://www.papercall.io/nrcon2022){rel="&#x22;nofollow&#x22;"}:br
A reminder about Node-RED Con and the call for papers, submissions close at the end of July but don't wait until the last minute to submit your proposal.


# FlowFuse 0.6 released

Node-RED is well known for its role in IoT solutions - which often means running
flows on devices.

This was something we always wanted to support in FlowFuse and with this release
we're taking the next steps in that direction.

### Devices

This release includes the first alpha release of the [FlowFuse Device Agent](https://github.com/FlowFuse/device-agent){rel="&#x22;nofollow&#x22;"}. This is a small piece of node.js software that can be
installed on a device, such as a Raspberry Pi. It connects back to the FlowFuse
platform to get the Node-RED flows it should be running.

This builds on the work we added in 0.5 that lets you register the device,
generate credentials for it and pick which Project in your team it should be assigned
to.

It makes it super simple to start developing your flows in FlowFuse and push them
out to a group of devices with a couple clicks.

There's plenty of work still to come on the Devices feature. Under the covers
it uses an HTTP polling approach to check for updates. That was a pragmatic choice
to get something working - but it isn't our long term strategy. We'll be working
towards a more IoT-native MQTT/WebSocket appoach in the coming releases.

- [Devices documentation](https://flowfuse.com/docs/device-agent/introduction/)
- [Epic #446 - Devices](https://github.com/FlowFuse/flowfuse/issues/446){rel="&#x22;nofollow&#x22;"}

### Snapshots

This release adds the ability to create Snapshots of your projects. These are
point-in-time backups of your project's flows, credentials and settings.

With this release we support *creating* snapshots and pushing them to devices.

We don't have the ability to revert a project back to a previous snapshot, but
that will come soon.

- [Snapshot documentation](https://flowfuse.com/docs/user/snapshots/)
- [Story #587 - Snapshot/Rollback](https://github.com/FlowFuse/flowfuse/issues/587){rel="&#x22;nofollow&#x22;"}

### Other updates

Beyond these headline features, there are a number of smaller, but just as useful
items in this release.

We've continued with the rebranding work started in 0.5 with some more improvements
to the overall UX of the platform. Little touches like placeholder loading graphics
give the UI a more responsive feel.

When you log out of the platform we now also automatically log you out of any
Node-RED editor sessions you have open.

### Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 0.6 - ready for
you to start creating snapshots and adding devices right now.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading FlowFuse on a local server](https://flowfuse.com/docs/upgrade/#upgrading-flowfuse).

### Getting help

If you hit any problems with the platform, or have questions to ask, please do
raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.

That also includes if you have any feedback or feature requests.

We also have a `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.


# Community News June 2022

Welcome to the FlowFuse newsletter, a regular roundup of what\`s happening with both FlowFuse and the wider Node-RED community.

If you've got something that you'd like us to share please email <contact@flowfuse.com>.

[FlowFuse 0.7 ](https://flowfuse.com/blog/2022/07/flowforge-07-released):br
We've shipped the next version of FlowFuse, features in this release include the ability to Rollback a project to a previous snapshot, setting environment variables for a specific device and we've begun to unify the experience between the Forge app and the Node-RED editor with our own Node-RED theme.

[Node-RED 3.0 Released ](https://nodered.org/blog/2022/07/14/version-3-0-released){rel="&#x22;nofollow&#x22;"}:br
Node-RED 3.0 Has been officially released, there are a lot of improvements in the user experience of the editor, with new menus and junctions. There's also the ability to stop your flows while you can continue to edit and deploy. Take a look at the blog post for all the details. This is now the default stack on FlowFuse Cloud.

[Node-RED for Microcontrollers](https://discourse.nodered.org/t/node-red-flows-on-esp8266-and-esp32/64345){rel="&#x22;nofollow&#x22;"}:br[Peter Hoddie](https://twitter.com/phoddie){rel="&#x22;nofollow&#x22;"} of [Moddable](https://moddable.com){rel="&#x22;nofollow&#x22;"} Has released some early [work](https://github.com/phoddie/node-red-mcu){rel="&#x22;nofollow&#x22;"} on getting the Node-RED runtime to execute a flow on a microcontroller like the ESP32. It's still very early days so don't expect to be building flows directly on the MCU, and the number of nodes that are supported is limited, but this is an interesting development for Node-RED in the IoT space.

[Node-RED Con CFP](https://www.papercall.io/nrcon2022){rel="&#x22;nofollow&#x22;"}:br
A reminder about Node-RED Con and the call for papers, submissions close at the end of July so get your proposals in now.


# FlowFuse 0.7 released

Rollback projects to a previous snapshot, improvements in using Devices, and more.

Keep reading for the details of whats in this release our you can watch our 1 min roundup video of the new release above.

We're pleased to announce version 0.7 is now available. the next release of the FlowFuse application.

## Features

[Rollback](https://github.com/FlowFuse/flowfuse/issues/587){rel="&#x22;nofollow&#x22;"}
FlowFuse is about running Node-RED at any scale, part of that scale is having multiple users collaborate on the same project. When you are collaborating with people it's important to be able to go back in time to a known working state. As part of that we are introducing rollbacks, this means that you can now take a snapshot of your project at a point in time and then make changes safe in the knowledge that you can rollback to that previous snapshot if you need to.

[Device Environment Variables](https://github.com/FlowFuse/flowfuse/issues/680){rel="&#x22;nofollow&#x22;"}
In the last release we introduced the concept of devices. We're already learning from how these are used and one feature we've added in 0.7 is Device Environment Variables. You have been able to set Environment Variables at the project level but when deploying a snapshot to multiple devices you may want to override these values for each device, for example to set a site ID. With device specific variable users are enabled to differentiate based on the context in their flows.

[FlowFuse Theme](https://github.com/FlowFuse/flowforge-nr-theme/){rel="&#x22;nofollow&#x22;"}
Now that we have a stronger visual identity in the Forge application we have continued that work through to the Node-RED editor. If you create or upgrade a project with a Node-RED 3.0 stack you will see a different theme in the editor. It's still very much Node-RED but just has some subtle hints to tie it back to the FlowFuse application. We will continue to iterate on this to further integrate the experience between FlowFuse and Node-RED in both directions.
!["Screenshot showing the FlowFuse theme when the Node-RED 3.0 stack is selected"](https://flowfuse.com/blog/2022/07/images/ff-07-theme.png "Screenshot showing the FlowFuse theme when the Node-RED 3.0 stack is selected")

[ProjectTypes](https://github.com/FlowFuse/flowfuse/issues/380){rel="&#x22;nofollow&#x22;"}
The introduction of ProjectTypes is a way to group Stacks together that share common characteristics - such as memory/cpu limits, or the availability of particular features. In platforms with billing enabled, such as our own FlowFuse Cloud, the ProjectTypes can have different price points set on them. Within FlowFuse Cloud, you'll see we've introduced the Small ProjectType - which applies to all existing projects on the platform.

[Stack Versions](https://github.com/FlowFuse/flowfuse/issues/694){rel="&#x22;nofollow&#x22;"}
This allows an admin to link different stacks together in their lineage. This allows administrators to nudge users to new Node-RED versions or upgrade pre-installed dependencies when running in a container environment. Any users with projects on an old version will be prompted that there is an update available, making it even easier to stay up to date with Node-RED versions when you build your flows on FlowFuse.

## Improvements

We've made a number of improvements to the overall experience of running FlowFuse.

- The Team Switch menu has been moved to a more prominent position in the interface, this also makes it easier to see how to create a new team. [#616](https://github.com/FlowFuse/flowfuse/issues/616){rel="&#x22;nofollow&#x22;"}
- Notifications have had an overhaul, you will now see waiting invites on all pages. [#515](https://github.com/FlowFuse/flowfuse/issues/515){rel="&#x22;nofollow&#x22;"}
- If you are running your own copy of FlowFuse you can now see the version details in the admin pages [#655](https://github.com/FlowFuse/flowfuse/issues/655){rel="&#x22;nofollow&#x22;"}
- Device polling is no longer an INFO level message filling the log on your devices [#10](https://github.com/FlowFuse/device-agent/issues/10){rel="&#x22;nofollow&#x22;"}

## Bug Fixes

We've fixed the following bugs in this release.

- [Devices now listen on all Interfaces allowing you to run local http servers](https://github.com/FlowFuse/device-agent/issues/7){rel="&#x22;nofollow&#x22;"}:br
- [Solved an issue where a device gets an error unknown device](https://github.com/FlowFuse/device-agent/issues/7){rel="&#x22;nofollow&#x22;"}:br
- [The Audit Log in the Forge app displays the correct IP when a user logs in to Node-RED](https://github.com/FlowFuse/flowfuse/issues/507){rel="&#x22;nofollow&#x22;"}:br
- [Resolved an issue with devices downloading snaphots from legacy stacks](https://github.com/FlowFuse/flowfuse/issues/507){rel="&#x22;nofollow&#x22;"}:br
- [Fixed an error where objects in the Node-RED log would hang the log page](https://github.com/FlowFuse/flowfuse/issues/735){rel="&#x22;nofollow&#x22;"}:br
- [Next Billing Date is now shown correctly](https://github.com/FlowFuse/flowfuse/issues/745){rel="&#x22;nofollow&#x22;"}:br
- [Fixed a bug where the loading page would flash during polling](https://github.com/FlowFuse/flowfuse/issues/689){rel="&#x22;nofollow&#x22;"}:br

### Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 0.7 - ready for
you to try out rollbacks and the new theme.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading FlowFuse on a local server](https://flowfuse.com/docs/upgrade/#upgrading-flowfuse).

### Getting help

If you hit any problems with the platform, or have questions to ask, please do
raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That also includes if you have any feedback or feature requests.

Customers of FlowFuse Cloud can raise a ticket by emailing <support@flowfuse.com>

We also have a `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.


# Introducing Medium Projects on FlowFuse Cloud

We've added a second size of project to FlowFuse Cloud. A bigger project type with more resources available to it.

Our [0.7 release](https://flowforge.com/blog/2022/07/flowforge-07-released/){rel="&#x22;nofollow&#x22;"} introduced the concept of Project Types. This allows platforms to provide different sizes of projects, varying the memory/cpu or features available within a given type.

Today we've put this feature to work on FlowFuse Cloud by introducing the new **Medium Project** type.
!["Screenshot showing the new stack selection feature"](https://flowfuse.com/blog/2022/07/images/project-type.png "Screenshot showing the new stack selection feature")

Medium projects have 3 times the resources of the existing Small type, allowing for more complex flows and larger message objects. This will be useful to business users looking to process complex sets of data.

Our Medium project is priced at $50 a month and we'll be adding new features to this project type in the coming months to further enhance the value of this new tier.

We don't currently support directly upgrading a project between types, but that is in the [plan for the future](https://github.com/FlowFuse/flowfuse/issues/595){rel="&#x22;nofollow&#x22;"}. In the meantime, you can use the 'Export Project' feature on a project's settings tab to copy it over into a new Medium type project.


# Community News July 2022

Welcome to the FlowFuse newsletter, a regular roundup of what\`s happening with both FlowFuse and the wider Node-RED community.

If you've got something that you'd like us to share please email <contact@flowfuse.com>.

[FlowFuse 0.8 ](https://flowfuse.com/blog/2022/08/flowforge-08-released/):br
Version 0.8 was released, notable features include the new Project Link nodes for sharing data between projects, and the ability to stop and start flows within Node-RED.
We've updated the format of our release posts as well to detail all the user facing changes, from new Features through to small improvements and bugs.

[Raspberry Pi Pico with Node-RED](https://www.tomshardware.com/how-to/raspberry-pi-pico-w-node-red){rel="&#x22;nofollow&#x22;"}:br[Les Pounder](https://twitter.com/biglesp){rel="&#x22;nofollow&#x22;"} Has published a great tutorial on communicating with the new [Raspberry Pi Pico W](https://www.raspberrypi.com/products/raspberry-pi-pico/){rel="&#x22;nofollow&#x22;"} and Node-RED. He shows you how to capture data from an environmental sensor then display this on a dashboard.

[Medium Projects](https://flowfuse.com/blog/2022/07/new-projecttype/):br
We've added a second size of project to FlowFuse Cloud. A bigger project type with more resources available to it.

[Using Node-RED to control IoT Devices on Golioth](https://blog.golioth.io/how-to-use-node-red-to-control-iot-devices-on-golioth/){rel="&#x22;nofollow&#x22;"}:br
Our friends at [Golioth](https://golioth.io/){rel="&#x22;nofollow&#x22;"} have published an article on how to use Node-RED to control and process data from IoT Devices connected to their platform.

[Node-RED 3.0.2 and 2.2.3](https://discourse.nodered.org/t/node-red-2-2-3-and-3-0-2-released/66018){rel="&#x22;nofollow&#x22;"}:br
Node-RED 3.0.2 has been released fixing some bugs in the 3.0.0 release, The Node-RED 2.x stream has also had a maintenance release with many of the fixes in 3.0 back-ported. As usual these are already available as stacks on FlowFuse Cloud.


# FlowFuse 0.8 released

Easily pass messages between your projects on the cloud or devices, UX improvements, and more.

Keep reading for the details of whats in this release our you can watch our 1 minute roundup video of the new release above.

We're pleased to announce version 0.8 is now available. The next release of the FlowFuse application containing new features, a number of improvements, and bug fixes.

## Features

[Project Link Nodes](https://github.com/FlowFuse/flowfuse/issues/662){rel="&#x22;nofollow&#x22;"}
We've introduced our first custom FlowFuse nodes to the palette of new projects. The Project Link nodes allow you to easily pass data between different projects within the same team.
These projects can be running in the cloud or on devices, with the communication powered by our own internal MQTT broker.
Try these out today on FlowFuse Cloud by creating a new project or updating your existing project's stack. There's more information in the [README](https://github.com/FlowFuse/nr-project-nodes/blob/main/README.md){rel="&#x22;nofollow&#x22;"} for the nodes.
For local installs of FlowFuse, the nodes are only available with an Enterprise Edition license.
:video{ariaLabel="Video showing the message being sent from one project to another using project link nodes" autoPlay="true" height="678" loop="true" muted="true" playsInline="true" preload="none" width="1864"}

[Start & Stop Flows](https://github.com/FlowFuse/flowfuse/issues/839){rel="&#x22;nofollow&#x22;"}
Node-RED 3.0 [introduced a new feature](https://nodered.org/blog/2022/07/14/version-3-0-released#editing-stopped-flows){rel="&#x22;nofollow&#x22;"} that allows you to stop your flows from processing requests while still being able to work in the editor and deploy changes. We've now enabled this feature within FlowFuse for projects running a Node-RED 3.x stack.

[Default Team](https://github.com/FlowFuse/flowfuse/issues/298){rel="&#x22;nofollow&#x22;"}
If you are a member of multiple teams you can now set your preferred default saving you from having to change teams each time you log in.

## Improvements

We've made a number of improvements to the overall experience of running FlowFuse.

- Devices now communicate to the Forge application over MQTT instead of polling [#754](https://github.com/FlowFuse/flowfuse/issues/754){rel="&#x22;nofollow&#x22;"}. You'll need to update your Device Agent to the latest version to take advantage of this.
- The table views have had a major overhaul allowing you to sort and search items [#28](https://github.com/FlowFuse/forge-ui-components/issues/28){rel="&#x22;nofollow&#x22;"}
- If the application receives an error you now see a notification in the UI. [#771](https://github.com/FlowFuse/flowfuse/issues/771){rel="&#x22;nofollow&#x22;"}
- The Verification email page has been cleaned up [#718](https://github.com/FlowFuse/flowfuse/issues/718){rel="&#x22;nofollow&#x22;"}
- The initial Thank-you page has been cleaned up [#648](https://github.com/FlowFuse/flowfuse/issues/648){rel="&#x22;nofollow&#x22;"}

## Bug Fixes

We've fixed the following bugs in this release.

- [Logo Distorted in Safari](https://github.com/FlowFuse/flowfuse/issues/793){rel="&#x22;nofollow&#x22;"}:br
- [LocalFS Install doesn't check for Build Tools](https://github.com/FlowFuse/flowfuse/issues/729){rel="&#x22;nofollow&#x22;"}:br
- [Users with Expired passwords can create teams](https://github.com/FlowFuse/flowfuse/pull/842){rel="&#x22;nofollow&#x22;"}:br
- [Click-jacking Vulnerability](https://github.com/FlowFuse/flowfuse/pull/790){rel="&#x22;nofollow&#x22;"}
- [Users with can create teams without verifying email](https://github.com/FlowFuse/flowfuse/pull/824){rel="&#x22;nofollow&#x22;"}:br
- [Occasional Timeout when deploying flows](https://github.com/FlowFuse/flowforge-nr-storage/issues/17){rel="&#x22;nofollow&#x22;"}:br
- [Notification of member deletion contains internal ID](https://github.com/FlowFuse/flowfuse/issues/833){rel="&#x22;nofollow&#x22;"}:br
- [Pressing Enter in the Team Delete modal triggers cancel](https://github.com/FlowFuse/flowfuse/issues/334){rel="&#x22;nofollow&#x22;"}:br
- [Node-RED Isn't ready when Forge app says it is running (Docker)](https://github.com/FlowFuse/flowfuse/issues/751){rel="&#x22;nofollow&#x22;"}:br

## Contributors

We'd like the thank the following for their contributions to this release:

- [HaroldPetersInskipp](https://github.com/HaroldPetersInskipp){rel="&#x22;nofollow&#x22;"} helped [updating our documentation](https://github.com/FlowFuse/flowfuse/pull/812){rel="&#x22;nofollow&#x22;"}
- [Steveorevo](https://github.com/Steveorevo){rel="&#x22;nofollow&#x22;"} also [updated our documentation](https://github.com/FlowFuse/flowfuse/pull/818){rel="&#x22;nofollow&#x22;"}

As an open-source project, we welcome the community involvement in what we're building. If you're interested in contributing, checkout our [guide in the docs](https://flowfuse.com/docs/contribute/).

### Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 0.8 and the stacks updated. Upgrade your project stacks to the latest version and start using the Project Link nodes now.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading FlowFuse on a local server](https://flowfuse.com/docs/upgrade/#upgrading-flowfuse).

### Getting help

If you hit any problems with the platform, or have questions to ask, please do
raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That also includes if you have any feedback or feature requests.

Customers of FlowFuse Cloud can raise a ticket by emailing <support@flowfuse.com>

We also have a `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.


# Community News August 2022

Welcome to the FlowFuse newsletter, a regular roundup of what’s happening with both FlowFuse and the wider Node-RED community.

If you've got something that you'd like us to share please email <contact@flowfuse.com>.

[**FlowFuse 0.9**](https://flowfuse.com/blog/2022/09/flowforge-09-released/):br
Version 0.9 was released on 1st September. Our latest release includes some great new features, quality of life improvements and bug fixes. Notable additions included the ability to [suspend your projects](https://github.com/FlowFuse/flowfuse/pull/893){rel="&#x22;nofollow&#x22;"}, [login with your email](https://github.com/FlowFuse/flowfuse/pull/856){rel="&#x22;nofollow&#x22;"} and [define custom paths for your dashboards](https://github.com/FlowFuse/flowfuse/issues/774){rel="&#x22;nofollow&#x22;"}.

If you’d like to learn more about what else was included in 0.9 you can do so on our [blog post](https://flowfuse.com/blog/2022/09/flowforge-09-released/), on our [GitHub release page](https://github.com/FlowFuse/flowfuse/releases/tag/v0.9.0){rel="&#x22;nofollow&#x22;"} and on our [Youtube channel](https://www.youtube.com/watch?v=d23Pmyc0k7I){rel="&#x22;nofollow&#x22;"}. We’d also love for more of you to get involved in the development of FlowFuse, [contributions to the code](https://github.com/FlowFuse/flowfuse/blob/main/CONTRIBUTING.md){rel="&#x22;nofollow&#x22;"} and [bug reports](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"} are really appreciated.

[**Node-RED Con 2022**](https://nrcon.nodered.org/){rel="&#x22;nofollow&#x22;"}:br
We are happy to again be involved in Node-RED con. The event is being held online on 7th October, with content for both English and Japanese speakers. You can find out more on the [Node-RED Con website](https://nrcon.nodered.org/){rel="&#x22;nofollow&#x22;"}.

[**FlowFuse Team News**](https://flowfuse.com/about/):br
We’d like to welcome Rob Marcer to the FlowFuse team. Rob has joined as our Developer Educator, he's going to work to help you get the best value from FlowFuse by developing our documentation and community support.

We are also recruiting for [NodeJS Developers](https://boards.greenhouse.io/flowfuse/jobs/4463977004){rel="&#x22;nofollow&#x22;"}, if you’re interested in joining our team please [apply here](https://boards.greenhouse.io/flowfuse/jobs/4463977004#app){rel="&#x22;nofollow&#x22;"}.

[**Official Node-RED Docker Image Passes Milestone**](https://twitter.com/Docker/status/1559919666721693699?t=QBzGGzY2kJ12Z5aoi1QPTA){rel="&#x22;nofollow&#x22;"}:br
Docker has [announced](https://twitter.com/Docker/status/1559919666721693699?t=QBzGGzY2kJ12Z5aoi1QPTA){rel="&#x22;nofollow&#x22;"} that the Node-RED Docker image has now been downloaded over 100 million times. They have also created a [guide to using Node-RED](https://www.docker.com/blog/build-retail-store-items-detection-system-no-code-ai/?utm_campaign=2022-08-17-brnd-nocode&utm_medium=social&utm_source=twitter){rel="&#x22;nofollow&#x22;"} to Build and Deploy a Retail Store Items Detection System Using No-Code AI Vision at the Edge. We think it’s worth a read.

[**Simulating IOT Projects in Your Browser**](https://wokwi.com/){rel="&#x22;nofollow&#x22;"}:br
While not directly related to FlowFuse we’ve enjoyed wasting a little too much time looking at the simulated IOT projects on [Wokwi](https://wokwi.com/){rel="&#x22;nofollow&#x22;"}. The [Simon Game with Score](https://wokwi.com/projects/328451800839488084){rel="&#x22;nofollow&#x22;"} project is a little too addictive.

[**Try FlowFuse for Free**](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}:br
As a thank you for reading our newsletters we’d like to offer you a free, small project for one month on FlowFuse when you create a new team. To get this discount please use the code RELEASE09 when on the payment page after creating a new team.


# FlowFuse 0.10 released

Secure your HTTP endpoints, create read-only users in your teams and use our static IP address for outbound traffic

Keep reading for the details of what's in this release or you can watch our 1 minute roundup video of the new release above.

We're pleased to announce version 0.10 is now available. The next release of the FlowFuse application containing new features, a number of improvements, and bug fixes. Keep reading for a promotion code to get your first month free on FlowFuse Cloud.

## Features

[Secure HTTP Endpoints](https://github.com/FlowFuse/flowfuse/issues/578){rel="&#x22;nofollow&#x22;"}
We've added the ability for you to secure your HTTP endpoints. You can now control who can access Dashboards or API endpoints you create in FlowFuse.

[Read-only Users](https://github.com/FlowFuse/flowfuse/issues/657){rel="&#x22;nofollow&#x22;"}
We've added a new user role for Read-only access. This will allow users to login to your FlowFuse project and view the Node-RED flows without them being able to edit anything.

[Static Outbound IP Addresses](https://flowfuse.com/docs/cloud/introduction/#ip-addresses)
We've updated FlowFuse Cloud so that all outbound traffic from your projects now comes from a single IP address. When trying to access a remote resource such as a database it is often a requirement for the IP address the traffic comes from to be fixed.

## Improvements

We've made a number of improvements to the overall experience of running FlowFuse.

- Allow both key and component in a ff-data-table column definition [#43](https://github.com/FlowFuse/forge-ui-components/issues/43){rel="&#x22;nofollow&#x22;"}
- Default Stack and Templates [#989](https://github.com/FlowFuse/flowfuse/issues/989){rel="&#x22;nofollow&#x22;"}
- Provide platform containers and base stack container for administrators [#917](https://github.com/FlowFuse/flowfuse/issues/917){rel="&#x22;nofollow&#x22;"}

## Bug Fixes

We've fixed the following bugs in this release.

- [Provide platform containers and base stack container for administrators](https://github.com/FlowFuse/flowfuse/issues/917){rel="&#x22;nofollow&#x22;"}
- [User names can be same (but different case)](https://github.com/FlowFuse/flowfuse/issues/983){rel="&#x22;nofollow&#x22;"}
- [User list not refreshing after changing user details](https://github.com/FlowFuse/flowfuse/issues/463){rel="&#x22;nofollow&#x22;"}
- [Navigating directly to a device page gets the wrong team selected](https://github.com/FlowFuse/flowfuse/issues/986){rel="&#x22;nofollow&#x22;"}
- [Node-RED Isn't ready when FlowFuse app says it is running following a project restart](https://github.com/FlowFuse/flowfuse/issues/941){rel="&#x22;nofollow&#x22;"}
- [Invitations left for deleted teams](https://github.com/FlowFuse/flowfuse/issues/923){rel="&#x22;nofollow&#x22;"}
- [Following email verification link twice throws error](https://github.com/FlowFuse/flowfuse/issues/1024){rel="&#x22;nofollow&#x22;"}
- [Agent does not log stderr from the Node-RED process](https://github.com/FlowFuse/device-agent/issues/21){rel="&#x22;nofollow&#x22;"}
- [On Kubernetes project names can not start with a number](https://github.com/FlowFuse/flowfuse/issues/948){rel="&#x22;nofollow&#x22;"}
- [When creating projects stack options do not wrap](https://github.com/FlowFuse/flowfuse/issues/930){rel="&#x22;nofollow&#x22;"}
- [Save button in admin user-edit dialog doesn't close dialog](https://github.com/FlowFuse/flowfuse/issues/979){rel="&#x22;nofollow&#x22;"}
- [Setting UI doesn't allow me to update settings](https://github.com/FlowFuse/flowfuse/issues/911){rel="&#x22;nofollow&#x22;"}

## Contributors

We'd like the thank the following for their contributions to this release:

[Pezmc](https://github.com/Pezmc){rel="&#x22;nofollow&#x22;"} for their work on [Add device count and project counts by type to admin](https://github.com/FlowFuse/flowfuse/pull/949){rel="&#x22;nofollow&#x22;"}

[ArshErgon](https://github.com/ArshErgon){rel="&#x22;nofollow&#x22;"} for their work on [Update vue component name for NoVerifiedEmail.vue](https://github.com/FlowFuse/flowfuse/pull/977){rel="&#x22;nofollow&#x22;"}

As an open-source project, we welcome the community involvement in what we're building. If you're interested in contributing, checkout our [guide in the docs](https://flowfuse.com/docs/contribute/).

### Try it out

[Sign up for FlowFuse Cloud](https://app.flowfuse.com/account/create?code=RELEASE010){rel="&#x22;nofollow&#x22;"} with this link or at the checkout enter the code **RELEASE010** to get your first project free for a month.

### Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 0.10 and the stacks updated. Upgrade your project stacks to the latest version to make sure you get all the latest changes.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading FlowFuse on a local server](https://flowfuse.com/docs/upgrade/#upgrading-flowfuse).

### Getting help

If you hit any problems with the platform, or have questions to ask, please do
raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That also includes if you have any feedback or feature requests.

Customers of FlowFuse Cloud can raise a ticket by emailing <support@flowfuse.com>

We also have a `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.


# FlowFuse 0.9 released

Suspend your projects when you don't need them, login with either your username or email, and introducing Team Types

Keep reading for the details of what's in this release our you can watch our 1 minute roundup video of the new release above.

We're pleased to announce version 0.9 is now available. The next release of the FlowFuse application containing new features, a number of improvements, and bug fixes. Keep reading for a promotion code to get your first month free on FlowFuse Cloud.

## Features

[Suspend Projects](https://github.com/FlowFuse/flowfuse/issues/893){rel="&#x22;nofollow&#x22;"}
Sometimes you want to put a project to one side for a while, maybe your development has stalled or you're waiting on something external to be ready. Perhaps you don't need it to be running all the time. With the 0.9 release we've added the ability to suspend a project. Once suspended, your flows are safely stored in the platform database, but Node-RED isn't running and the project doesn't consume any resources. In FlowFuse Cloud we do not charge you for suspended projects - you only pay when the project is running.
Your project will be there ready to start back up when you need it with just one click.
Remember that any context data or anything written to the filesystem will not persist through a restart or a suspend of a project.

Alongside this change, we've removed the option to 'stop' a project. That option would only stop Node-RED, but the underlying container would still be running, consuming resources. With Node-RED 3.0 adding the ability to stop the flows, but still be able to edit them, that provides a much better user experience.
You can still restart the Node-RED process from the Forge app as before for example when you have updated a package in your flows.

[Team Types](https://github.com/FlowFuse/flowfuse/issues/733){rel="&#x22;nofollow&#x22;"}
We've introduced another concept into the platform with this release. Team Types will allow us to offer more advanced features to teams on FlowFuse Cloud. You won't see much difference in this release but it allows us to build on in future releases.

[PostHog Analytics](https://github.com/FlowFuse/flowfuse/issues/695){rel="&#x22;nofollow&#x22;"}
We've changed the analytics tooling integrated into the platform. With this release, we've deprecated the use of Plausible Analytics as it didn't quite provide the sort of insight we wanted. We now integrate with [PostHog](https://posthog.com/){rel="&#x22;nofollow&#x22;"}. They share our ethos and approach to open source and self hosting - something you can take advantage of if you're running your own FlowFuse platform.
For FlowFuse Cloud, the data is sent to our PostHog account so we can better understand how the platform is being used. If you're running your own instance, the information is only captured if you configure it with your own PostHog instance details - it does not send any data back to us.

[Login with email](https://github.com/FlowFuse/flowfuse/issues/856){rel="&#x22;nofollow&#x22;"}
A common problem that we've seen from users is trying to login with their email address instead of their username. As of 0.9 you can now enter either at the login screen.

[Custom Dashboard Path](https://github.com/FlowFuse/flowfuse/issues/774){rel="&#x22;nofollow&#x22;"}
If you are using the Node-RED Dashboard set of nodes, you can now change the path where the dashboard will be served from. The default is still `/ui` but you can now move that onto `/` or anything else. This is helpful when migrating existing projects over to FlowFuse.

## Improvements

We've made a number of improvements to the overall experience of running FlowFuse.

- Improvements to the FlowFuse Theme [#883](https://github.com/FlowFuse/flowfuse/pull/883){rel="&#x22;nofollow&#x22;"}.
- Upper-case characters in Project Names [#546](https://github.com/FlowFuse/flowfuse/issues/546){rel="&#x22;nofollow&#x22;"}
- Password reset requests are logged[#773](https://github.com/FlowFuse/flowfuse/issues/773){rel="&#x22;nofollow&#x22;"}
- Admin can manually verify users email [#902](https://github.com/FlowFuse/flowfuse/issues/692){rel="&#x22;nofollow&#x22;"}

## Bug Fixes

We've fixed the following bugs in this release.

- [Cannot edit template settings](https://github.com/FlowFuse/flowfuse/issues/875){rel="&#x22;nofollow&#x22;"}:br
- [Project Link Nodes Appear in CE Install](https://github.com/FlowFuse/nr-project-nodes/issues/10){rel="&#x22;nofollow&#x22;"}
- [Project Link Nodes MQTT Connection](https://github.com/FlowFuse/nr-project-nodes/issues/14){rel="&#x22;nofollow&#x22;"}
- [Theme shows white characters on white background](https://github.com/FlowFuse/flowforge-nr-theme/issues/19){rel="&#x22;nofollow&#x22;"}
- [Changing Project on device doesn't remove old modules](https://github.com/FlowFuse/device-agent/issues/27){rel="&#x22;nofollow&#x22;"}
- [Device Agent and Node-RED use different time in logs](https://github.com/FlowFuse/device-agent/issues/30){rel="&#x22;nofollow&#x22;"}

## Contributors

We'd like the thank the following for their contributions to this release:

[Bonantech](https://github.com/bonanitech){rel="&#x22;nofollow&#x22;"} for his work [cleaning up the theme CSS](https://github.com/FlowFuse/flowforge-nr-theme/commit/30e21a3777dc3438ef206157ee9110728011f59c){rel="&#x22;nofollow&#x22;"}

As an open-source project, we welcome the community involvement in what we're building. If you're interested in contributing, checkout our [guide in the docs](https://flowforge.com/docs/contribute/){rel="&#x22;nofollow&#x22;"}.

### Try it out

[Sign up for FlowFuse Cloud](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and at the checkout enter the code **RELEASE09** to get your first project free for a month.

### Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 0.9 and the stacks updated. Upgrade your project stacks to the latest version and start using the Project Link nodes now.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading FlowFuse on a local server](https://flowfuse.com/docs/upgrade/#upgrading-flowfuse).

### Getting help

If you hit any problems with the platform, or have questions to ask, please do
raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That also includes if you have any feedback or feature requests.

Customers of FlowFuse Cloud can raise a ticket by emailing <support@flowfuse.com>

We also have a `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.


# Static Outbound IP Addresses

On Friday last week we updated FlowFuse Cloud to use a static IP address for outbound traffic. This will allow you to predict which IP address your traffic will come from for example when traversing a firewall or accessing a remote database.

You will need to manually suspend then start each of your projects (a restart will not move your projects to the fixed IP address). Once that action is completed all outbound connections will come from one of our static IP address.

Any inbound traffic should still use the hostname assigned to each of your projects, you cannot use our IP address to route http traffic to your projects.

You can view our IP address in the [Docs](https://flowfuse.com/docs/cloud/introduction/#ip-addresses) section of our website.

If you’d like to stay up to date with our latest releases you can do so on [our blog](https://flowfuse.com/blog).


# Community News September 2022

Welcome to the FlowFuse newsletter, a regular roundup of what’s happening with both FlowFuse and the wider Node-RED community.

If you've got something that you'd like us to share please email <contact@flowfuse.com>.

[**FlowFuse 0.10**](https://flowfuse.com/blog/2022/09/flowforge-010-released/)
Version 0.10 was released on 30th September. Our latest release includes some great new features, quality of life improvements and bug fixes. Notable additions included the ability to [Secure your HTTP endpoints](https://github.com/FlowFuse/flowfuse/pull/893){rel="&#x22;nofollow&#x22;"}, [Add read-only users to your projects](https://github.com/FlowFuse/flowfuse/issues/657){rel="&#x22;nofollow&#x22;"} and [use our static IP address for outbound connections](https://flowfuse.com/docs/cloud/introduction/#ip-addresses)

If you’d like to learn more about what else was included in 0.10 you can do so on our [blog post](https://flowfuse.com/blog/2022/09/flowforge-010-released/), on our [GitHub release page](https://github.com/FlowFuse/flowfuse/releases/tag/v0.10.0){rel="&#x22;nofollow&#x22;"} and on our [Youtube channel](https://youtube.com/watch?v=mjR1iiEFiBg){rel="&#x22;nofollow&#x22;"}. We’d also love for more of you to get involved in the development of FlowFuse, [contributions to the code](https://github.com/FlowFuse/flowfuse/blob/main/CONTRIBUTING.md){rel="&#x22;nofollow&#x22;"} and [bug reports](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"} are really appreciated.

[**Node-RED Con 2022**](https://nrcon.nodered.org/){rel="&#x22;nofollow&#x22;"}:br
We are happy to again be involved in Node-RED con. The event is being held online on 7th October, with content for both English and Japanese speakers including our colleagues Nick O'Leary and Sam Machin. You can find out more on the [Node-RED Con website](https://nrcon.nodered.org/){rel="&#x22;nofollow&#x22;"}.

[**FlowFuse Team News**](https://flowforge.com/team/){rel="&#x22;nofollow&#x22;"}:br
We are currently recruiting [NodeJS Developers](https://boards.greenhouse.io/flowfuse/jobs/4463977004){rel="&#x22;nofollow&#x22;"}, if you’re interested in joining our team please [apply here](https://boards.greenhouse.io/flowfuse/jobs/4463977004#app){rel="&#x22;nofollow&#x22;"}.

We are also looking for a [PeopleOps Manager](https://boards.greenhouse.io/flowfuse/jobs/4687876004){rel="&#x22;nofollow&#x22;"} to help us grow our team. You can [apply here](https://boards.greenhouse.io/flowfuse/jobs/4687876004#app){rel="&#x22;nofollow&#x22;"} for that position.

[**Forest Fire Alerts Using ML, IOT and Node-RED**](https://hackster.io/user102774/fight-fire-wild-fire-prediction-using-tinyml-df7572){rel="&#x22;nofollow&#x22;"}:br
This fascinating project came up a few days ago and we wanted to share it with you all. The concept is to use a mesh network of IoT devices to monitor various indicators of potential and current wildfires and report data back to the relevant authorities. The system will use ML to predict wildfire risk levels and hopefully send warnings before a fire actually starts. The two developers [Muhammed](https://linkedin.com/in/zainmfd/){rel="&#x22;nofollow&#x22;"} and [Salman](https://linkedin.com/in/salmanfarisvp/){rel="&#x22;nofollow&#x22;"} are planning to use Node-RED to manage the reporting of fires to the authorities.

[**Try FlowFuse for Free**](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}:br
As a thank you for reading our newsletters we’d like to offer you a free, small project for one month on FlowFuse when you create a new team. To get this discount please follow [this link](https://app.flowfuse.com/account/create?code=RELEASE010){rel="&#x22;nofollow&#x22;"} or use the code RELEASE010 when on the payment page after creating a new team.


# Scheduled maintenance: Database encryption October 2022

As part of an on-going security [review](https://flowfuse.com/platform/security/#data-at-rest) of the FlowFuse Cloud offering we discovered that the backend database was not using encrypted storage. In keeping with industry best practices we plan to migrate the database to a new instance using encrypted at rest storage.

## Impact

Customers' Node-RED instances will remain running, though any features that depend on FlowFuse will not operate as expected during the migration. This includes user sessions, project and team management, as well as the project nodes for inter-project communication.

Self-hosted installations are unaffected by this change.

## When

The migration will be on 26 October 2022 at 22:00 UTC and is expected to take under 2 hours. The platform will be available as soon as the migration is complete.

We will post updates during the migration period to our Twitter account [@FlowFuseInc](https://twitter.com/flowforgeinc){rel="&#x22;nofollow&#x22;"}.


# Install FlowFuse Docker on Google Cloud

As part of our preparations for FlowFuse 1.0 we have been testing various real world scenarios to see where we can add to our documentation and where we might be able to improve our releases to make the install process easier for users. As a benefit of that testing we have been able to hone these installation processes and we wanted to share one of those with you today.

In this first of three articles, we are going to run through the process for installing FlowFuse on Google Cloud Platform (GCP) within a virtual machine (VM) using Docker.

We have set ourselves the goal of delivering a production environment. We want this installation benefit from:

- Email alerts (emails to users when they are added to teams etc)
- HTTPS access to the install
- FlowFuse [Device](https://flowfuse.com/docs/user/concepts/#device) deployment via the included MQTT server that comes in our Docker build

We will follow up with a second article covering the process of getting HTTPS running then we will close out the series by covering how to use key features of FlowFuse including [Devices](https://flowfuse.com/docs/user/concepts/#device).

# Prerequisites

- A domain name - We've registered flowforge-demo.com to demonstrate these steps
- A DNS provider - Our Domain registrar provides a basic DNS service for free
- A GCP account - Google will often give you free service credits on sign up so setting up FlowFuse on GCP should not cost you anything for at least a few weeks
- An email provider which will allow SMTP connections to send email - To manage users on your FlowFuse platform you will need to be able to send emails to them. We have used a Google Workspace account for this purpose

# GCP VM Creation

Create a GCP account, once logged in navigate to Compute Engine then VM Instances. Select Create Instance you should now be [here](https://console.cloud.google.com/compute/instancesAdd?project){rel="&#x22;nofollow&#x22;"}.

Give your instance a name, select a Region and Zone. I have found that the default machine configuration works fine but depending on your project you may wish to change the resources.

!["Screenshot showing the interface for creating GCP VM"](https://flowfuse.com/blog/2022/10/images/1.png "Screenshot showing the interface for creating GCP VM")

You now need to allow access to your FlowFuse installation from the internet. In the Firewall section tick Allow HTTP traffic and Allow HTTPS traffic.

!["Screenshot showing the firewall section in the interface for creating a GCP VM"](https://flowfuse.com/blog/2022/10/images/2.png "Screenshot showing the firewall section in the interface for creating a GCP VM")

Next up, assign a static IP address to the VM. Click Advanced options, then Networking. Now scroll down until you see Network interfaces and click on default to expand that section. In External IPv4 address select Create IP Address, give it a name than press Reserve.

!["Screenshot showing the network section in the interface for creating a GCP VM"](https://flowfuse.com/blog/2022/10/images/3.png "Screenshot showing the network section in the interface for creating a GCP VM")

Once you have reserved your IP it will be shown in the External IPv4 address field, write it down as we will need it later to create the DNS records. Our IP address was 34.125.156.130.

!["Screenshot showing your reserved IP in the External IPv4 address field"](https://flowfuse.com/blog/2022/10/images/4.png "Screenshot showing your reserved IP in the External IPv4 address field")

You are now ready to create and boot your VM, scroll to the bottom of the page and press Create. It can take a minute or two for the VM to be ready to use.

# DNS Set Up

So that you can run FlowFuse on your newly created GCP VM you will need to set up 2 DNS records. These records are slightly different to what is suggested in the FlowFuse install docs. We were keen to be able to run other services on this domain so we set up the following records.

![Screenshot showing interface for setting DNS](https://flowfuse.com/blog/2022/10/images/5.png "Screenshot showing interface for setting DNS")

DNS changes need to propagate, and depending on your DNS provider, ISP, and other factors, this can take anywhere between a few seconds to 4 hours. Our’s were in place very quickly. To validate the DNS records you can use `dig` on either a Mac or Linux.

![Screenshot showing output of the dig command](https://flowfuse.com/blog/2022/10/images/6.png "Screenshot showing output of the dig command")

The DNS records are set to the IP record we noted down earlier, so we're good to continue.

# FlowFuse Docker Installation

The next step is to install Docker on our GCP VM. If you return to GCP you should see that your VM is now up and running, you can now click on SSH to connect to your VM. This will open up a browser based SSH session to your VM.

![Screenshot showing access to SSH in GCP](https://flowfuse.com/blog/2022/10/images/7.png "Screenshot showing access to SSH in GCP")

Once you have a Secure Shell (SSH) session open, the first step is to install Docker using the following commands.

`sudo apt-get update`

```text
sudo apt-get install \
   ca-certificates \
   curl \
   gnupg \
   lsb-release
```

`sudo mkdir -p /etc/apt/keyrings`

`curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg`

```text
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
```

`sudo apt-get update`

`sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin`

You can read a lot more detail about what each these commands actually do [here](https://docs.docker.com/engine/install/debian/){rel="&#x22;nofollow&#x22;"}.

# Download FlowFuse’s latest Docker build

The next step is to get the codebase for FlowFuse onto your VM, to do so you will need to run the following commands. Please note that we are working with our 0.10.0 build, you will need to update the version number in the commands below if you are working with a newer build.

Use curl to download the files we need.

`sudo curl -L https://github.com/FlowFuse/docker-compose/archive/refs/tags/v0.10.1.tar.gz -o v0.10.1.tar.gz`

Make the directory where we will store FlowFuse.

`sudo mkdir /opt/flowforge`

Uncompress FlowFuse and save it to the directory.

`sudo tar zxf v0.10.1.tar.gz --directory /opt/flowforge`

You should now have all the code you need for FlowFuse in the directory `/opt/flowforge/docker-compose-0.10.1`, it should look something like this.

!["Screenshot showing directory listing for FlowFuse"](https://flowfuse.com/blog/2022/10/images/8.png "Screenshot showing directory listing for FlowFuse")

# Configure FlowFuse

We can now configure FlowFuse on your VM. We are going to need to edit two files. Firstly we need to switch into the directory where we just placed FlowFuse.

`cd /opt/flowforge/docker-compose-0.10.1`

Then we need to edit the flowforge.yml file, we're using Nano to do that.

`sudo nano /opt/flowforge/docker-compose-0.10.1/etc/flowforge.yml`

At the top of the file you need to update the domain and base\_url to match your domain

!["Screenshot showing domain configuration in flowforge.yml"](https://flowfuse.com/blog/2022/10/images/9.png "Screenshot showing domain configuration in flowforge.yml")

Next we will need to edit the Email Configuration section to match your SMTP provider. Set enabled to true then add in the details provider by your email provider. For example in this case I am using our Google Workspace account.

!["Screenshot showing email configuration in flowforge.yml"](https://flowfuse.com/blog/2022/10/images/10.png "Screenshot showing email configuration in flowforge.yml")

Finally, you need to update the `public_url` for your mqtt broker to match your DNS record.

!["Screenshot showing MQTT configuration in flowforge.yml"](https://flowfuse.com/blog/2022/10/images/11.png "Screenshot showing MQTT configuration in flowforge.yml")

You can now save and close that file, in Nano you can do that by pressing ‘control x’ then ‘y’ then the Return key.

Now we need to edit the `docker-compose.yml` file. We will use Nano again to do that.

`sudo nano /opt/flowforge/docker-compose-0.10.1/docker-compose.yml`

We need to edit the file to add in to the domain as follows.

!["Screenshot showing virtual hosts configuration in docker-compose.yml"](https://flowfuse.com/blog/2022/10/images/12.png "Screenshot showing virtual hosts configuration in docker-compose.yml")

Save and exit from that file, in Nano you can do that by pressing ‘control x’ then ‘y’ then the Return key.

# Start FlowFuse

We are now ready to start up FlowFuse for the first time, to do so we will use the following command.

`sudo docker compose -p flowforge up -d`

The build process will take a few minutes, once it’s completed let’s make sure all the docker containers are running.

`sudo docker ps`

![Docker PS output](https://flowfuse.com/blog/2022/10/images/13.png)

You should see 4 running Docker containers.

If everything went well you should now be able to access your FlowFuse server via the DNS record you created.

![FF Login page](https://flowfuse.com/blog/2022/10/images/14.png)

Nice, you now have a working instance of FlowFuse running on GCP but remember that all traffic is currently running on HTTP so we still have some work to do.

In the next article we will cover how to add HTTPS support to this FlowFuse installation.


# FlowFuse 1.0 released

Predefined environment variables for your Instances and Devices, manage your Project's modules and import your existing flows (and credentials) into your FlowFuse [Projects](https://flowfuse.com/docs/user/concepts/#instance).

We're pleased to announce version 1.0 FlowFuse is now available. Keep reading for a promotion code to get your first month free on FlowFuse. Version 1.0 represents our vision of the base set of features needed for you to get great value from using FlowFuse in a production environment. That's not to say we are done, we will continue to add features, improve our interfaces and fix bugs with the same enthusiasm as we've worked towards 1.0. We'd like to hear your feedback on what we will be including in [1.1 and beyond](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"}.

## Features

[Standard Environment Variables set for both Projects and Devices](https://github.com/FlowFuse/flowfuse/issues/841){rel="&#x22;nofollow&#x22;"}

Projects now get a set of predefined environment variables that can be used by their flows. These give your flows access to the projects unique id and name. When the flows are deployed to [devices](https://flowfuse.com/docs/user/concepts/#device), they also get the device's id and name. That makes is easier to deploy flows across multiple devices and have each able to identify itself.

[Add additional node modules to your projects](https://github.com/FlowFuse/flowfuse/issues/405){rel="&#x22;nofollow&#x22;"}
This feature allows you to pre-define additional Node-RED nodes and node modules you may want to be installed in your FlowFuse project, making it easier to manage.

[Import existing projects into FlowFuse](https://github.com/FlowFuse/flowfuse/issues/835){rel="&#x22;nofollow&#x22;"}

You can now import your existing flow and credentials files straight into your FlowFuse project - making it really easy to move your existing projects into the platform.

## Improvements

We've made a number of improvements to the overall experience of running FlowFuse.

- Editable Stack labels [#915](https://github.com/FlowFuse/flowfuse/issues/915){rel="&#x22;nofollow&#x22;"}
- Check for suitable version of Node on Devices [#37](https://github.com/FlowFuse/device-agent/issues/37){rel="&#x22;nofollow&#x22;"}
- Realtime Project status details in Project overview [#990](https://github.com/FlowFuse/flowfuse/issues/990){rel="&#x22;nofollow&#x22;"}
- Improve Template creation & Edit Project Settings UX [#1041](https://github.com/FlowFuse/flowfuse/issues/1041){rel="&#x22;nofollow&#x22;"}

## Bug Fixes

We've fixed the following bugs in this release.

- [Pressing return in search box reloads page](https://github.com/FlowFuse/flowfuse/issues/1143){rel="&#x22;nofollow&#x22;"}
- [Vue Router Warn](https://github.com/FlowFuse/flowfuse/issues/1126){rel="&#x22;nofollow&#x22;"}
- [Kebab menu in Settings breaks](https://github.com/FlowFuse/forge-ui-components/issues/58){rel="&#x22;nofollow&#x22;"}
- [flowforge-nr-launcher missing try/catch on http request](https://github.com/FlowFuse/flowfuse/issues/1096){rel="&#x22;nofollow&#x22;"}
- [Invite with + in email address is incorrectly sanitised](https://github.com/FlowFuse/flowfuse/issues/1145){rel="&#x22;nofollow&#x22;"}
- [Table does not sort correctly when empty fields are present](https://github.com/FlowFuse/forge-ui-components/issues/59){rel="&#x22;nofollow&#x22;"}
- [4xx Errors not shown in App](https://github.com/FlowFuse/flowfuse/issues/929){rel="&#x22;nofollow&#x22;"}
- [Inconsistent errors returned from the API](https://github.com/FlowFuse/flowfuse/issues/1076){rel="&#x22;nofollow&#x22;"}
- [Module install not working on windows](https://github.com/FlowFuse/flowforge-nr-launcher/issues/77){rel="&#x22;nofollow&#x22;"}
- [Avatar lettering is mis-allinged when only rendering 1 character](https://github.com/FlowFuse/flowfuse/issues/1038){rel="&#x22;nofollow&#x22;"}
- [it.only is not prohibited](https://github.com/FlowFuse/flowfuse/issues/968){rel="&#x22;nofollow&#x22;"}
- [No feedback when an API error occurs editing user](https://github.com/FlowFuse/flowfuse/issues/966){rel="&#x22;nofollow&#x22;"}
- [Start action is available on a running project](https://github.com/FlowFuse/flowfuse/issues/1040){rel="&#x22;nofollow&#x22;"}

## Contributors

We'd like the thank the following for their contributions to this release:

[Jozefik](https://github.com/Jozefik){rel="&#x22;nofollow&#x22;"} for their work on [Adding limits to admin panel](https://github.com/FlowFuse/flowfuse/pull/1082){rel="&#x22;nofollow&#x22;"}.

As an open-source project, we welcome community involvement in what we're building. If you're interested in contributing, checkout our [guide in the docs](https://flowfuse.com/docs/contribute/).

### Try it out

[Sign up for FlowFuse-Managed Premium](https://app.flowfuse.com/account/create?code=RELEASE1){rel="&#x22;nofollow&#x22;"} with this link or at the checkout enter the code **RELEASE1** to get your first project free for a month. As an open source project you can also use [FlowFuse-Community](https://flowfuse.com/docs/install/) for free, forever.

### Upgrading FlowFuse

Our managed \[FlowFuse]\({{ site.appURL }}) is already running 1.0. Upgrade your project Stacks to the latest version to make sure you get all the latest changes.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading FlowFuse on a local server](https://flowfuse.com/docs/upgrade/#upgrading-flowfuse).

### Getting help

If you hit any problems with the platform, or have questions to ask, please raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That also includes if you have any feedback or feature requests.

Customers of FlowFuse Cloud can raise a ticket by emailing <support@flowfuse.com>

We also have a `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.


# FlowFuse raises $7.25M Seed Round to bring Node-RED to the Enterprise

Since the [launch of FlowFuse](https://flowfuse.com/blog/2021/04/first-deploy/) in April 2021 our goal has been to
build a low-code, enterprise-ready development platform based on Node-RED. We
wanted to make it easier for enterprises to adopt, integrate, and scale Node-RED
into their existing environments. We published our [first version](https://flowfuse.com/blog/2022/01/flowforge-01-released/)
at the start of this year and have continued the journey to the
[launch of FlowFuse v1.0](https://flowfuse.com/blog/2022/10/flowforge-1-released/) just last week. Each of these releases
has moved us towards our goal of creating a platform for integrating the
IT and OT for all organizations, built around an open core.

### FlowFuse is Node-RED for the enterprise

Node-RED is an incredible tool that has allowed many organizations to quickly
and easily integrate both their IT and OT. The sheer range and variety of
solutions created with Node-RED today go far beyond what we imagined. But we’ve
also seen the challenges faced by companies wanting to take their Node-RED
solutions into production and beyond.

This is where FlowFuse comes in. It addresses those challenges by adding
security, collaboration and deployment capabilities.

### Our $7.25M Seed Round

Today, we’re super excited to announce a $7.25M seed round led by Cota Capital,
joined by Westwave Capital, Uncorrelated Ventures, and Open Core Ventures. This
brings a huge amount of extensive knowledge and experience in IoT, open source,
enterprise-ready software solutions.

This investment will enable us to continue growing the team and platform to
realize our vision of FlowFuse being the best way to achieve enterprise-ready
Node-RED. It will enable us to invest back into the core Node-RED project to
further its development. One of our core company principles is around Open
Source Stewardship - the success of FlowFuse relies on a strong and successful
Node-RED community.

We’ll be bringing more collaboration features to the FlowFuse platform to
enable true collaborative, team-based working. We’ll expand our
[Devices offering](https://flowfuse.com/docs/user/concepts/#device) to make it
far easier to run Node-RED wherever it suits your use-case, from data center to
remote edge locations.

Above all, we’ll be building a company that is open, sustainable, and fun to
work at. We already have some job openings available - check out our
\[jobs board]\({{ site.jobBoard }}) if you’re interested in joining our
team.

If you’re interested in learning more about what we’re doing, or have any
questions, please do [get in touch](https://flowfuse.com/contact-us/)!


# Community News October 2022

Welcome to the FlowFuse newsletter for October 2022, a monthly roundup of what’s happening with both FlowFuse and the wider Node-RED community.

If you've got something that you'd like us to share please email <contact@flowfuse.com>.

[**FlowFuse 1.0 Released**](https://flowfuse.com/blog/2022/10/flowforge-1-released/):br
Version 1.0 was released on 27th October. Our latest release represents our vision of the base set of features needed for you to get great value from using FlowFuse in a production environment. That's not to say we are done, we will continue to add features, improve our interfaces and fix bugs with the same enthusiasm as we've worked towards 1.0. We'd like to hear your feedback on what we will be including in [1.1 and beyond](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"}.

If you’d like to learn more about what else was included in 1.0 you can do so on our [blog post](https://flowfuse.com/blog/2022/10/flowforge-1-released), on our [GitHub release page](https://github.com/FlowFuse/flowfuse/releases/tag/v1.0.0){rel="&#x22;nofollow&#x22;"} and on our [Youtube channel](https://www.youtube.com/watch?v=5TLT7CQR7iI){rel="&#x22;nofollow&#x22;"}. We’d also love for more of you to get involved in the development of FlowFuse, [contributions to the code](https://github.com/FlowFuse/flowfuse/blob/main/CONTRIBUTING.md){rel="&#x22;nofollow&#x22;"} and [bug reports](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"} are really appreciated.

[**Node-RED Nears 3.1 Release**](https://github.com/node-red/node-red/milestone/19){rel="&#x22;nofollow&#x22;"}
The next release of Node-RED has some great new features including support for [locking flows in the editor](https://github.com/node-red/node-red/pull/3938){rel="&#x22;nofollow&#x22;"} and [improving the user experience around hiding flows](https://github.com/node-red/node-red/pull/3930){rel="&#x22;nofollow&#x22;"}. We'd expect the first 3.1 beta to be available in November with a full release following shortly afterwards.

\[\*\*FlowFuse raises [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[7.25]{.mord}[M]{.mord.mathnormal style="margin-right:0.109em;"}[t]{.mord.mathnormal}[o]{.mord.mathnormal}[b]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[N]{.mord.mathnormal style="margin-right:0.109em;"}[o]{.mord.mathnormal}[d]{.mord.mathnormal}[e]{.mord.mathnormal}[]{.mspace style="margin-right:0.2222em;"}[−]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[R]{.mord.mathnormal style="margin-right:0.0077em;"}[E]{.mord.mathnormal style="margin-right:0.0576em;"}[D]{.mord.mathnormal style="margin-right:0.0278em;"}[t]{.mord.mathnormal}[o]{.mord.mathnormal}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[e]{.mord.mathnormal}[E]{.mord.mathnormal style="margin-right:0.0576em;"}[n]{.mord.mathnormal}[t]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[p]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[i]{.mord.mathnormal}[se]{.mord.mathnormal}[]{.mspace style="margin-right:0.2222em;"}[∗]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:1em;vertical-align:-0.25em;"}[∗]{.mord}[]]{.mclose}[(]{.mopen}[/]{.mord}[b]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[o]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[/2022/10/]{.mord}[see]{.mord.mathnormal}[d]{.mord.mathnormal}[]{.mspace style="margin-right:0.2222em;"}[−]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:0.7778em;vertical-align:-0.0833em;"}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[u]{.mord.mathnormal}[n]{.mord.mathnormal}[d]{.mord.mathnormal}[]{.mspace style="margin-right:0.2222em;"}[−]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[b]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[]{.mspace style="margin-right:0.2222em;"}[−]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:0.7778em;vertical-align:-0.0833em;"}[n]{.mord.mathnormal}[o]{.mord.mathnormal}[d]{.mord.mathnormal}[e]{.mord.mathnormal}[]{.mspace style="margin-right:0.2222em;"}[−]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:0.7778em;vertical-align:-0.0833em;"}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[]{.mspace style="margin-right:0.2222em;"}[−]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:0.6984em;vertical-align:-0.0833em;"}[t]{.mord.mathnormal}[o]{.mord.mathnormal}[]{.mspace style="margin-right:0.2222em;"}[−]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:1em;vertical-align:-0.25em;"}[e]{.mord.mathnormal}[n]{.mord.mathnormal}[t]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[p]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[i]{.mord.mathnormal}[se]{.mord.mathnormal}[/]{.mord}[)]{.mclose}[E]{.mord.mathnormal style="margin-right:0.0576em;"}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[i]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[t]{.mord.mathnormal}[hi]{.mord.mathnormal}[s]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[ee]{.mord.mathnormal}[k]{.mord.mathnormal style="margin-right:0.0315em;"}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[e]{.mord.mathnormal}[ann]{.mord.mathnormal}[o]{.mord.mathnormal}[u]{.mord.mathnormal}[n]{.mord.mathnormal}[ce]{.mord.mathnormal}[d]{.mord.mathnormal}[a]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 7.25M seed round led by [Cota Capital](https://www.cotacapital.com/knowledgecapital/flowforge-closes-the-gap-between-it-and-ot){rel="&#x22;nofollow&#x22;"}, joined by Westwave Capital, Uncorrelated Ventures, and Open Core Ventures. This brings a huge amount of extensive knowledge and experience in IoT, open source, enterprise-ready software solutions. You can read more about what this investment means for FlowFuse in this [TechCrunch article](https://techcrunch.com/2022/11/03/flowforge-nabs-7-2m-to-help-companies-integrate-iot-using-node-red){rel="&#x22;nofollow&#x22;"}.

[**Node-RED Dashboard - Beginners Guide**](https://stevesnoderedguide.com/node-red-dashboard){rel="&#x22;nofollow&#x22;"}:br
It's great to see members of the Node-RED community taking their personal time to help us all build better projects. This write up takes you through the basics of creating your first Dashboard through to more advanced techniques to help your interfaces look professional and provide great user experiences.

[**FlowFuse Team News**](https://flowfuse.com/about/):br
We are currently recruiting [NodeJS Developers](https://boards.greenhouse.io/flowfuse/jobs/4463977004){rel="&#x22;nofollow&#x22;"}, a [Product Manager](https://boards.greenhouse.io/flowfuse/jobs/4717778004){rel="&#x22;nofollow&#x22;"}, a [Recruiter / PeopleOps Manager](https://boards.greenhouse.io/flowfuse/jobs/4687876004){rel="&#x22;nofollow&#x22;"} and a [Senior Community Manager](https://boards.greenhouse.io/flowfuse/jobs/4700809004){rel="&#x22;nofollow&#x22;"}. You can view any of the roles we currently have open and apply on our [Jobs page](https://boards.greenhouse.io/flowfuse){rel="&#x22;nofollow&#x22;"}.

We'd also like to welcome [Pez Cuckow](https://github.com/Pezmc){rel="&#x22;nofollow&#x22;"} who joined FlowFuse as a Senior Software Engineer in October.

[**Try FlowFuse for Free**](https://app.flowfuse.com/account/create?code=RELEASE1){rel="&#x22;nofollow&#x22;"}:br
As a thank you for reading our newsletters we’d like to offer you a free, small project for one month on our managed FlowFuse platform when you create a new team. To get this discount please follow [this link](https://app.flowfuse.com/account/create?code=RELEASE010){rel="&#x22;nofollow&#x22;"} or use the code RELEASE1 when on the payment page after creating a new team. As an open source project you can also use [FlowFuse](https://flowfuse.com/docs/install/) for free, forever.


# FlowFuse 1.1 released with persistent file storage

Persist files on your FlowFuse Projects, publish locally developed flows to dozens of Devices in a few clicks, and use our new interface for managing Project Deployments.

We're pleased to announce version 1.1 is now available! The latest release of the FlowFuse application contains new features, many improvements, and bug fixes. Keep reading for the details of what's in this release or you can watch our 1 minute roundup video of the new release above.

## Features

[Persistent File Storage](https://github.com/FlowFuse/flowfuse/issues/998){rel="&#x22;nofollow&#x22;"} We've had a great deal of feedback
from our customers that being able to persist files in a project is a vital feature
in Node-RED. In FlowFuse 1.1 flows can now create and persist files within
your Projects. We know those files are used in many creative ways and we're looking
forward to seeing how users improve their Projects using this new feature.

[Import Snapshots from Outside FlowFuse](https://flowfuse.com/docs/migration/node-red-tools/) Developers may wish to
work on Node-RED in a local environment but want an easy path to share that with their team. You can now link your Node-RED instances running outside of FlowFuse and push Snapshots directly into your FlowFuse Projects to leverage FlowFuse fully. With this new feature we've made it effortless to push a local build of a project to FlowFuse for deployment to your staging and production FlowFuse instances.

## Improvements

[Project Deployments UX](https://github.com/FlowFuse/flowfuse/issues/1046){rel="&#x22;nofollow&#x22;"}
We've reworked the interface for managing your FlowFuse Deployments of Node-RED.
We are seeing FlowFuse users deploying their Projects to edge devices at scale.
This is another step towards making it easier for users to manage a large quantity
of devices in their Projects.

When users change their username, email address, or password they'll now be
notified through email of changes to ensure they were made by the
user.

In this release a lot of effort went into the install process, specifically the
local install method. First and foremost; a default Stack and Template will be
installed automatically. That will ensure users get up and running with
Node-RED more quickly. Administrators of each platform can still change Stacks
and Templates when needed. Secondly, the installer now auto generates the
configuration file for Mosquitto, the MQTT broker FlowFuse uses. This again should save
administrators time when installing FlowFuse.

## Bug Fixes

The v1.0.1 release included a bug fix where [snapshot rollbacks](https://github.com/FlowFuse/flowfuse/issues/1186){rel="&#x22;nofollow&#x22;"}
didn't work, which has also been included in v1.1 onwards.

We've fixed the following bugs in this release.

- When installing the stack during a FlowFuse installation the process would quit on Windows [#62](https://github.com/FlowFuse/installer/issues/62){rel="&#x22;nofollow&#x22;"}
- After accepting an invite to join a team, users are no longer seeing a blank page [#1208](https://github.com/FlowFuse/flowfuse/issues/1208){rel="&#x22;nofollow&#x22;"}
- Pagination on device deployments wasn't showing all devices [#1207](https://github.com/FlowFuse/flowfuse/issues/1207){rel="&#x22;nofollow&#x22;"}
- Markdown rendering when selecting the project type wasn't quite working, fixed now! [#1171](https://github.com/FlowFuse/flowfuse/issues/1171){rel="&#x22;nofollow&#x22;"}
- Continuous spinner in UI body when entering a new (short) password [#1280](https://github.com/FlowFuse/flowfuse/issues/1280){rel="&#x22;nofollow&#x22;"}
- Friendly stack name not shown in the Change Project Stack option list [#1169](https://github.com/FlowFuse/flowfuse/issues/1169){rel="&#x22;nofollow&#x22;"}
- The stacks view in the admin area didn't render properly [#1260](https://github.com/FlowFuse/flowfuse/issues/1260){rel="&#x22;nofollow&#x22;"}
- Like the deployments page, pagination for stacks was broken. [#1164](https://github.com/FlowFuse/flowfuse/issues/1164){rel="&#x22;nofollow&#x22;"}
- Several UX and UI bugs got polished away!

## Contributors

We'd like the thank the following for their contributions to this release:

[mikermcneil](https://github.com/mikermcneil){rel="&#x22;nofollow&#x22;"} for their work on [#1301](https://github.com/FlowFuse/flowfuse/pull/1301){rel="&#x22;nofollow&#x22;"}

As an open-source project, we welcome community involvement in what we're building.
If you're interested in contributing, checkout our [guide in the docs](https://flowfuse.com/docs/contribute/).

### Try it out

As said before, a lot of effort went into the local installer. We're confident
you can have your own FlowFuse running locally in about 30 minutes.
[Get started right away!](https://flowfuse.com/docs/contribute/local/)
([Docker](https://flowfuse.com/docs/install/docker/) and [Kubernetes](https://flowfuse.com/docs/install/kubernetes/)
are available too!)

If you'd rather use our hosted offering: [Sign up for FlowFuse Cloud](https://app.flowfuse.com/account/create?code=RELEASE11){rel="&#x22;nofollow&#x22;"}
with the coupon **RELEASE11** to get your first project free for a month.

### Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.1. To use
persisted files you'll need to upgrade your projects stack. You'll be prompted
to do so on the project page.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/)

### Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there.

If you hit any problems with the platform please raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That also includes if you have any feedback or feature requests.

Chat with us on the `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.

You can also raise a support ticket by emailing <support@flowfuse.com>


# Re-spin of Docker-Compose install package

After [yesterdays 1.1.0 FlowFuse release](https://flowfuse.com/blog/2022/11/flowforge-1-1-released/) we noticed a few minor issues with the docker-compose install instructions.

We had relied on the fact we are now publishing container images to Docker Hub to install the new `flowforge/file-server` container. At this time we are only building images for amd64 and arm64. Further, it was only tagged them with the current release number.

To remedy this we tagged v1.1.1 of the docker-compose project in which we have included the required `Dockerfile` and resources to build the `flowforge/file-server` locally, updated the `build-containers.sh` script to build this container. We will also build the published containers for armv7 and include a latest tag going forward.


# Challenges scaling Node-RED with DIY tooling

In this post, I'm going to share some of the challenges customers face when
scaling Node-RED with Do-It-Yourself tooling.

Specifically, we'll talk about
common threads in their journey building their own tooling around Node-RED, its
flows, and deploying them. Node-RED is a visual programming environment for
wiring together hardware devices, APIs and online services in a single
application. It's great because it's flexible enough to be used by both
beginners and experts alike; however, going from one instance of Node-RED to 100
isn't for the faint-hearted.

### Zero to hero in a few days

If you’re new to Node-RED and are just getting started, the first step is simple:
go to [nodered.org](https://nodered.org){rel="&#x22;nofollow&#x22;"}, download, install and run. There’s no
need to configure anything or set up credentials or security or alerts. You can
get started with Node-RED straight away by simply running it on your machine.
The guides and scripts provided on Node-RED or are more than enough to get
started. You'll dive right in and start developing your flows.

### Onto the second instance

The next instance is a simple copy of the first. You'll need to make sure that
you are installing the same version on both instances, and that any
configuration files (such as the `settings.js`) are also in sync.

The second instance improves the first equally. Docs are read again,
improvements are made, and copied over. Life's good! Although there's a slight
itch to start automating the setup, it's ignored. Just too many open questions
on how to achieve it: write scripts in bash? Or can we use Node-RED to manage
Node-RED? Automation can wait, there's new flows to implement!

### Wake-up call; how many of them do we have?

There's nothing like a good ol' wake-up call to get you back on track. One of
our team members asked a questions about a buggy flow you've got no recollection
of. During the investigation there's issues left and right; it's running a much
older version, missing standard packages, the settings are out of date, and the
timezone not set to UTC? Adoption of Node-RED is going quite well, it's useful
and effective. Gets the job done without fuss. But now there's toil in
maintaining them; ensure the right tooling is build, properly documented, it
needs dashboards and overviews, lots of work to be done. Not quite business
related, but Node-RED is important for the company, the bosses sure would
approve spending 2 months building these tools!

But then something happened, there was a higher priority project to be picked up.
Some tooling could be written for a couple of hours a month, but not two
dedicated months to get it in tip top shape. Better than nothing! Built a
dashboard in Node-RED to keep track of all devices, there's some scripts and a
few flows that aid in monitoring and maintenance. Scaling further is possible,
but confidence in the tooling isn't sky high.

### Data extraction at scale; now there's over 100

At [FlowFuse](https://flowfuse.com) we've got regular conversations with customers managing 100s of
devices. Scaling to that many devices and runtimes requires hours of development
each week alongside monitoring, maintenance, and auditing.

As a side effect of investing more time into Node-RED and its ecosystem the
organization has developed a few standards. Standard custom nodes that are
pre-installed (👋 `moment.js`), a style guide published for developing flows,
maybe even flow linting: <https://github.com/node-red/nrlint>{rel="&#x22;nofollow&#x22;"}

The security model is fairly decent. One just hopes the
[CISO](https://nl.wikipedia.org/wiki/Chief_Information_Security_Officer){rel="&#x22;nofollow&#x22;"} doesn't
inspects them, but it's a fair bet they won't; we're far away from the
headquarters, right?

Many other edge cases itch in the back of our heads, but we can't focus on those right now.

### Conclusion

Node-RED is a great tool, it's got many built-in features that make it easy to
get started with no coding experience necessary. Running it at scale, in a
production environment can require a lot of sys-ops and dev-ops time and we
think [FlowFuse](https://flowfuse.com) is a great solution to keep that admin and tech debt in check.

If you're running into these challenges we believe we can help, you can adopt
our [free and open source edition](https://flowfuse.com/docs/install/).

Additionally, to get a head start or enhance your current setup, explore our [Beginner's Guide to Professional Node-RED](https://flowfuse.com/ebooks/beginner-guide-to-a-professional-nodered/). This comprehensive ebook offers a clear overview of Node-RED’s capabilities and practical tips for making the most of its features.


# Community News November 2022

Welcome to the FlowFuse newsletter for November 2022, a monthly roundup of what’s been happening with both FlowFuse and the wider Node-RED community.

If you've got something that you think we should share on our newsletters please [get it touch](mailto\:contact@flowfuse.com).

[**Node-RED Nears 3.1 Release**](https://github.com/node-red/node-red/milestone/19){rel="&#x22;nofollow&#x22;"}
As we mentioned last month, the release of Node-RED 3.1 is expected very soon. 3.1 includes lots of great new features such as support for [locking flows in the editor](https://github.com/node-red/node-red/pull/3938){rel="&#x22;nofollow&#x22;"} and [improving the user experience around hiding flows](https://github.com/node-red/node-red/pull/3930){rel="&#x22;nofollow&#x22;"}. As an open source project the development of Node-RED is entirely dependent on individuals and companies giving their time to work towards each new release. If you'd like to know how you can get involved you can read more on the [Node-RED web site](https://nodered.org/about/contribute/){rel="&#x22;nofollow&#x22;"}.

[**FlowFuse 1.1 Released**](https://flowfuse.com/blog/2022/11/flowforge-1-1-released/):br
Version 1.1 of FlowFuse was released on 24th November. Our latest release included some great new features such as [Persistent file storage](https://github.com/FlowFuse/flowfuse/issues/998){rel="&#x22;nofollow&#x22;"}, the ability to [import Node-RED snapshots](https://flowfuse.com/docs/migration/node-red-tools/) from outside of FlowFuse and a much improved interface to [deploy projects to your devices](https://github.com/FlowFuse/flowfuse/issues/1046){rel="&#x22;nofollow&#x22;"}. We're now working towards our final release of 2022 which is due just before Christmas. You can see what we are planning to deliver in that release and beyond on [FlowFuse's project board](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"}.

If you’d like to learn more about what else was included in 1.1 you can do so on our [blog post](https://flowfuse.com/blog/2022/11/flowforge-1-1-released), [GitHub release page](https://github.com/FlowFuse/flowfuse/releases/tag/v1.1.0){rel="&#x22;nofollow&#x22;"}, and [Youtube channel](https://www.youtube.com/watch?v=134iljE_urI){rel="&#x22;nofollow&#x22;"}.

[**Node-Redscape - 100% Free, Open-Source Escape Room Control Software**](https://github.com/playfultechnology/node-redscape){rel="&#x22;nofollow&#x22;"}:br
As we'll come to later in this newsletter, FlowFuse visited an Escape Room in Winchester as part of our team meet-up. Co-incidentally, a great Node-RED project came up a few days after our visit which we thought was worth sharing. In their own words [Node-Redscape](https://github.com/playfultechnology/node-redscape){rel="&#x22;nofollow&#x22;"} 'provides a set of templates, flows, and examples that turn Node-RED into a complete Escape Room automation system'. Very topical for us and also seems like a great project. You can learn more about the project on [Youtube](https://www.youtube.com/watch?v=f9yYDxqK_2E){rel="&#x22;nofollow&#x22;"} as well as on [Github](https://github.com/playfultechnology/node-redscape){rel="&#x22;nofollow&#x22;"}.

**FlowFuse team meetup**
FlowFuse is a fully remote team, we currently have a strong skew towards western Europe but we are in the process of adding team members in each of the continents. On that point, any great Product Managers who live in Antarctica are encouraged to [apply for a job with us](https://boards.greenhouse.io/flowfuse/jobs/4717778004){rel="&#x22;nofollow&#x22;"}! Remote work is great but it's also valuable to get everyone together in the real world from time to time. FlowFuse had such a meet up last month in Winchester, UK. We came from near and far and took the opportunity to have productive round-table discussions about some features we are working towards in 1.2 and beyond. We also dropped into [Clue Capers](https://cluecapers.co.uk/){rel="&#x22;nofollow&#x22;"}, a great Escape Room in the center of Winchester who provided the photo below to mark the occasion.

!["The FlowFuse team pictured during our visit to Clue Capers"](https://flowfuse.com/blog/2022/12/images/clue-capers.jpg "The FlowFuse team pictured during our visit to Clue Capers")

[**FlowFuse Team News**](https://flowfuse.com/about/):br
We are currently recruiting a [Product Manager](https://boards.greenhouse.io/flowfuse/jobs/4717778004){rel="&#x22;nofollow&#x22;"}, and a [Senior Community Manager](https://boards.greenhouse.io/flowfuse/jobs/4700809004){rel="&#x22;nofollow&#x22;"}. You can view any of the roles we currently have open and apply on our [Jobs page](https://boards.greenhouse.io/flowfuse){rel="&#x22;nofollow&#x22;"}.

[**Try FlowFuse for Free**](https://app.flowfuse.com/account/create?code=RELEASE11){rel="&#x22;nofollow&#x22;"}:br
As a thank you for reading our newsletters we’d like to offer you a free, small project for one month on our managed FlowFuse platform when you create a new team. To get this discount please follow [this link](https://app.flowfuse.com/account/create?code=RELEASE11){rel="&#x22;nofollow&#x22;"} or use the code RELEASE11 when on the payment page after creating a new team. As an open source project you can also use [FlowFuse](https://flowfuse.com/docs/install/) for free, forever.


# Create HTTP triggers with authentication

Having an HTTP endpoint trigger your flows is very useful. From any browser or command line you now have the ability to trigger your flows.

Doing so safely with authentication is slightly harder, but not a lot. FlowFuse makes it rather easy to accomplish.

### Creating the HTTP flow

When you start a project on FlowFuse, remember the project name. For this how-to we’ll use `example`. Open the editor and drag in the HTTP In node as well as the HTTP response node. Connect them, and add a debug node, which is connected to the “HTTP in” node.

First off; let’s set the HTTP in node properties:

![Shows the UI to edit the node's properties](https://flowfuse.com/blog/2022/12/images/edit-http-node.png "Shows the UI to edit the node's properties")

You can import this flow into your own project if you’d like:

```text
[{"id":"4faa84d37a52bb28","type":"group","z":"3c6e2dc732ada815","name":"Allow HTTP Post request to trigger a flow","style":{"label":!0},"nodes":["1fa26e0ed3ddec1a","45a180052e1a2f43","09347881f4fa4057"],"x":34,"y":79,"w":472,"h":122},{"id":"1fa26e0ed3ddec1a","type":"http in","z":"3c6e2dc732ada815","g":"4faa84d37a52bb28","name":"HTTP Trigger","url":"/http-trigger","method":"post","upload":!1,"swaggerDoc":"","x":130,"y":120,"wires":[["45a180052e1a2f43","09347881f4fa4057"]]},{"id":"45a180052e1a2f43","type":"http response","z":"3c6e2dc732ada815","g":"4faa84d37a52bb28","name":"Empty HTTP response","statusCode":"200","headers":{},"x":360,"y":120,"wires":[]},{"id":"09347881f4fa4057","type":"debug","z":"3c6e2dc732ada815","g":"4faa84d37a52bb28","name":"Print HTTP Request","active":!0,"tosidebar":!0,"console":!1,"tostatus":!1,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":360,"y":160,"wires":[]}]
```

Now I’ve opened a terminal and executed:

```text
curl -X POST https://example.flowforge.com/http-trigger
```

When there’s no output, that means it’s all good! There should be an empty message in the debug console in the Node-RED editor though

### Securing the HTTP trigger with a username and password

The problem with our trigger is that anyone with internet access could trigger it. That’s not a great idea. So let’s secure this endpoint with HTTP Basic Authentication. There are various ways to include a secure endpoint in Node-RED, we’ve built authentication directly into FlowFuse to make it easier for all users. On the FlowFuse project, go to settings and then to ‘Editor’. Under the section HTTP Auth you can set a username and password. You should generate both by a random string generator, and store the credentials somewhere safe. Restart the project to have the runtime pick up the changes, and the endpoint is secured!

Let’s validate the endpoint that worked a minute ago doesn’t anymore:

```text
curl -X POST https://example.flowforge.cloud/http-trigger
=> Unauthorized
```

Let’s get it working again: (replace `<username>` and `<password>` with the details from the sticky note)

```text
curl -X POST https://<username>:<password>@example.flowforge.cloud/http-trigger
```

That’s it! You now have a flow that’s protected by a username and password combination!


# FlowFuse 1.1.2 released

We've published a maintenance fix with an important fix for the Palette Manager in Node-RED.

A [bug](https://github.com/FlowFuse/flowfuse/issues/1367){rel="&#x22;nofollow&#x22;"} was reported this week
where a user was unable to install additional nodes into their Node-RED project
using the editor's palette manager.

We tracked it down to an issue that was introduced in the 1.1 release, where the
project template lets you list nodes that should be blocked from being installed.
It was interpreting an empty list to mean *disallow everything*! Not quite the
intended behaviour.

Whilst tracking this down, we also spotted a bug ([#1379](https://github.com/FlowFuse/flowfuse/issues/1379){rel="&#x22;nofollow&#x22;"})
around editing this same setting that made it tricky to work around without this
release being published.

These issues have now been fixed and FlowFuse 1.1.2 published.

## Bug Fixes

In additional to the above issues, this release includes some further fixes around
the docker and helm components:

- Fix fileStore hostname by @flecoufle in [#59](https://github.com/FlowFuse/docker-compose/pull/59){rel="&#x22;nofollow&#x22;"}
- Fix healthcheck [#62](https://github.com/FlowFuse/docker-compose/pull/62){rel="&#x22;nofollow&#x22;"} [#63](https://github.com/FlowFuse/docker-compose/pull/63){rel="&#x22;nofollow&#x22;"} [#74](https://github.com/FlowFuse/helm/pull/74){rel="&#x22;nofollow&#x22;"}

## Contributors

We'd like to thank the following people for their contributions to this release:

[flecoufle](https://github.com/flecoufle){rel="&#x22;nofollow&#x22;"} for their work on [#59](https://github.com/FlowFuse/docker-compose/pull/59){rel="&#x22;nofollow&#x22;"}

As an open-source project, we welcome community involvement in what we're building.
If you're interested in contributing, checkout our [guide in the docs](https://flowfuse.com/docs/contribute/).

### Upgrading FlowFuse

This release has already been rolled out to \[FlowFuse Cloud]\({{ site.appURL }}).

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/)

### Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there.

If you hit any problems with the platform, please raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That also includes if you have any feedback or feature requests.

Chat with us on the `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.

You can also raise a support ticket by emailing <support@flowfuse.com>


# FlowFuse 1.2 is now available with single sign on and persistent context storage

Control access to FlowFuse using single sign-on and retain context values when restarting projects.

We're pleased to announce version 1.2 is now available! The latest release of the FlowFuse application contains new features, improvements, better documentation, and bug fixes.

We've put a great deal of work in this release to make it easier to run your own self-managed instance of FlowFuse. That includes significant improvements for FlowFuse in [Kubernetes](https://flowfuse.com/docs/install/kubernetes/) and [Docker](https://flowfuse.com/docs/install/docker/).

Keep reading for the details of what's in this release or you can watch our 1 minute roundup video of the new release above.

## Features

[Single Sign-On](https://github.com/FlowFuse/flowfuse/issues/226){rel="&#x22;nofollow&#x22;"} Single sign-on (SSO) is a method of authentication that allows a user to access multiple applications or systems with a single set of login credentials, improving security, productivity, and user experience, and reducing IT overhead. We've implemented SSO using the Security Assertion Markup Language [(SAML)](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language){rel="&#x22;nofollow&#x22;"} framework. This allows users of FlowFuse Cloud, Premium and the open source edition to easily access their FlowFuse projects.

[Persistent Context](https://github.com/FlowFuse/flowfuse/issues/212){rel="&#x22;nofollow&#x22;"} Node-RED provides a way to store information that can be shared between different nodes and flow executions without using the messages that pass through a flow. This is called ‘context’. You can now select if context should be stored in memory or in persistent storage. Persistent storage allows the stored values to be recalled after a restart of your project. You can see a demonstration of this feature on our [Youtube channel](https://youtu.be/ma2vYrXmssc){rel="&#x22;nofollow&#x22;"}.

## Improvements

- In FlowFuse 1.1 we added logging of user actions. In 1.2 we’ve [improved the audit log interface](https://github.com/FlowFuse/flowfuse/issues/517){rel="&#x22;nofollow&#x22;"} to help you read the recorded user actions.
  !["An image of the new audit log interface of FlowFuse"](https://flowfuse.com/blog/2022/12/images/audit-log.png "An image of the new audit log interface of FlowFuse")
- Configuring DNS for FlowFuse has historically been challenging as for most FlowFuse installs you'll need two entries. One for the FlowFuse application, and one for the Node-RED projects. There's been updates to the documentation to make it much easier to set this up, and much faster. Please checkout the new [documentation](https://flowfuse.com/docs/install/dns-setup/).
- We've updated our documentation to always link to the latest build (older builds are still available).
- Previously customers were asked to build their own containers for the main FlowFuse applications, as well as the Node-RED ones. For the Node-RED containers this allows customers to pre-install packages in the container they intent to use. For FlowFuse Cloud these containers are build by FlowFuse. These containers are now published to the [Docker Hub](https://hub.docker.com/u/flowforge){rel="&#x22;nofollow&#x22;"}. This makes it much easier to get up and running with your first containers.
- We are now pushing our Docker builds to Docker Hub, this saves users from having to build the Docker images when installing or updating. These containers are used by default by `docker-compose`.
- Setting up MQTT for inter-project communication and communication with devices has been simplified. Please read the improved the documentation around configuration of [MQTT](https://github.com/FlowFuse/flowfuse/issues/1397){rel="&#x22;nofollow&#x22;"}.

## Bug Fixes

We've fixed the following bugs in this release.

- Unable to edit 'Prevent Install of External nodes' template option [#1376](https://github.com/FlowFuse/flowfuse/issues/1376){rel="&#x22;nofollow&#x22;"}
- Self-managed FlowFuse needs an external email server to deliver email to users. FlowFuse should be able deal with the email server being offline and gracefully recover once it is back online. [#1159](https://github.com/FlowFuse/flowfuse/issues/1159){rel="&#x22;nofollow&#x22;"}
- Duplicate Activity Log for Project whose state is in flight [#1461](https://github.com/FlowFuse/flowfuse/issues/1461){rel="&#x22;nofollow&#x22;"}

## Contributors

We'd like the thank the following for their contributions to this release:

[flecoufle](https://github.com/flecoufle){rel="&#x22;nofollow&#x22;"} for their work on [#59](https://github.com/FlowFuse/docker-compose/pull/59){rel="&#x22;nofollow&#x22;"}

[sumanpaikdev](https://github.com/sumanpaikdev){rel="&#x22;nofollow&#x22;"} for their work on [#53](https://github.com/FlowFuse/docker-compose/pull/53){rel="&#x22;nofollow&#x22;"}

[sdirosa](https://github.com/sdirosa){rel="&#x22;nofollow&#x22;"} for their work on [#1326](https://github.com/FlowFuse/flowfuse/pull/1326){rel="&#x22;nofollow&#x22;"}

As an open-source project, we welcome community involvement in what we're building.
If you're interested in contributing, checkout our [guide in the docs](https://flowfuse.com/docs/contribute/).

### Try it out

In 1.2 we've continued to improve the experience of running your own self managed FlowFuse installation. We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install our [local build](https://flowfuse.com/docs/contribute/local/), through [Docker](https://flowfuse.com/docs/install/docker/), or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

If you'd rather use our hosted offering: [Sign up for FlowFuse Cloud](https://app.flowfuse.com/account/create?code=FF12){rel="&#x22;nofollow&#x22;"}
with the coupon **FF12** to get your first project free for a month.

### Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.2. To use
persistent context you'll need to upgrade your projects stack.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

### Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there.

If you hit any problems with the platform please raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That also includes if you have any feedback or feature requests.

Chat with us on the `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.

You can raise a support ticket by emailing <support@flowfuse.com>.

We've also added a live chat widget to our website, you can access it using the icon on the bottom right corner of our website. We'd love to hear from you.


# Configure FlowFuse in Docker to secure all traffic

Following on from our [previous article](https://flowfuse.com/blog/2022/10/ff-docker-gcp/) in which we covered how to run FlowFuse in Docker on Google’s Cloud Platform, today we are going to look at how to secure HTTP traffic to your FlowFuse server.

### Introduction

When we wrote the first part of this series FlowFuse didn't have an easy path to secure HTTP traffic. Happily, two versions of FlowFuse later and at least partially inspired by these blogs, we have added the configuration you need in Docker to use HTTPS with minimal work.

That addition makes our job of explaining this setup a lot easier, credit to our developers for seeing the value of having an easy implementation of HTTPS in FlowFuse as part of our [1.0 build](https://flowfuse.com/blog/2022/10/flowforge-1-released/).

To achieve secure HTTPS traffic we are employing a great service called [Let's Encrypt](https://letsencrypt.org/){rel="&#x22;nofollow&#x22;"}. In their own words, "Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit". In practice Let's Encrypt will allow us to easily secure HTTPS traffic.

We are also utilising a Docker image called [acme-companion](https://github.com/nginx-proxy/acme-companion){rel="&#x22;nofollow&#x22;"} which makes the configuration of Let's Encrypt a breeze. To quote the project's own Github page "acme-companion is a lightweight companion container for nginx-proxy. It handles the automated creation, renewal and use of SSL certificates for proxied Docker containers through the ACME protocol". It's a great project and credit to the team over there for making it a lot easier to secure the internet.

Now we've covered our goals and the tools we are going to use let's configure our existing GCP VM to secure all web traffic.

### Prerequisites

As mentioned above, you will need to be running FlowFuse version 1.0 or higher to follow this guide. If you are using an older version you can upgrade now using the [instructions here](https://flowfuse.com/docs/upgrade/).

### Update Docker Compose

The first step is to edit our Docker compose file. We're using Nano again to edit files so we will run this command:

```text
sudo nano /opt/flowforge/docker-compose-1.1.1/docker-compose.yml
```

In the docker-compose.yml file, un-comment the following lines:

```yaml
- "./certs:/etc/nginx/certs"
```

```yaml
- "443:443"
```

```yaml
 acme:
    image: nginxproxy/acme-companion
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./acme:/etc/acme.sh"
    volumes_from:
      - nginx:rw
    environment:
      - "DEFAULT_EMAIL=mail@example.com"
    depends_on:
      - "nginx"
```

We should also redirect all traffic to use HTTPS, to do that un-comment the following in the nginx service section:

```yaml
Environment:
      - "HTTPS_METHOD=redirect"
```

We now need to add the configuration for LetsEncrypt, edit the following lines to include a valid email address and the correct domain for where you are hosting your FlowFuse server:

```yaml
- "DEFAULT_EMAIL=mail@example.com"
```

```yaml
- "LETSENCRYPT_HOST=mqtt.example.com"
```

```yaml
- "LETSENCRYPT_HOST=forge.example.com"
```

Save and exit from that file, in Nano you can do that by pressing ‘control x’ then ‘y’ then the Return key.

### Update flowforge.yml

Next, we need to edit the public\_url for the MQTT broker:

```text
sudo nano /opt/flowforge/docker-compose-1.1.1/docker-compose.yml
```

Then replace ws\:// with wss\://

```yaml
public_url: wss://mqtt.flowforge-demo.com
```

Save and exit from that file, in Nano you can do that by pressing ‘control x’ then ‘y’ then the Return key.

### Restart your Docker containers

OK, we should be ready to restart the Docker containers, run the command:

```text
sudo docker compose -p flowforge up -d
```

If you reload your FlowFuse root directory in a web browser you should now see that your traffic is encrypted using LetsEncypt.

![A screenshot from Safari web browser showing that the traffic to FlowFuse is encrypted](https://flowfuse.com/blog/2022/12/images/https-working.png "A screenshot from Safari web browser showing that the traffic to FlowFuse is encrypted")

Nice! That’s it, you can now access your FlowFuse installation securely.

In the next and final part of this series of articles, we are going to look at how we can actually use FlowFuse including how to build flows and deploy and update them on Devices linked to a project.


# FlowFuse Inc. becomes a member of the OpenJS Foundation

We're pleased to share the news we've joined the OpenJS Foundation to bolster our
support for the Node-RED community.

One of our [founding principles](https://flowfuse.com/handbook/company/principles/#open-source-stewardship) is
the importance of Open Source being at the core of what we do.

Node-RED has been part of the [OpenJS Foundation](https://openjsf.org/){rel="&#x22;nofollow&#x22;"} since it was formed in 2019.
The Foundation provides the project a vendor-neutral home and enables its open governance model that
allows anyone to get involved.

It also provides some vitally important resources to the community, such as the hosting for the
[community forum](https://discourse.nodered.org){rel="&#x22;nofollow&#x22;"}, which regularly gets over 1.5 Million page views a
month.

With my Node-RED Project Lead hat on, I regularly see the impact the foundation has had on the growth
of the Node-RED community. These are things that may not always be obvious to our end users, but
we wouldn't be where we are today with them.

The success of what we're building with FlowFuse relies on a strong and healthy Node-RED community.
Becoming members of the Foundation allows us to provide more yet more support to Node-RED and the wider
JavaScript communities represented by the foundation.

For more information about this news, check out the [OpenJS Foundation blog post](https://openjsf.org/announcement/2022/12/13/welcoming-flowforge-to-the-openjs-foundation/){rel="&#x22;nofollow&#x22;"}.


# Format your Node-RED flows for better team collaboration

When it comes to working on Node-RED flows as part of a team, there are a few best practices that can make things go more smoothly.

From formatting your flows for readability to providing clear comments on nodes and groups, a little bit of effort upfront can save your team a lot of headaches down the road. In this post, we'll cover some of the main things to keep in mind when working on Node-RED flows as part of a team.

### Give your groups descriptive names

Let’s start with [grouping your flows](https://nodered.org/docs/user-guide/editor/workspace/groups){rel="&#x22;nofollow&#x22;"} and giving each group a clear explanation of what it does. Compare the first to the second example below and consider how much more quickly you can understand what the flow is doing.

#### This is not helpful, 'Time' doesn't tell you enough to understand the flow's purpose.

!["Screenshot showing the example of flow having the bad group name"](https://flowfuse.com/blog/2022/12/images/name-bad.png "Screenshot showing the example of flow having the bad group name")

#### This is much better, we know what the flow is doing without inspecting the nodes.

!["Screenshot showing the example of flow having the good group name"](https://flowfuse.com/blog/2022/12/images/name-good.png "Screenshot showing the example of flow having the good group name")

### Explain what your switches do

Try to make it obvious what each switch does without having to open the node editor. Ask a question in the switch's name and make a positive answer the top connection out.

#### This is not easy to understand, what does the switch do?

!["Screenshot showing the example of flow having the switch with bad name"](https://flowfuse.com/blog/2022/12/images/switch-bad.png "Screenshot showing the example of flow having the switch with bad name")

#### This is a lot better, we can see that the top debug should be triggered.

!["Screenshot showing the example of flow having the switch with good name"](https://flowfuse.com/blog/2022/12/images/switch-good.png "Screenshot showing the example of flow having the switch with good name")

### Where possible your flows should work down the canvas

It makes it so much easier to understand what happens and in which order if your flows start at the top of the canvas and work down to the bottom.

#### This is almost unreadable, it's very hard to work out the order of the groups.

!["Screenshot showing an example of flow that doesn't work down the canvas"](https://flowfuse.com/blog/2022/12/images/flowdown-bad.png "Screenshot showing an example of flow that doesn't work down the canvas")

#### Where as this is so much easier to understand.

!["Screenshot showing an example of flow that works down the canvas"](https://flowfuse.com/blog/2022/12/images/flowdown-good.png "Screenshot showing an example of flow that works down the canvas")

### Use link nodes rather than wires to join groups

Groups should not be joined using wires, it just looks untidy and quickly reduces readability of your flows.

#### The wire is blocking the title, it only gets worse as you add more wires.

!["Screenshot showing an example of flow with wires blocking group titles"](https://flowfuse.com/blog/2022/12/images/link-bad.png "Screenshot showing an example of flow with wires blocking group titles")

#### You can see the group titles easily now.

!["Screenshot showing an example of flow with link nodes improving readability"](https://flowfuse.com/blog/2022/12/images/link-good.png "Screenshot showing an example of flow with link nodes improving readability")

### Keep your groups compact

Keeping your groups compact will save time when reading the flow. This is especially helpful if when viewed on a smaller screen.

#### Consider how hard a flow made of groups spaced out like this would be to read on a smaller laptop screen.

!["Screenshot showing an example of flow with widely spaced groups"](https://flowfuse.com/blog/2022/12/images/compact-bad.png "Screenshot showing an example of flow with widely spaced groups")

#### This now takes up less space and is arguably easier to read on any screen size.

!["Screenshot showing an example of flow with compact groups"](https://flowfuse.com/blog/2022/12/images/compact-good.png "Screenshot showing an example of flow with compact groups")

### Don’t cross ~~beams~~ wires

Crossed wires are not only hard to read, they can lead to misinterpretation of what a flow actually does. Where possible don’t cross your wires, where you can’t avoid it try to make sure it’s easy for the reader to understand where wires cross as rather than join.

#### This is confusing, which change node does the top switch output link to?

!["Screenshot showing an example of the flow with nodes having crossed beams/wires"](https://flowfuse.com/blog/2022/12/images/wires-bad.png "Screenshot showing an example of the flow with nodes having crossed beams/wires")

#### This is better, much less chance of confusing the change nodes.

!["Screenshot showing an example of the flow with nodes having correctly linked beams/wires"](https://flowfuse.com/blog/2022/12/images/wires-good.png "Screenshot showing an example of the flow with nodes having correctly linked beams/wires")

### Don’t use link nodes in groups where avoidable

Excessive link nodes within groups can make a flow much harder to understand, where possible use wires to join nodes within a group.

#### This is hard to read and you will end up checking the link nodes again and again.

!["Screenshot showing the example of flow having the uneccessary link nodes"](https://flowfuse.com/blog/2022/12/images/groupwires-bad.png "Screenshot showing the example of flow having the uneccessary link nodes")

#### Functionally identical to the example above, it should only take a few seconds to understand this flow now.

!["Screenshot showing an example of the flow with the avoided link nodes"](https://flowfuse.com/blog/2022/12/images/groupwires-good.png "Screenshot showing an example of the flow with the avoided link nodes")

### Boost Collaboration with FlowFuse

[FlowFuse](https://flowfuse.com) is a cloud-based platform that makes working together on Node-RED projects easier and more efficient. It’s trusted by industries like manufacturing and smart building management, as well as textiles, to improve their systems. For more information, refer to our [customer stories](https://flowfuse.com/customer-stories/).

With FlowFuse, you can quickly [set up and manage teams](https://flowfuse.com/docs/user/team/), giving each member the right level of access. It keeps all your [Node-RED instances organized in one place](https://www.youtube.com/watch?v=KOnQnR7yfT0&list=PLpcyqc7kNgp3nRacWBJ9JUVUJqtTjXdvh&index=2){rel="&#x22;nofollow&#x22;"}, so your team can collaborate seamlessly. Plus, it features [snapshots](https://www.youtube.com/watch?v=m2Onip4Lf4w){rel="&#x22;nofollow&#x22;"}, which let you restore previous versions of your flows if something goes wrong. FlowFuse simplifies team collaboration, making it easier to manage and work on Node-RED projects.

**[Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now for a free trial and experience FlowFuse's powerful collaboration tools!**

### Conclusion

Working on Node-RED flows as part of a team doesn't have to be a headache. By following some simple best practices you can make collaboration smooth sailing for everyone involved. So next time you're starting work on a new Node-RED flow, remember these tips and make life easier for yourself and your teammates.


# Why you need FlowFuse when you already have Node-RED?

Many organizations face challenges in IT/OT convergence. There are many protocols, disparate devices, and everything is a brownfield project. Furthermore, skilled engineers are hard to find. Many organizations find themselves maintaining systems and integrations, and have little time left to improve continuously.

This is why Node-RED is adopted so widely, it makes a world of difference through two of its properties: Low-Code Development and the ability to integrate with a wide range of hardware and software systems. Node-RED makes it easy to program data collection, then use that data for decision making, and provide feedback to both your digital platform and the physical reality of your business. Furthermore, Node-RED is unrivalled in making data accessible. The data previously locked in a walled garden of your hardware providers is now accessible and obtainable. With that, more data is available and better decisions are made, faster.

FlowFuse makes developer collaboration, flow deployment, and scaling of infrastructure easy when working with Node-RED. It offers an intuitive user interface for creating, deploying, monitoring, and managing multiple Node-RED projects. FlowFuse also provides one-click deployment to thousands of devices, making it easy to manage large-scale environments.

These features make FlowFuse a valuable tool for organizations using Node-RED to build applications and automate processes. Enabling for further adoption of Node-RED to integrate more systems, for even better decisions.

This not only reduces operational costs but it also allows an organization to be far more agile with their Node-RED projects than was possible without FlowFuse.

We would be happy to talk to you more about how FlowFuse can help you get the most value from Node-RED. Please [contact us](https://flowfuse.com/contact-us/) to learn more.


# Community News December 2022

Welcome to the FlowFuse newsletter for December 2022, a monthly roundup of what’s been happening with both FlowFuse and the wider Node-RED community. 2022 was a really exciting year for the development of both Node-RED and FlowFuse. Node-RED released version 3, another major milestone for the project. FlowFuse hit version 1, leaving the beta development stage. We are excited to see what the community can achieve in 2023!

If you've got something that you think we should share on our newsletters please [get it touch](mailto\:contact@flowfuse.com).

[**Node-RED Nears 3.1 Release**](https://github.com/node-red/node-red/milestone/19){rel="&#x22;nofollow&#x22;"}
The release of Node-RED 3.1 is expected very soon. 3.1 includes lots of great new features such as support for [locking flows in the editor](https://github.com/node-red/node-red/pull/3938){rel="&#x22;nofollow&#x22;"} and [improving the user experience around hiding flows](https://github.com/node-red/node-red/pull/3930){rel="&#x22;nofollow&#x22;"}. As an open source project the development of Node-RED is entirely dependent on individuals and companies giving their time to work towards each new release. If you'd like to know how you can get involved you can read more on the [Node-RED web site](https://nodered.org/about/contribute/){rel="&#x22;nofollow&#x22;"}.

[**FlowFuse 1.2 Released**](https://flowfuse.com/blog/2022/12/flowforge-1-2-0-released/):br
Version 1.2 of FlowFuse was released on 23rd December. Our last release of the year included some great new features such as [Single Sign-On](https://flowfuse.com/docs/cloud/introduction/#single-sign-on) to make it easier for your team to access your projects and [Persistent Context](https://flowfuse.com/docs/cloud/introduction/#node-red-context) which allows you to retain context values even when restarting projects. We're now working towards our first release of 2023 which is due on 19th January. You can see what we are planning to deliver in that release and beyond on [FlowFuse's project board](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"}.

If you’d like to learn more about what else was included in 1.2 you can do so on our [blog post](https://flowfuse.com/blog/2022/12/flowforge-1-2-0-released/), [GitHub release page](https://github.com/FlowFuse/flowfuse/releases/tag/v1.2.0){rel="&#x22;nofollow&#x22;"}, and [Youtube channel](https://www.youtube.com/watch?v=u7TjqUAub1g){rel="&#x22;nofollow&#x22;"}.

[**5 IoT Sensor Technologies to Watch**](https://iot-analytics.com/5-iot-sensor-technologies/){rel="&#x22;nofollow&#x22;"}:br
According to this detailed article from iot-analytics.com, on average, four new sensors are connected with every new IoT device that comes online. With approximately 14 billion current IoT connections, this means more than 50 billion connected sensors have been deployed. IoT sensor technology plays a crucial role in the IoT tech stack because these sensors collect data from the physical world and convert it into digital signals. We think [their article](https://iot-analytics.com/5-iot-sensor-technologies/){rel="&#x22;nofollow&#x22;"} is worth a read.

[**Custom Node Spotlight - node-red-contrib-string**](https://flows.nodered.org/node/node-red-contrib-string){rel="&#x22;nofollow&#x22;"}
String manipulation is the bread and butter of so many programming tasks. Node-RED has a lot of tools to help you edit your strings including support for [JSONata](https://jsonata.org/){rel="&#x22;nofollow&#x22;"} and using the trusty function node. For those of us who prefer to keep things 'no-code' [node-red-contrib-string](https://flows.nodered.org/node/node-red-contrib-string){rel="&#x22;nofollow&#x22;"} allows you to stack string manipulations together quickly and easily. It has a huge library of ready to use functions.

[**FlowFuse Team News**](https://flowfuse.com/about/):br
We’d like to welcome two new members to the FlowFuse team. [Ian Skerrett](https://twitter.com/ianskerrett){rel="&#x22;nofollow&#x22;"} has joined as our Head of Marketing and [Tracy Anthony](https://www.linkedin.com/in/tracyanthonyfernandez/){rel="&#x22;nofollow&#x22;"} has joined as our HR Manager. FlowFuse continues to grow and we are becoming a truly global team.

Would you like to work for FlowFuse? We are currently recruiting [NodeJS Developers](https://boards.greenhouse.io/flowfuse/jobs/4463977004){rel="&#x22;nofollow&#x22;"} to join our team. You can view any of the roles we currently have open and apply on our [Jobs page](https://boards.greenhouse.io/flowfuse){rel="&#x22;nofollow&#x22;"}.

[**Try FlowFuse for Free**](https://app.flowfuse.com/account/create?code=FF12){rel="&#x22;nofollow&#x22;"}:br
As a thank you for reading our newsletters we’d like to offer you a free, small project for one month on our managed FlowFuse platform when you create a new team. To get this discount please follow [this link](https://app.flowfuse.com/account/create?code=FF12){rel="&#x22;nofollow&#x22;"} or use the code FF12 when on the payment page after creating a new team. As an open source project you can also use [FlowFuse](https://flowfuse.com/docs/install/) for free, forever.


# Using Environment Variables in Node-RED (2026)

Programs, written with Node-RED or otherwise, need to sometimes retrieve information that wasn’t decided on during the creation of the program.

Contextual data like configuration, which user is executing the code, differentiate based on what device is executing a flow, or sometimes secrets which shouldn’t be exposed in the code. This is usually done through environment variables. These are pairs of strings, a key with an attached value, which are accessed by their key. Say you want to access an API endpoint with a key, you’d save the key as `API_KEY` with the value set to `yoursupersecretkey`. FlowFuse allows setting environment variables. Let’s start using them to understand how they work.

One of the options for the `inject` node is to inject a `env variable`, short for; you guessed it: Environment Variable. In this case we’re going to one that’s pre-defined by Node-RED: `NR_FLOW_NAME`. The name of each variable is in all caps by convention. When connecting this inject to a debug it prints “Flow 1” for me.

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

![Using an environment variable in Node-RED](https://flowfuse.com/blog/2023/01/images/node-red-use-env-var.png "Using an environment variable in Node-RED")

Leveraging environment variables can also be done with other nodes, like for example `change`, `switch`. Note however; you can set the `inject` node to output the value for `FOO` even when it doesn’t exist, but it doesn’t allow you to check in the switch node for example if `FOO` exists.

Node-RED allows you to set environment variables, but not to change them when executing flows. If you want to update data during execution, look into using [persistent context](https://flowfuse.com/docs/user/persistent-context/). Node-RED doesn’t support Environment Variables like other programming environments do. When the flow is deployed the environment variables are replaced with the known values at that time. This is the biggest gotcha for most developers.

### Predefined variables

Our first example was using a predefined variable, exposed by Node-RED. As of 3.0 it exposes a few environment variables among which `NR_NODE_NAME`, `NR_GROUP_NAME`, and `NR_FLOW_NAME`.

[FlowFuse](https://flowfuse.com) extends this list with for example a `FF_PROJECT_ID` allowing you to for example understand what group of instances sent a certain message, but also sets them for each [device agent](https://flowfuse.com/docs/device-agent/introduction/). This allows users to pinpoint which device sent a message, for example to update a dashboard accordingly.

### Managing environments variables

In FlowFuse it’s easy to manage variables set for instances. Under settings in the environment tab it’s a form to set them. You’ll have to restart your instances to make them available in the cloud, and update the target snapshot for devices. When done, these are available.

!["Setting a environment variable in FlowFuse"](https://flowfuse.com/blog/2023/01/images/flowforge-set-env-var.png "Setting a environment variable in FlowFuse")

## Boost Your Node-RED Security with FlowFuse

FlowFuse provides a comprehensive platform for managing and securing your Node-RED solutions. It includes advanced security features such as role-based access control, Multi-factor Authentication (MFA), Single Sign-On (SSO), and encryption to protect your data and enhance operational efficiency.

Learn how FlowFuse can boost your Node-RED security and streamline management through the [FlowFuse security statement](https://flowfuse.com/platform/security/#application).

### Explore More on Security

- [Role-Based Access Control (RBAC) for Node-RED with FlowFuse](https://flowfuse.com/blog/2024/04/role-based-access-control-rbac-for-node-red-with-flowfuse/)
- [Protecting Instances from Being Modified](https://flowfuse.com/docs/user/devops-pipelines/#protected-instances)
- [How to Set Up SSO LDAP for Node-RED](https://flowfuse.com/blog/2024/07/how-to-setup-sso-ldap-for-the-node-red/)
- [How to Set Up SSO SAML for Node-RED](https://flowfuse.com/blog/2024/07/how-to-setup-sso-saml-for-the-node-red/)
- [Securing HTTP Traffic for Node-RED with FlowFuse](https://flowfuse.com/blog/2024/03/http-authentication-node-red-with-flowfuse/)
- [FlowFuse is now SOC 2 Type 1 Compliant](https://flowfuse.com/blog/2024/01/soc2/)


# FlowFuse 1.3 is now available, share your flows through our new team libraries and much more

Share your flows via team libraries, control access to your Node-RED dashboards using FlowFuse credentials, and filter your audit logs by users and actions.

We're pleased to announce version 1.3 is now available! Due to the recent holiday season, most of our team have been away from their desks but we still have some great new features to share. Keep reading for the details of what's in this release or you can watch our 1 minute roundup video of the new release above.

To make it easy for everyone to experience FlowFuse, we are introducing a new [free 30-day trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}. With this trial, you can experience the power of using FlowFuse to quickly deliver Node-RED applications in a reliable, repeatable, collaborative, and secure manner. To get your trial simply [sign up for a new FlowFuse team](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}.

## Features

[Share your flows via team libraries](https://github.com/FlowFuse/flowfuse/issues/237){rel="&#x22;nofollow&#x22;"} :br
FlowFuse has now added the ability for you to share your flows via the import and export features in Node-RED. Once you export a flow everyone else in your FlowFuse team will be able to import your work into their projects. You can see a demonstration of this new feature in [the video](https://youtu.be/B7XK3TUklUU){rel="&#x22;nofollow&#x22;"} below.

::div
  :::lite-youtube
  ---
  params: rel=0
  style: "width: 704px; height: 100%;"
  title: YouTube video player
  videoid: B7XK3TUklUU
  ---
  :::

[Control access to your Node-RED dashboards using FlowFuse credentials](https://github.com/FlowFuse/flowfuse/issues/1325){rel=""nofollow""} :br
In FlowFuse 0.10 we added the ability to secure endpoints created within your FlowFuse projects. This allows you to create dashboards or APIs and limit who can access them. In 1.3 we've added the ability for you to limit access to those same resources based on the visitor having a user account on your FlowFuse team. You can see a demonstration of this new feature in [the video](https://youtu.be/JRk-Cf7eNIo){rel=""nofollow""} below.

  :::div
    ::::lite-youtube
    ---
    params: rel=0
    style: "width: 704px; height: 100%;"
    title: YouTube video player
    videoid: JRk-Cf7eNIo
    ---
    ::::

  [Filter your audit logs for easier reading](https://github.com/FlowFuse/flowfuse/issues/1448){rel=""nofollow""} :br
  In FlowFuse 1.3 we’ve added the ability to filter your admin logs by user or action type. We think this is a great new feature which will help admins have confidence that they will be able to review the audit logs quickly when needed. You can see a demonstration of this new feature in [the video](https://youtu.be/p0Vuy5x42Go){rel=""nofollow""} below.

    ::::div
      :::::lite-youtube
      ---
      params: rel=0
      style: "width: 704px; height: 100%;"
      title: YouTube video player
      videoid: p0Vuy5x42Go
      ---
      :::::

    ## Improvements

    [Allow installation of FlowFuse on devices which can't access npm](https://github.com/FlowFuse/device-agent/issues/45){rel=""nofollow""} :br
    We've had feedback from customers that in some cases they want to use FlowFuse devices on hardware which cannot access [Node Package Manager](https://www.npmjs.com/){rel=""nofollow""} (npm). In a standard configuration of Node-RED, access to npm is mandatory to run your flows. In FlowFuse 1.3.0 we've added the ability for you to import all the data usually installed from npm without your devices having access to the npm service.

    ## Bug Fixes

    We've fixed the following bugs in this release.

    - Project status UI sometimes getting stuck when restarting [#1232](https://github.com/FlowFuse/flowfuse/issues/1232){rel=""nofollow""}
    - SSO users asked to click link in email to verify [#1543](https://github.com/FlowFuse/flowfuse/issues/1543){rel=""nofollow""}
    - SSO users unable to edit settings [#1542](https://github.com/FlowFuse/flowfuse/issues/1542){rel=""nofollow""}
    - SSO users not redirected to editor when signing in [#1481](https://github.com/FlowFuse/flowfuse/issues/1481){rel=""nofollow""}

    ## Contributors

    We'd like to thank the following for their contributions to this release:

    [flecoufle](https://github.com/flecoufle){rel=""nofollow""} for their work on [#89](https://github.com/FlowFuse/helm/pull/89){rel=""nofollow""}

    As an open-source project, we welcome community involvement in what we're building.
    If you're interested in contributing, checkout our [guide in the docs](https://flowfuse.com/docs/contribute/).

    ## Try it out

    We're confident you can have self managed FlowFuse running locally in under 30 minutes.
    You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

    If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel=""nofollow""} on FlowFuse Cloud.

    ## Upgrading FlowFuse

    \[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.3.

    If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
    guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

    ## Getting help

    Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there.

    If you hit any problems with the platform please raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel=""nofollow""}.
    That's also a great place to send us any feedback or feature requests.

    You can also get help on [the Node-RED forums](https://discourse.nodered.org/){rel=""nofollow""}

    AS well as in the [forum within our Github project](https://github.com/FlowFuse/flowfuse/discussions){rel=""nofollow""}

    Chat with us on the `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel=""nofollow""}

    You can raise a support ticket by emailing <support@flowfuse.com>

    We've also added a live chat widget to our website, you can access it using the icon on the bottom right corner of our website. We'd love to hear from you.
    ::::
  :::
::


# FlowFuse 1.2.1 released

We've published a maintenance release containing a fix for new users.

This release fixes an [issue](https://github.com/FlowFuse/flowfuse/issues/1537){rel="&#x22;nofollow&#x22;"} introduced in FlowFuse 1.2 where users were not being sent their welcome email when they first sign up to the platform. As the sign-up page asks them to click on the link in that email, it left them waiting for an email that wasn't going to arrive.

The same fix also addresses an [issue](https://github.com/FlowFuse/flowfuse/issues/1514){rel="&#x22;nofollow&#x22;"} where users could not sign up using an email with a `+` in it. This is a restriction we apply to users signing up with Single Sign-On enabled email domains - but the check was being applied to everyone.

### Upgrading FlowFuse

This release has already been rolled out to \[FlowFuse Cloud]\({{ site.appURL }}).

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/)

### Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there.

If you hit any problems with the platform, please raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That also includes if you have any feedback or feature requests.

Chat with us on the `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}.

You can also raise a support ticket by emailing <support@flowfuse.com>


# Telling the FlowFuse Story

During my first month at FlowFuse, I have been helping to refine the FlowFuse story. Trying to answer the questions: What is the value FlowFuse brings to our customers and what features does FlowFuse want to offer the Node-RED community?

People love Node-RED because it makes it trivial to connect different types of services and data, create flows of the data, and store/forward data to the cloud or a database. The Node-RED [library of nodes and flows](https://flows.nodered.org/){rel="&#x22;nofollow&#x22;"} enables connections to almost anything. The speed and ease of use of Node-RED allows non-traditional programmers to accelerate their innovation and exploration of what is possible.

Node-RED is great for individuals to unlock what is possible for an organization. However, there are some challenges if you want to scale Node-RED into a corporate development platform. Challenges like how do you set up a development -> test -> production delivery pipeline, how to share instances with different developers, how do you create repeatable release processes, how can you deploy the same Node-RED instance out to multiple target environments (devices or servers).

Today, we see many industrial engineers using Node-RED to collect and integrate data from different factory and industrial equipment. Many PLC vendors, like Opto22, are enabling this by making Node-RED as a development environment for the PLC platform. In the manufacturing and industrial automation industries, benefits like reliability and security are important for the continuous operation of these facilities. This is why we believe these types of organizations will be looking for tools that improve their software development lifecycle.

In the larger software development community, DevOps tools are being used to address many of these same challenges. DevOps is all about increasing the reliability and speed of the software development lifecycle. Using tools that increase automation of the software development process and improve collaboration and communication between developers. These are also many of the same challenges that FlowFuse solves for Node-RED users.

For these reasons, we see FlowFuse as being the DevOps platform for Node-RED. We believe FlowFuse enables a more reliable way to deliver Node-RED applications in a repeatable, collaborative and secure manner. What FlowFuse adds to Node-RED are some key features:

- Tools for collaborative Node-RED development
- The ability to manage remote deployments of Node-RED instances
- A more streamline way to deliver Node-RED applications
- FlowFuse Cloud provides a hosted Node-RED platform but FlowFuse can also be self-hosted
- FlowFuse also offers professional technical support to organizations that require the assurance of receiving help with production deployments.

We will be rolling out this new way of talking about FlowFuse over the next couple of days and weeks. We are always open to feedback about FlowFuse and would love to hear about your experience of using Node-RED.


# Getting Started with Node-RED

Node-RED is a visual programming tool for working with IoT devices and web services. It allows users to create flows using a drag-and-drop interface, making it easy to connect different nodes together to build powerful automations.

In this blog post, we'll take a look at how to get started with Node-RED and create some basic flows. We'll also explore the palette manager, a powerful feature that allows users to install and manage additional nodes for Node-RED.

### Installing Node-RED

First, you'll need to get an installation of Node-RED up and running. There are several ways to do this. We suggest using FlowFuse as it's very easy to get Node-RED running. You can also install Node-RED locally using npm (Node Package Manager), which comes with Node.js.

#### FlowFuse

To get Node-RED running on FlowFuse [sign up as a new user](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}. New users are enrolled in a trial and a Node-RED instance will be started for you within a minute.

Once that instance has booted up you can access Node-RED by pressing "Open Editor".

#### npm

To install Node-RED locally using npm, open up your terminal and type the following command:

```bash
npm install -g node-red
```

Once Node-RED is installed, you can start it by running the following command:

```bash
node-red
```

This will start the Node-RED server and open up the [editor in your web browser](http://localhost:1880){rel="&#x22;nofollow&#x22;"}. You can also specify a different port or a settings file if you want to. If you want to run Node-RED locally but manage it remotely through FlowFuse, check out [this guide](https://flowfuse.com/blog/2025/09/installing-node-red/).

### First Flow

Now that you have Node-RED running, let's take a look at how to create a simple flow. In this example, we'll create a simple "Hello World" endpoint. To do this, we'll use the `http in`, `http response`, and the `change` nodes, which can be found in the common nodes menu on the left of Node-RED.

First, drag an `http in` node into the editor. This node will listen for incoming HTTP requests. Next drag in the "change" and the `http response` node into the editor. Connect the `http in` node to the `change` node and connect the `change` node to the `http response` node. Your flow should look similar to this:

!["Screenshot showing the HTTP-in, Change, and HTTP-response nodes that we will be using throughout this blog for demonstration."](https://flowfuse.com/blog/2023/01/images/three-nodes.png "Screenshot showing the HTTP-in, Change, and HTTP-response nodes that we will be using throughout this blog for demonstration.")

To configure the `http in` node, double-click on it to open its properties. Here, you can set the URL that the node will listen to, as well as the method (GET, POST, etc.). In this example, we'll set the URL to `/hello` and the method to `GET`.

Now we need to set what the endpoint will respond with, we will do that in the `change` node. Double-click the `change` node then add "Hello World" to the field which says "to the value". It should look like this:

!["Configuring the change node to set the payload to Hello World"](https://flowfuse.com/blog/2023/01/images/set-reply.png "Configuring the change node to set the payload to Hello World")

To configure the `http response` node, double-click on it to open its properties. Here, you should set the "Status Code" to be 200. This is not vital for the demo to work but it's good practice to return the correct codes when something connects to an API. Status code 200 means the API responded OK. This is how your `http response` node should look:

!["Configuring the status node to set the response to 200"](https://flowfuse.com/blog/2023/01/images/response-code.png "Configuring the status node to set the response to 200")

You can read more about HTTP response codes in [this article](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes){rel="&#x22;nofollow&#x22;"}.

### Testing Your Flow

Now that we have our flow set up, we can deploy it by clicking the "Deploy" button in the top right corner of the editor. Once the flow is deployed, you can test it by opening up a web browser. If you installed Node-RED using npm navigate to "<http://localhost:1880/hello>{rel="&#x22;nofollow&#x22;"}". If you are working on FlowFuse and running cloud hosted instance, use your instance URL with "/hello" added to the end, it should look something like "<https://your-instance-name.flowfuse.cloud/hello>{rel="&#x22;nofollow&#x22;"}". You should see "Hello World!" displayed in the browser.

### Debug Output

One of the most powerful features in Node-RED is the ability to debug your flow. This can be done by adding a debug node to your flow and connecting it to the nodes you want to debug. When a message is sent through the connected node, the debug node will print the message in the debug sidebar on the right side of the editor. This can be very helpful when trying to understand how a flow is working or troubleshoot any issues.

### The Palette Manager

In addition to the built-in nodes, Node-RED also has a palette manager feature which allows users to easily install and manage additional nodes from the community. To access the palette manager, go to the menu in the top right corner and select "Manage Palette". Here, you can search for and install new nodes, as well as update or remove existing ones. This is a great way to extend the functionality of Node-RED and add new capabilities to your flows.

### Import the flow

If you want to view this flow you can import it using the code below. Copy the code then select Import from the top right menu in Node-RED. Paste the code into the field then press Import.

::render-flow
```json
[
    {
        "id": "a742e7a95697bb40",
        "type": "http in",
        "z": "9e9af3caa4dc14d3",
        "name": "",
        "url": "/hello",
        "method": "get",
        "upload": false,
        "swaggerDoc": "",
        "x": 180,
        "y": 200,
        "wires": [
            [
                "883e7d597f7c7c4b"
            ]
        ]
    },
    {
        "id": "aca024dcb79bdb92",
        "type": "http response",
        "z": "9e9af3caa4dc14d3",
        "name": "",
        "statusCode": "200",
        "headers": {},
        "x": 500,
        "y": 200,
        "wires": []
    },
    {
        "id": "883e7d597f7c7c4b",
        "type": "change",
        "z": "9e9af3caa4dc14d3",
        "name": "",
        "rules": [
            {
                "t": "set",
                "p": "payload",
                "pt": "msg",
                "to": "Hello World",
                "tot": "str"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 340,
        "y": 200,
        "wires": [
            [
                "aca024dcb79bdb92"
            ]
        ]
    }
]
```
::

### What's Next?

Well done, you've now got your first flow up and running. Enjoy using Node-RED and thanks for reading. Now if you want to start with your first beginner friendly project, building a weather dashboard is great, read this [article for getting started](https://flowfuse.com/blog/2025/12/getting-weather-data-in-node-red/). If you'd like to dive deeper into more Node-RED capabilities and how it can help in an enterprise setting, check out our [eBook The Ultimate Beginner Guide to a Professional Node-RED](https://flowfuse.com/ebooks/beginner-guide-to-a-professional-nodered/).


# Node-RED Tips - Wiring Shortcuts

There is usually more than one way to complete a given task in software and Node-RED is no exception. In this blog post we are going to share three useful tips to save yourself time when working on your flows.

### 1. Use control+left-click to search your nodes

Sometimes it's quicker to search for a node using its name rather than scrolling through the palette. Simply hold control then left-click to bring up a searchable list.

:video{ariaLabel="Selecting a node without having to use the palette" autoPlay="true" height="318" loop="true" muted="true" playsInline="true" preload="none" width="774"}

### 2. Split sections of your code using the link nodes

If you want to separate your flow into two distinct sections, link nodes are a great way to format your work. As we covered in our blog on [Node-RED best practices](https://flowfuse.com/blog/2022/12/node-red-flow-best-practice), the combination of link nodes and grouped flows is very powerful.

To split your flow select the input and output nodes then right click, select 'Show Action List' and then type 'split'. Select 'Split wire with link nodes'.

:video{ariaLabel="Spliting your nodes with link nodes" autoPlay="true" height="440" loop="true" muted="true" playsInline="true" preload="none" width="726"}

### 3. Link multiple inputs and outputs in one command

Once a switch node has several outputs it can be slow to manually wire each to the new node. Using the action menu (right click), select 'Show Action List' then 'Wire Node to Multiple' this option will join everything up in one step.

:video{ariaLabel="Linking multiple inputs and outputs in one command" autoPlay="true" height="362" loop="true" muted="true" playsInline="true" preload="none" width="538"}

We hope you found these tips useful, if you'd like to suggest some of your own tips which you think we should share in our future blog posts please [get in touch](mailto\:contact@flowfuse.com).


# Node-RED Tips - Deploying, Debugging, and Delaying

There is usually more than one way to complete a given task in software, and Node-RED is no exception. In each of this series of blog posts, we are going to share three useful tips to save yourself time when working on your flows.

### 1. Deploy just what you've changed

When deploying your changes, the default option is deploy everything which also restarts all your flows. You can also select to deploy just the nodes you edited or just the flows in which any changes were made.

This allows you to update part of your flow without restarting other sections. This can be really handy when you have different flows spread across your workspace or tabs but you don't want to reload them all each time you deploy.

:video{ariaLabel="Deploying only the changed nodes" autoPlay="true" height="322" loop="true" muted="true" playsInline="true" preload="none" width="898"}

### 2. Find which debug node generated an entry in the log

Once your flow has a few debug nodes it can become challenging to see which particular node generated an entry in the log. To quickly track an entry back to its source, click the text 'node: debug' and you will be whisked back to the specific debug node, even it it's elsewhere on you workspace or even on a different tab.

:video{ariaLabel="Finding the debug node which generated the log line" autoPlay="true" height="258" loop="true" muted="true" playsInline="true" preload="none" width="898"}

### 3. The delay node can be used as a rate limiter

Sometimes it's useful to be able to limit messages to only allow one every so many minutes. You may for example send alerts when a temperature sensor goes above a particular threshold but you don't want your email or instant messaging inbox being swamped with repeated alerts for the same issue.

You can use the delay node to limit how many messages can pass through in a given period of time.

Open the delay node settings, select Rate Limit then select 1 message per 15 minutes, then select 'Drop intermediate messages'. This flow will now output a maximum of one message every quarter of an hour, all others will be deleted.

:video{ariaLabel="Limiting how many alerts are sent" autoPlay="true" height="298" loop="true" muted="true" playsInline="true" preload="none" width="764"}

We hope you found these tips useful, if you'd like to suggest some of your own tips which you think we should share in our future blog posts please [get in touch](mailto\:contact@flowfuse.com).

## Enhance Efficiency with FlowFuse

FlowFuse is a cloud-based platform designed to boost collaboration, security, and scalability for your Node-RED applications. It features [numerous tools and functionalities](https://flowfuse.com/platform/features/) that streamline the development-to-deployment process, including one-click deployment, the [FlowFuse Assistant](https://flowfuse.com/docs/user/expert/), and other capabilities that simplify managing your Node-RED environment.

For more tips, tricks, and professional development techniques with Node-RED, check out our recommended eBook:

[The Ultimate Beginner's Guide to Professional Node-RED](https://flowfuse.com/ebooks/beginner-guide-to-a-professional-nodered/)


# Community News February 2023

Welcome to the FlowFuse newsletter for February 2023, a monthly roundup of what’s been happening with both FlowFuse and the wider Node-RED community.

If you've got something that you think we should share on our newsletters please [get in touch](mailto\:contact@flowfuse.com).

## News

### Node-RED Ask Me Anything

![AMA Session with Nick O'Leary and Rob Marcer](https://flowfuse.com/images/webinars/ama-feb.jpg "AMA Session with Nick O'Leary and Rob Marcer")

Do you have any questions about Node-RED or need some advice on a tricky issue using Node-RED? Here is your opportunity to get help from the experts.

Nick O'Leary, co-founder of Node-RED & CTO of FlowFuse, and Rob Marcer, Node-RED community member & Developer Educator at FlowFuse, will be hosting an interactive Ask Me Anything session. This is a great opportunity to ask questions of the Node-RED experts. If you have any questions for Nick and Rob you can send them in before the session using [this form](https://docs.google.com/forms/d/e/1FAIpQLSdfPq4lAQjdvqhTpoYtKiMNgP8vcMhZsAf_AG0MHuVMRK83_Q/viewform){rel="&#x22;nofollow&#x22;"}.

### [Free FlowFuse project for 30 days, no catches](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}

To make it easy for everyone to experience FlowFuse, we are introducing a new [free 30-day trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}. With this trial, you can experience the power of using FlowFuse to quickly deliver Node-RED applications in a reliable, repeatable, collaborative, and secure manner. To get your trial simply [sign up for a new FlowFuse team](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}.

### [1.3 Released](https://flowfuse.com/blog/2023/01/flowforge-1-3-0-released)

Version 1.3 of FlowFuse was released on 19th January. Our first release of 2023 included some great new features such as the ability to share flows via a [team library](https://www.youtube.com/watch?v=B7XK3TUklUU){rel="&#x22;nofollow&#x22;"}, [control access to your Node-RED dashboards](https://www.youtube.com/watch?v=JRk-Cf7eNIo){rel="&#x22;nofollow&#x22;"} using FlowFuse credentials, and [filtering on your audit logs](https://www.youtube.com/watch?v=p0Vuy5x42Go){rel="&#x22;nofollow&#x22;"} for easier reading. We also added the ability to use FlowFuse on devices which cannot access npm, we think this will be really valuable to users of networks with limited access to the internet.

We're now working towards release 1.4 which is due on 16th February. You can see what we are planning to deliver in that release and beyond on [FlowFuse's project board](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"}.

If you’d like to learn more about what else was included in 1.3 you can do so on our [blog post](https://flowfuse.com/blog/2023/01/flowforge-1-3-0-released/), [GitHub release page](https://github.com/FlowFuse/flowfuse/releases/tag/v1.3.0){rel="&#x22;nofollow&#x22;"}, and [Youtube channel](https://www.youtube.com/watch?v=ey3xv5j5x7k){rel="&#x22;nofollow&#x22;"}.

### [Team News](https://flowfuse.com/about/)

We are currently recruiting [NodeJS Developers](https://boards.greenhouse.io/flowfuse/jobs/4463977004){rel="&#x22;nofollow&#x22;"} as well as a [Graphic Designer](https://boards.greenhouse.io/flowfuse/jobs/4785058004){rel="&#x22;nofollow&#x22;"} to join our team. You can view any of the roles we currently have open and apply on our [Jobs page](https://boards.greenhouse.io/flowfuse){rel="&#x22;nofollow&#x22;"}.

## Node-RED in the Community

### [Twitch Streamer beats Elden Ring boss using mind control (and a little Node-RED)](https://www.vice.com/en/article/bvmqmm/watch-an-elden-ring-streamer-beat-a-boss-using-her-thoughts){rel="&#x22;nofollow&#x22;"}

[![Twitch Streamer beats Elden Ring boss using mind control (and a little Node-RED)](https://flowfuse.com/blog/2023/02/images/twitch.webp)](https://www.vice.com/en/article/bvmqmm/watch-an-elden-ring-streamer-beat-a-boss-using-her-thoughts){rel="&#x22;nofollow&#x22;"}
Streamer [Perrikaryal](https://www.twitch.tv/videos/1717013810){rel="&#x22;nofollow&#x22;"} used an electroencephalography (EEG) headset to read her brain activity which in turn sends commands via Node-RED to her gaming computer. She then proceeded to use that control method to beat one of the harder bosses in Elden Ring, a notoriously difficult game to start with. The end result is a great example of how Node-RED can link disparate tech together easily. You can [watch the full stream on Twitch](https://www.twitch.tv/videos/1722048787){rel="&#x22;nofollow&#x22;"}.

### [Run Node-RED in a web browser, client side!](https://www.linkedin.com/posts/kazuhitoyokoi_nodered-webassembly-activity-7015696090112958464-F3MA/?utm_source=share&utm_medium=member_android){rel="&#x22;nofollow&#x22;"}

[Kazuhito Yokoi](https://www.linkedin.com/in/kazuhitoyokoi/){rel="&#x22;nofollow&#x22;"} has implemented an early prototype of Node-RED runtime for WebAssembly. As a demonstration, he built a simple flow which shows the current location of the International Space Station (ISS). This proof-of-concept shows that an entire Node-RED flow can be executed in a browser. We think this could be a very useful option for running Node-RED in places where it wasn’t previously practical. You can view his work on this [GitHub project](https://github.com/kazuhitoyokoi/node-red-wasm){rel="&#x22;nofollow&#x22;"}.

### [Custom Node Spotlight - Moment](https://flows.nodered.org/node/node-red-contrib-moment){rel="&#x22;nofollow&#x22;"}

[![Moment converting a timestamp to ISO standard date and time](https://flowfuse.com/blog/2023/02/images/moment.png)](https://flows.nodered.org/node/node-red-contrib-moment){rel="&#x22;nofollow&#x22;"}
Being able to easily switch dates and times from one format to another is a huge timesaver, node-red-contrib-moment makes those tasks a breeze. The package actually includes two custom nodes, the first ‘Moment’ produces a nicely formatted Date/Time string using the Moment.JS library. The second custom node ‘Humanizer’ converts time durations (time spans) into textual descriptions (e.g. 2 minutes). We recommend you keep it in mind for any flows working with time conversions.


# FlowFuse v1.4 with device provisioning in bulk and staged development process

Deploy Node-RED to many devices quickly, and allow a staged development process with the latest release of FlowFuse v1.4.

Keep reading for the details of what's in this release or you can watch our 1 minute roundup video of the new release above.

To make it easy for everyone to experience FlowFuse, we are introducing a new free 30-day trial. You can now experience the power of using FlowFuse to quickly deliver Node-RED applications in a reliable, repeatable, collaborative, and secure manner. To get your free trial simply [sign up for FlowFuse Cloud;](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} no credit card is required!

## New User Features

**Automatic Device Provisioning**

Most prominently, FlowFuse 1.4 features automatic device onboarding for fleets. Simply download a FlowFuse device provisioning credential to allow quick roll-out to a whole fleet, without the need to have device specific configuration. When the agent starts, the FlowFuse agent and the Node-RED snapshot will automatically be provisioned to the device and start operations. [Issue #1212](https://github.com/FlowFuse/flowfuse/issues/1212){rel="&#x22;nofollow&#x22;"}

::div
  :::lite-youtube
  ---
  params: rel=0
  style: "width: 704px; height: 100%;"
  title: YouTube video player
  videoid: XTVw4O4-Crg
  ---
  :::

**Support for Staged Development**

A new feature of 1.4 is the ability to setup staged deployments. This makes it possible to simply move a project between a Development > Test > Production for your Node-RED application delivery. [Issue #1580](https://github.com/FlowFuse/flowfuse/issues/1580){rel=""nofollow""}

  :::div
    ::::lite-youtube
    ---
    params: rel=0
    style: "width: 704px; height: 100%;"
    title: YouTube video player
    videoid: 6QOmotlrwWw
    ---
    ::::

  ## Improvements

  - It's now much easier to change the resources available to your Node-RED instance. With a few clicks a resource intensive workload can be processed faster by changing between small, medium, or large instance types. [#595](https://github.com/FlowFuse/flowfuse/issues/595){rel=""nofollow""}
  - Last release allows users to capture flows in a shared library to reuse in another flow, now it's possible to preview the stored flows. [#1657](https://github.com/FlowFuse/flowfuse/issues/1657){rel=""nofollow""}
  - Add a synchronous mode for the FlowFuse persisted context store, next to the asynchronous mode already available. [#17](https://github.com/FlowFuse/flowforge-nr-persistent-context/issues/17){rel=""nofollow""}
  - Add a Last Seen status for devices connecting to FlowFuse. [#1599](https://github.com/FlowFuse/flowfuse/issues/1599){rel=""nofollow""}
  - Added a check to ensure the team slug is unique. [#1609](https://github.com/FlowFuse/flowfuse/issues/1609){rel=""nofollow""}
  - Optionally set snapshot as target at creation, to quickly roll out changes to remote deployments [#1527](https://github.com/FlowFuse/flowfuse/issues/1527){rel=""nofollow""}
  - Agents are more rugged when starting up if they're unable to connect to FlowFuse, and will retry to connect.
  - With FlowFuse v1.4 some changes were made under the hood to speed up the recovery
    of Node-RED instances. On terminal failures of an instance it will now be
    automatically be redeployed with the correct flows. This uses Kubernetes features
    and is also available if you've installed through [kubernetes](https://flowfuse.com/docs/install/kubernetes/).
    To migrate the old style of deployments to this system a restart or stack upgrade is needed.

  ## Bug Fixes

  We've fixed the following bugs in this release.

  - Deleting your only team, doesn't exit from the team UI. [#1630](https://github.com/FlowFuse/flowfuse/issues/1630){rel=""nofollow""}
  - Async Team Slug Check. [#1609](https://github.com/FlowFuse/flowfuse/issues/1609){rel=""nofollow""}
  - Improve communication of Device Last Seen and Status [#1599](https://github.com/FlowFuse/flowfuse/issues/1599){rel=""nofollow""}

  ## Contributors

  We'd like the thank the following for their contributions to this release:

  - [UlisesGascon](https://github.com/UlisesGascon){rel=""nofollow""} for their work on [#74](https://github.com/FlowFuse/installer/pull/74){rel=""nofollow""}

  As an open-source project, we welcome community involvement in what we're building.
  If you're interested in contributing, checkout our [guide in the docs](https://flowfuse.com/docs/contribute/).

  ## Try it out

  We're confident you can have self managed FlowFuse running locally in under 30 minutes.
  You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

  If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel=""nofollow""} on FlowFuse Cloud.

  ## Upgrading FlowFuse

  \[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.4.

  If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
  guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

  ## Getting help

  Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there.

  If you hit any problems with the platform please raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel=""nofollow""}.
  That's also a great place to send us any feedback or feature requests.

  You can also get help on [the Node-RED forums](https://discourse.nodered.org/){rel=""nofollow""}

  As well as in the [forum within our Github project](https://github.com/FlowFuse/flowfuse/discussions){rel=""nofollow""}

  Chat with us on the `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel=""nofollow""}

  You can raise a support ticket by emailing <support@flowfuse.com>

  We've also added a live chat widget to our website, you can access it using the icon on the bottom right corner of our website. We'd love to hear from you.
  :::
::


# Toward Highly Available Node-RED

Over the past few months we've held a lot of product discovery sessions and a topic
which keeps coming up is "HA Node-RED". All software will have failures, with
HA (high availability) the intent is to allow the workload to be processed
regardless. There's quite a few considerations which are often not covered
during product discovery calls, I'm going to discuss some of those points in this article.

When my job title was software engineer I was fortunate to design and
implement a HA system. It's an incredibly challenging and rewarding task for
any software engineer. As a topic, it's studied when obtaining a Computer Science
Bachelors degree, masters and even PhD. When tasked
to make a HA system, it took me a good month to define what our goals
were, and what we were willing to exchange for the properties sought. This
might be extra hardware, engineering hours, as well as organizational challenges.
For now, let's focus on the first two.

Let's start with defining the goal; reduce the impact of a Node-RED instance
being unresponsive for an arbitrary reason. In many use-cases the MTTR (Mean Time To
Recovery) is what's measured. When for example a hardware failure takes down the instance and the time to
detection is zero, it will likely still take a few hours to recover. Most of
the recovery work is also manual, and knowledge on how to recover is usually
[tribal knowledge](https://en.wikipedia.org/wiki/Tribal_knowledge){rel="&#x22;nofollow&#x22;"}. If the right
person is on-site, the right hardware is available, you kept great backups,
and are able to deploy the new hardware right away without support from other
functions you might just achieve an MTTR of 120 minutes!

### 5-10 minute Mean Time to Recovery

What's needed to bring this back to say 10 minutes? First, adopting FlowFuse will
help massively here. FlowFuse can be installed on-premise, or you can use our
managed Cloud offering. The software is the same, provided the on-premise
install uses our [Kubernetes install](https://flowfuse.com/docs/install/kubernetes/) method.

The key of the installation is the fact that the hardware layer is generalized
as a fleet. Detecting failures is included in the install, and very fast. Comparing
that to most alerting systems currently, it's usually a difference between night
and day. Furthermore, to decrease the recovery time significantly
there's a requirement to make software responsible for the whole procedure. Human intervention is much too slow.

To get the MTTR down to 5 minutes there's a requirement to either make hardware
automatically available to the fleet, or to over-provision (more hardware is
available than is needed at any given moment). When a hardware failure occurs
FlowFuse is configured to ensure all Node-RED instances that are KIA are
replaced. Bringing down the time to recovery to about 5 minutes.
For many use-cases a MTTR of 5 minutes is *good enough*.

### Sub minute MTTR

To go below the minute, or dare I say go below 10 seconds, we'll need to increase
the number of running Node-RED instances. Let's start with a hot-spare. Meaning
there's a running Node-RED instance with the flows exactly the same as another,
ready to pick up the work when the first has some failure. Note this isn't like
a relay race, there's no baton being passed from one Node-RED to the other. While
some data and messages might be lost, it's possible to redirect all workload from
the plagued Node-RED to the hot-spare in a matter of seconds. Hot-spares taking
over are usually only observed by humans a good few minutes after they replace a failed instance.

### Sub second!

Before this post turns into a theoretical exercise we'd really need to understand
which trade-offs are acceptable to you. There's the [CAP Theorem](https://en.wikipedia.org/wiki/CAP_theorem){rel="&#x22;nofollow&#x22;"}
which states 3 guarantees are wanted: Consistency, Availability, and Partition Tolerance. You get to pick
only two. In manufacturing the line must never be stopped due to a software failure where possible,
so Availability is the most important. The question is, what comes next? Is it Consistency meaning
all 3 instances have the same view of the global state? Or maybe Partition Tolerance where it's vital for each instance need to be able to predict the intended action even if it can't communicate to the others?

Whichever 2 you choose will dictate engineering choices in the pursuit of a great HA solution.

### The roadmap

With FlowFuse v1.4, released February 2023, a 5 minute mean time to recovery is
achieved for all flows running locally, that is: in the cluster. Going beyond this
milestone requires your input! I'd love to chat about your challenges, please
[pick a timeslot to discuss your requirements](https://meetings-eu1.hubspot.com/zeger-jan){rel="&#x22;nofollow&#x22;"}!


# MING Stack for IoT

The folks at Balena have created a bundle they call the [MING stack](https://hub.balena.io/organizations/marc6/apps/MING){rel="&#x22;nofollow&#x22;"}, (Mosquitto/MQTT, InfluxDB, Node-RED and Grafana) which first appeared back in [2019](https://forums.balena.io/t/ming-an-iot-sensor-stack-mosquitto-influxdb-nodered-grafana/36540){rel="&#x22;nofollow&#x22;"}. It is an interesting way to look at the IoT tech stack and a pattern I have seen used many times.

In the early days of the web, the [LAMP stack](https://en.wikipedia.org/wiki/LAMP_\(software_bundle\)){rel="&#x22;nofollow&#x22;"} was popularized as being the open source tech stack for hosting web sites. First used in 1998, LAMP stood for Linux, Apache, MySQL and Python/Perl/PHP. The LAMP stack did a lot to popularize open source software and create architecture patterns for building web applications. The LAMP stack did a lot to simplify a confusing technology landscape back in the early days of the web.

Can the IoT industry benefit from a MING stack? There is a fair amount of complexity building IoT systems. Therefore, having defined architecture patterns might help reduce some of the confusion. In fact, MING does bring together the key open source components of an IoT system:

- [Mosquitto](https://mosquitto.org/){rel="&#x22;nofollow&#x22;"} is the popular open source MQTT broker. MQTT has become the default protocol for IoT communications. The MQTT pub/sub protocol solves a lot for the communication challenges for IoT applications. In fact, I would define the M as being MQTT since there are a lot of MQTT broker implementations available.
- [InfluxDB](https://www.influxdata.com/){rel="&#x22;nofollow&#x22;"} is the popular open source time series database. Many IoT use cases are based on analyzing trends from different IoT devices. The classic examples is preventive maintenance of factory equipment. Having a time series database in your IoT architecture to record trending information will solve a lot of your data problems.
- [Node-RED](https://flowfuse.com/node-red/) is the popular low-code development environment that helps create flows of data. IoT systems are often pulling data from many different sources. The data needs to be filtered, analysed or transformed before being forward to another service. Node-RED has a large community of data nodes that makes it easy to collect data from a wide variety of sources. For instance in the industrial world, Node-RED nodes are available for OPC-UA, Modbus, S7, MQTT, various PLC platforms like Opto22, etc, etc.
- Finally [Grafana](https://grafana.com/){rel="&#x22;nofollow&#x22;"} is a popular open source visualization platform. Real time monitoring of IoT data is often the first applications deployed for IoT systems. Having graphing and dashboard technology available in your architecture makes perfect sense.

Another important feature of MING is that it can be deployed on the edge or in the cloud. IoT systems are inheritenty distributed so having the same technology available at different tiers is useful for lower barriers to adoption.

The LAMP stack was successful because it was:

- Open source and freely available for anyone to adopt and use.
- Highly flexible and customizable that allowed developers to adopt the stack to their use case.
- Back by large developer communities creating plugins/extensions, documentation, tutorials, etc.
- Easy to learn for developers with limited experience.

The MING stack has all the same characteristics. All four technologies are open source, highly flexible, back by large developer communities and relatively easy to learn. There are a lot of similarities between MING and LAMP.

Is MING relevant for IoT use cases? In my experience, people building IoT solutions are using 3-4 of the MING components. What is your experience?

## Simplify IoT Complexity with FlowFuse’s MIND Stack

If you’re concerned about managing multiple components in your IoT stack, FlowFuse has you covered. By bundling three of the four core elements of the MING stack, MQTT, Node-RED, and Grafana. FlowFuse simplifies your setup and management. This streamlined approach means fewer moving parts and less complexity, allowing you to focus on what matters most: your data and your applications.

With the FlowFuse [MIND stack](https://flowfuse.com/blog/2024/05/node-red-mind-stack-with-flowfuse/), you get a unified platform that integrates MQTT for efficient communication, Node-RED for seamless integration and data transformation, and [Dashboard 2.0](https://flowfuse.com/platform/dashboard/) for powerful visualizations, all from one place. This integration reduces configuration and maintenance overhead while ensuring consistent performance and security across your deployments. Explore the MIND stack now.

**Want an easier, more secure, and scalable IoT stack? Start your [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} of FlowFuse today.**


# Service Disruption Report for January 27th, 2023

On January 27th, 2023, we were alerted to an issue on FlowFuse Cloud where a user
was not able to access a newly created Node-RED Project, receiving a 404 error
instead. This post examines the issue that was hit, the timeline of events and
what we've done to resolve it.

## Summary

We hit a limit in the AWS Load Balancer that capped how many projects could be
exposed to the internet within our FlowFuse Cloud deployment. The result of this
was that users could create a new Node-RED project, but they would not be able
to access the editor.

We freed up capacity on the platform to allow user projects to be created without
hitting the limit, whilst also asking AWS to increase the limit in question which
they duly did.

However, we later discovered a second limit that was also being applied. That limit
was not one AWS permits us to change.

We successfully completely deployment of a change to our platform architecture
today that removes these limits from our environment.

In total, this lead to approximately 2 hours of disruptions on January 27th 2023 and again
on February 8th 2023 during which newly created Node-RED projects were not accessible.

Our logs show that two users were impacted during these times.

## Technical Details

When running FlowFuse within a Kubernetes environment, each project creates a
new Ingress Object configuration to tell the platform how to route HTTP traffic
to that project.

Our FlowFuse Cloud deployment runs within Amazon Elastic Kubernetes Service (EKS)
and uses the Application Load Balancer (ALB) service as its ingress controller.

When the FlowFuse platform creates the new Ingress Object configuration, EKS passes
that to ALB to generate the necessary configuration, which, given the configuration we
were using, created both a Target Group and Rule object.

With a default of limit of 100 Target Groups and Rules, that meant we had a technical
limit of 100 Node-RED projects within the FlowFuse Cloud environment. Increasing
the Rule limit did not solve the problem as the Target Group limit still applied.

Our initial mitigation was to delete any Node-RED projects we had created for
our own internal testing. We also identified that we could safely delete any rules
for suspended projects. A suspended project is one that is not actively running
in the platform. The code that resumes a suspended project would recreate any ingress
objects needed - so deleting the rule whilst suspended would not have any impact
on the project.

This gave us a small amount of headroom on the platform which crucially meant we
had time to develop a longer term solution.

## Resolution

There were two possible routes we could take to resolve this issue:

- Investigate how to reuse existing Target Groups rather than create one for each project :br Our intial research was inconclusive on how to achieve this. The AWS docs weren't
  clear enough to give us a definitive answer we felt comfortable to invest our time
  in.
- Move away from ALB in favour of nginx to provide our ingress load balancing. :br This was always our long term strategy as it was a prerequisite to FlowFuse
  features we have in the roadmap such as providing custom domains to projects.
  However it was potentially a large piece of work with a complicated migration
  for the existing environment.

Given it fitted with our longer-term strategic goals, we decided to move ahead
with replacing ALB with nginx.

After some initial development work and experimentation, we felt comfortable that
the migration was not as complicated as initially feared. We would have to manually
copy the existing ALB rules over - something that could be scripted. Once we had
nginx deployed we could push a small code change to FlowFuse to use it rather than
ALB, and also switch over the DNS entry to point at nginx.

Following a successful run through in our testing/staging environment, we decided
to move ahead updating the production environment.

This change was applied today, whilst we closely monitored the system to ensure
no further disruption occurred. We have validated that new projects can be
created without issue and everything is working as it should.

## Next Steps

With FlowFuse Cloud updated to use the new load balancer, we'll be closely monitoring
it over the next few days to ensure it operates normally.

We will also be taking on some follow-up activities to minimise the risk of this
type of issue happening again:

1. Review all AWS limits within our architecture. Identify any that pose a potential
   issue in the future. Ensure they are documented and a plan put in place to mitigate
   the impact based on our expected platform growth.
2. Add additional external monitoring for project liveness.
3. Review all logging around k8s apis

## Timeline

*All times are GMT.*

**2023-01-27 22:15** : (Friday evening) Customer reports via our support channel a newly created project was not accessible and returning a 404 error.

**2023-01-27 22:22** : We start examining the platform logs

**2023-01-27 22:47** : We identify we've hit the default Rules limit on the AWS Application Load Balancer

**2023-01-27 23:15** : To free-up capacity on the platform we delete any ununsed internal projects we were using for general testing. We also identify we can safely delete any rules associated with suspended projects.

**2023-01-27 23:41** : We complete deleting rules to give us enough head-room to see us through the weekend.

**2023-01-30 10:00** : We submit a request to AWS to increase the rule limit to 200 which is accepted and actioned later that day.

...

**2023-02-08 14:05** : Another customer reports seeing a newly created project returning a 404 error. We examine the ALB configuration and whilst it reports the new limit has been changed to 200, it appears to still be limiting at 100. We start identifing more suspended projects we can delete the rules for to free up capacity.

**2023-02-08 14:20** : Sufficient capacity is freed to enable the customer's projects to be accessible.

**2023-02-08 15:00** : We identify we've hit the ALB Target Group limit. This is a hard limit that AWS does not allow you to change. We begin researching options.

**2023-02-09** : Commited to plan to replace ALB with nginx. Successful migration of our staging environment.

**2023-02-10** : Change applied to production, FlowFuse 1.3.3 deployed and DNS updated to use the new load balancer.


# Some questions we didn't get to in our first webinar

There were some great questions from our [first webinar](https://www.youtube.com/watch?v=47EvfmJji-k){rel="&#x22;nofollow&#x22;"} that we didn't get time to answer, we wanted to share those questions and our answers here.

### Irvin asks, 'is it possible to save the debug information or data flow to a storage like Splunk or SQL'?

Hi Irvin, thanks for the question. I suspect you might be better using a custom node which is designed for logging data rather than capturing the debug node content to a database.

I've come across [Flogger](https://flows.nodered.org/node/node-red-contrib-flogger){rel="&#x22;nofollow&#x22;"} which seems to do a good job of logging, including support for multiple log files, and built in support for log rotation.

:video{ariaLabel="Capturing debug to a log file using Flogger" autoPlay="true" height="580" loop="true" muted="true" playsInline="true" preload="none" width="1470"}

If you really wanted to log to a database rather than a log file you could create your own logging subflow. Once that's in place you can drop it into your flow as needed to capture your debug data for later consumption.

### Anonymous asks 'can we make an mobile application with Node-RED or can the content only be accessed through a web browser'?

Hello Anon', it would be great if a Node-RED flow could be built into a mobile app. Sadly, there isn't a simple way to do so at the time of writing.

Assuming you want an easy way to package up and distribute the functionality you might be best creating a link to where the application is hosted. Both [iOS](https://www.macrumors.com/how-to/add-a-web-link-to-home-screen-iphone-ipad/){rel="&#x22;nofollow&#x22;"} and [Android](https://www.androidauthority.com/add-website-android-iphone-home-screen-3181682/){rel="&#x22;nofollow&#x22;"} support making a home icon. Once added using them is basically the same user experience as a locally installed application.

### John asks 'From the random node example in the webinar, the node connected to four different nodes. Is there an order to which is invoked first? Can that be controlled'?

Hi John, interesting question, thanks for sending it in. For the sake of any readers who were not an the webinar here is what you are describing.

!["Image showing the Flow where the random number generator sends a message to 4 nodes at the same time"](https://flowfuse.com/blog/2023/02/images/chart-flow.png "Image showing the Flow where the random number generator sends a message to 4 nodes at the same time")

All downstream nodes linked to the same prior node will be triggered at practically the same time.

You could use a delay node if you want to ensure a particular node is triggered first. It might also make sense to wire your flow in series rather than parallel. This would allow your functions to all execute in a specific order. That being said, in this case all but one of the nodes do not have outputs so using delays might be the only practical option.

### Abdelhamid asks, 'How can I delete a subflow'?

Thanks Abdelhamid, that's actually really easy to do. Double click the subflow you want to delete, then select 'delete subflow' from the top of your workspace.

!["Image showing how to delete a subflow"](https://flowfuse.com/blog/2023/02/images/delete-subflow.png "Image showing how to delete a subflow")

Thanks again to everyone who attended and participated in our first webinar. We have lots of other useful live content coming up soon, you can view and register for future events on our website's [webinars page](https://flowfuse.com/webinars/).


# Node-RED Tips - Exec, Filter, and Debug

There is usually more than one way to complete a given task in software, and Node-RED is no exception. In each of this series of blog posts, we are going to share three useful tips to save yourself time when working on your flows.

### 1. The Exec node allows you to interact with BASH from Node-RED

Exec allows you to run Shell commands and receive the value back into your flow. This opens up almost any command which can be run on the host devices CLI to your Node-RED flows.

:video{ariaLabel="Example flow using the Exec node" autoPlay="true" height="220" loop="true" muted="true" playsInline="true" preload="none" width="810"}

### 2. The Filter node helps you discard duplicate messages

It can be useful to only allow messages to proceed through a flow where their value is unique. Filter makes that task simple, no need to store the past values and check each new message against a list.

![Configuring the Filter node to only allow unique payloads through](https://flowfuse.com/blog/2023/03/images/filter-config.png "Configuring the Filter node to only allow unique payloads through")

Once your filter is configured as shown above, try sending different payloads through to see the outcome.

:video{ariaLabel="Demonstration showing the Filter node" autoPlay="true" height="194" loop="true" muted="true" playsInline="true" preload="none" width="802"}

### 3. Counting the amount of messages sent to a Debug node

The Debug node has a lot of great features that we don't see used that often. One example is the ability to show a count of how many messages have been sent to that Debug node since the last deploy.

![Setting up the debug to count messages](https://flowfuse.com/blog/2023/03/images/setup-counting-debug.png "Setting up the debug to count messages")

Once you've setup the node as shown above, you will see a counter under the debug.

:video{ariaLabel="Each message sent to the debug node is counted" autoPlay="true" height="380" loop="true" muted="true" playsInline="true" preload="none" width="916"}

We hope you found these tips useful, if you'd like to suggest some of your own tips which you think we should share in our future blog posts please [get in touch](mailto\:contact@flowfuse.com).

## Effortless Communication Between Node-RED Instances with FlowFuse Project Nodes

Managing communication between multiple Node-RED instances can be a complex task, but FlowFuse [Project Nodes](https://flowfuse.com/docs/user/projectnodes/) simplify this process dramatically. With these nodes, you can easily send messages between different Node-RED instances without worrying about complex configurations or network setup.

All you need to do is select the target instance by name, and FlowFuse takes care of the rest. This makes it faster and more efficient to handle multi-instance environments, ensuring seamless communication between flows across different devices or locations. Whether you're managing multiple environments or working on large-scale projects, FlowFuse Project Nodes save you time and reduce the risk of errors.

FlowFuse continues to innovate, making collaboration and scalability in Node-RED projects even easier. To learn more about these features, check out the [FlowFuse website](https://flowfuse.com).


# Node-RED Tips - Smooth, Catch, and Math

There is usually more than one way to complete a given task in software, and Node-RED is no exception. In each of this series of blog posts, we are going to share three useful tips to save yourself time when working on your flows.

### 1. Use the Smooth node to get the minimum and maximum values of your payloads

When taking data in from sensors sometimes a spurious value can be sent into your flow. This can result in oddities in a graph or even misfiring of actions such as turning on a heating system. The Smooth custom node allows you to store the min and max of a payload for the last few messages received.

![Using the Smooth node to return highest value from the last 100 payloads](https://flowfuse.com/blog/2023/03/images/smooth.png "Using the Smooth node to return highest value from the last 100 payloads")

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

You can in turn use this to ignore values that deviate too far from the sample. To help demonstrate the Smooth node, I've created a flow you can import into Node-RED.

```json
[{"id":"9484c25a0120bd48","type":"group","z":"dd95c0bca1101c86","name":"Automatically outputs random value (temperature in Celcius) between 0 & 25 every second","style":{"label":!0},"nodes":["e4f972f9daad6246","c7fc075a1915e87b","966a772c46dc2888"],"x":34,"y":59,"w":574,"h":82},{"id":"e4f972f9daad6246","type":"link out","z":"dd95c0bca1101c86","g":"9484c25a0120bd48","name":"link out 1","mode":"link","links":["33594c64783cdc45","e6bf7b494b48861e"],"x":355,"y":100,"wires":[]},{"id":"c7fc075a1915e87b","type":"inject","z":"dd95c0bca1101c86","g":"9484c25a0120bd48","name":"","props":[],"repeat":"1","crontab":"","once":!1,"onceDelay":0.1,"topic":"","x":130,"y":100,"wires":[["966a772c46dc2888"]]},{"id":"966a772c46dc2888","type":"random","z":"dd95c0bca1101c86","g":"9484c25a0120bd48","name":"","low":"0","high":"25","inte":"true","property":"payload","x":260,"y":100,"wires":[["e4f972f9daad6246"]]},{"id":"37380f26e8bfc98a","type":"group","z":"dd95c0bca1101c86","name":"Calculate average, high and low, save to flow","style":{"label":!0},"nodes":["cc3978c7c4ea56ed","e1819526a5f365c8","33594c64783cdc45","fea261a15b3b7683","e28a69232f1cac53","aecb1727be523240","e30039ee13e480a8"],"x":34,"y":259,"w":552,"h":142},{"id":"cc3978c7c4ea56ed","type":"change","z":"dd95c0bca1101c86","g":"37380f26e8bfc98a","name":"","rules":[{"t":"set","p":"high","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":!1,"x":310,"y":300,"wires":[["aecb1727be523240"]]},{"id":"e1819526a5f365c8","type":"change","z":"dd95c0bca1101c86","g":"37380f26e8bfc98a","name":"","rules":[{"t":"set","p":"low","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":!1,"x":310,"y":360,"wires":[["e30039ee13e480a8"]]},{"id":"33594c64783cdc45","type":"link in","z":"dd95c0bca1101c86","g":"37380f26e8bfc98a","name":"link in 1","links":["c07b2e101cecbd3b","e4f972f9daad6246"],"x":75,"y":320,"wires":[["e28a69232f1cac53","fea261a15b3b7683"]]},{"id":"fea261a15b3b7683","type":"smooth","z":"dd95c0bca1101c86","g":"37380f26e8bfc98a","name":"Min","property":"payload","action":"min","count":"100","round":"2","mult":"single","reduce":!1,"x":170,"y":360,"wires":[["e1819526a5f365c8"]]},{"id":"e28a69232f1cac53","type":"smooth","z":"dd95c0bca1101c86","g":"37380f26e8bfc98a","name":"Max","property":"payload","action":"max","count":"100","round":"2","mult":"single","reduce":!1,"x":170,"y":300,"wires":[["cc3978c7c4ea56ed"]]},{"id":"aecb1727be523240","type":"debug","z":"dd95c0bca1101c86","g":"37380f26e8bfc98a","name":"debug 23","active":!0,"tosidebar":!1,"console":!1,"tostatus":!0,"complete":"payload","targetType":"msg","statusVal":"payload","statusType":"auto","x":480,"y":300,"wires":[]},{"id":"e30039ee13e480a8","type":"debug","z":"dd95c0bca1101c86","g":"37380f26e8bfc98a","name":"debug 25","active":!0,"tosidebar":!1,"console":!1,"tostatus":!0,"complete":"payload","targetType":"msg","statusVal":"payload","statusType":"auto","x":480,"y":360,"wires":[]},{"id":"ec11a9ee9148b0b5","type":"group","z":"dd95c0bca1101c86","name":"Evaluate if an incoming value is between flow.high and flow.low, if it is not, send the message down a different wire and show an alert in debug","style":{"label":!0},"nodes":["9393c22b2e3c1ec8","1cd18307cb919159","7c1f474e646765a7","a209cd10f33ec401","f4b15283e55babf4","e6bf7b494b48861e"],"x":34,"y":419,"w":1032,"h":162},{"id":"9393c22b2e3c1ec8","type":"switch","z":"dd95c0bca1101c86","g":"ec11a9ee9148b0b5","name":"Was the value between flow.high and flow.low?","property":"payload","propertyType":"msg","rules":[{"t":"btwn","v":"high","vt":"flow","v2":"low","v2t":"flow"},{"t":"else"}],"checkall":"true","repair":!1,"outputs":2,"x":300,"y":480,"wires":[["1cd18307cb919159"],["7c1f474e646765a7","a209cd10f33ec401"]]},{"id":"1cd18307cb919159","type":"debug","z":"dd95c0bca1101c86","g":"ec11a9ee9148b0b5","name":"debug 15","active":!0,"tosidebar":!0,"console":!1,"tostatus":!1,"complete":"false","statusVal":"","statusType":"auto","x":560,"y":460,"wires":[]},{"id":"7c1f474e646765a7","type":"debug","z":"dd95c0bca1101c86","g":"ec11a9ee9148b0b5","name":"debug 16","active":!1,"tosidebar":!0,"console":!1,"tostatus":!1,"complete":"false","statusVal":"","statusType":"auto","x":560,"y":540,"wires":[]},{"id":"a209cd10f33ec401","type":"change","z":"dd95c0bca1101c86","g":"ec11a9ee9148b0b5","name":"Alert to debug when value is outside of the range","rules":[{"t":"set","p":"payload","pt":"msg","to":"The value was outside of the range","tot":"str"}],"action":"","property":"","from":"","to":"","reg":!1,"x":690,"y":500,"wires":[["f4b15283e55babf4"]]},{"id":"f4b15283e55babf4","type":"debug","z":"dd95c0bca1101c86","g":"ec11a9ee9148b0b5","name":"debug 17","active":!0,"tosidebar":!0,"console":!1,"tostatus":!1,"complete":"false","statusVal":"","statusType":"auto","x":960,"y":500,"wires":[]},{"id":"e6bf7b494b48861e","type":"link in","z":"dd95c0bca1101c86","g":"ec11a9ee9148b0b5","name":"link in 2","links":["e4f972f9daad6246","c07b2e101cecbd3b"],"x":75,"y":480,"wires":[["9393c22b2e3c1ec8"]]},{"id":"caf4214602d5f2c9","type":"group","z":"dd95c0bca1101c86","name":"Manually send a spurious value","style":{"label":!0},"nodes":["14097fb7ba3a9ecc","c07b2e101cecbd3b"],"x":34,"y":159,"w":232,"h":82},{"id":"14097fb7ba3a9ecc","type":"inject","z":"dd95c0bca1101c86","g":"caf4214602d5f2c9","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":!1,"onceDelay":0.1,"topic":"","payload":"75","payloadType":"num","x":130,"y":200,"wires":[["c07b2e101cecbd3b"]]},{"id":"c07b2e101cecbd3b","type":"link out","z":"dd95c0bca1101c86","g":"caf4214602d5f2c9","name":"link out 2","mode":"link","links":["33594c64783cdc45","e6bf7b494b48861e"],"x":225,"y":200,"wires":[]}]
```

### 2. Perform simple maths functions using JSONata in Change nodes

You can perform basic maths functions using the Change node and JSONata. Let's say you wanted to take a payload and multiply it by a value. You could use a custom node such as [node-red-contrib-calc](https://flows.nodered.org/node/node-red-contrib-calc){rel="&#x22;nofollow&#x22;"} but you can also easily complete the same task within a change node.

![Using JSONata in a Change node to multiply a payload by 2.5](https://flowfuse.com/blog/2023/03/images/jsonata.png "Using JSONata in a Change node to multiply a payload by 2.5")

This will take the input payload, multiply it by 2.5 then output it as the new payload. You can try this out using the code below.

::render-flow
```json
[{"id":"6bbe9c1e81c4ee39","type":"inject","z":"cfe9fec308e144db","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"2","payloadType":"num","x":350,"y":400,"wires":[["07aa636f3db17775"]]},{"id":"07aa636f3db17775","type":"change","z":"cfe9fec308e144db","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"msg.payload * 2.5","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":520,"y":440,"wires":[["8bde558e6e2f8551"]]},{"id":"8bde558e6e2f8551","type":"debug","z":"cfe9fec308e144db","name":"debug 26","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":680,"y":440,"wires":[]},{"id":"1c04633997beb150","type":"inject","z":"cfe9fec308e144db","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"3","payloadType":"num","x":350,"y":440,"wires":[["07aa636f3db17775"]]},{"id":"bc52c3d2f38115b1","type":"inject","z":"cfe9fec308e144db","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"4","payloadType":"num","x":350,"y":480,"wires":[["07aa636f3db17775"]]}]
```
::

### 3. Use the Catch node to trigger flows on errors

Sometimes you might be working with nodes which don't output anything when they error or maybe output text directly to debug. This makes it difficult for you to run flows when something fails. For example, when using the Read File node, where the expected file is not found, it would be useful to be able to run a specific flow which sends an alert.

You can do this using the Catch node. Drop the node onto your workspace then select if you want errors from some or all nodes. For this example I am going to select just the Read File node. If I then rerun the flow I get an error message out of the Catch node every time there is an error with reading the file.

:video{ariaLabel="Catching an error from the Read File node and outputting a message to debug" autoPlay="true" height="234" loop="true" muted="true" playsInline="true" preload="none" width="836"}

Note that there are no wires connecting the flow to the error output. This means you can have a single Catch node monitoring a whole project and logging errors as well as sending alerts as needed. You can import the flows from this example using the code below.

::render-flow
```json
[{"id":"d6399c6fddb572ef","type":"debug","z":"0c6a2ba248b5933f","name":"debug 28","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1100,"y":300,"wires":[]},{"id":"de70fda720070c57","type":"inject","z":"0c6a2ba248b5933f","name":"","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":790,"y":260,"wires":[["a18f9c8638c78e57"]]},{"id":"a18f9c8638c78e57","type":"file in","z":"0c6a2ba248b5933f","name":"","filename":"example.txt","filenameType":"str","format":"utf8","chunk":false,"sendError":false,"encoding":"none","allProps":false,"x":930,"y":260,"wires":[[]]},{"id":"2dbb0cc4bc10d0bc","type":"catch","z":"0c6a2ba248b5933f","name":"","scope":["a18f9c8638c78e57"],"uncaught":false,"x":790,"y":300,"wires":[["b22988df6357a52a"]]},{"id":"b22988df6357a52a","type":"change","z":"0c6a2ba248b5933f","name":"Debug message","rules":[{"t":"set","p":"payload","pt":"msg","to":"There was an error reading the file","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":940,"y":300,"wires":[["d6399c6fddb572ef"]]}]
```
::

We hope you found these tips useful, if you'd like to suggest some of your own tips which you think we should share in our future blog posts please [get in touch](mailto\:contact@flowfuse.com).

### Simplifying Multi-Instance Communication with FlowFuse Project Nodes

Coordinating communication between multiple Node-RED instances can be challenging, but FlowFuse's [Project Nodes](https://flowfuse.com/docs/user/projectnodes/) make it effortless. With these nodes, you can seamlessly send messages between instances without dealing with complicated network configurations.

Simply choose the target instance by name, and FlowFuse handles the connection automatically. This streamlines the management of multi-instance environments, ensuring smooth communication between flows across different devices or locations. Whether you're handling multiple projects or managing large-scale systems, FlowFuse Project Nodes help you save time and minimize errors.

FlowFuse continues to push the boundaries of collaboration and scalability in Node-RED projects. For more details on these features, visit the [FlowFuse website](https://flowfuse.com).


# Node-RED Tips - Importing, Exporting, and Grouping Flows

There is usually more than one way to complete a given task in software, and Node-RED is no exception. In each of this series of blog posts, we are going to share three useful tips to save yourself time when working on your flows.

### 1. Copy and share your flows using Export and Import

Node-RED provides both import and export features that allow you to save your flows and settings as compressed JSON files. You can use these features to easily move your flows between multiple Node-RED instances or to back up your work.

To import a flow, follow these steps:

1. Click on the three horizontal lines in the upper right corner of the Node-RED editor and click on "Import".
2. Select the JSON file that contains the flow you want to import.
3. Click on "Import" and the flow will be imported into the current instance of Node-RED.

To export a flow, follow these steps:

1. Click on the three horizontal lines in the upper right corner of the Node-RED editor and click on "Export".
2. Select the type of export you want to perform - this can be either the "Clipboard" or "File".
3. If you chose "File" you will be prompted to save a compressed JSON file to your computer; if you chose "Clipboard" the flow JSON will be copied to your clipboard.
4. Use the exported file or clipboard content to import into a different instance of Node-RED.

:video{ariaLabel="Importing and exporting your flows" autoPlay="true" height="474" loop="true" muted="true" playsInline="true" preload="none" width="978"}

Keep in mind that some nodes or flows may require additional setup or node installation on the Node-RED instance you import your flow to.

### 2. Import helpful example flows provided with custom nodes

In Node-RED, custom nodes can include examples that provide users with a starting point for using the node. These examples can help users understand how a node works and how it can be integrated into their flows.

To use example flows in custom nodes, follow these steps:

1. Open the Node-RED editor and drag the custom node you want to use into your flow.
2. Double-click on the node to open its configuration panel.
3. Look for an "Examples" menu or button within the node configuration panel. The name and location of the Examples button can vary depending on the node.
4. Click on the "Examples" button to bring up a list of example flows included with the node.
5. Select the example flow you want to use and click on "Import" to add the example flow to your Node-RED workspace.

Once the example flow has been added to your workspace, you can modify it to fit your specific needs.

:video{ariaLabel="Using the example flow included in the moment node" autoPlay="true" height="474" loop="true" muted="true" playsInline="true" preload="none" width="978"}

It's important to note that while custom node examples can be a useful starting point, they may not always work seamlessly with your other flows or nodes. Be sure to thoroughly test any custom node examples before incorporating them into a production environment.

### 3. Group nodes together to make your flows easier to read

The group feature in Node-RED allows users to visually group nodes together within the workspace. This feature offers several benefits:

1. Improved organization: The group feature allows you to group related nodes visually, which can make your flow easier to understand and navigate. This can be particularly helpful for larger, more complex flows.
2. Simplified editing: When you group nodes together, you can edit or move them as a single unit, rather than individually. This can save time and reduce the chance of errors.
3. Easier sharing: When you share your flow with others, the group feature allows you to package related nodes together, making it easier for others to understand and use your flow.
4. Reduced clutter: Grouping nodes can help reduce the visual clutter in your workspace, making it easier to focus on key aspects of your flow.

:video{ariaLabel="Grouping your nodes to make them easier to read" autoPlay="true" height="474" loop="true" muted="true" playsInline="true" preload="none" width="978"}

Overall, the group feature in Node-RED is a valuable tool that can help users better organise, edit, and share their flows.

We hope you found these tips useful, if you'd like to suggest some of your own tips which you think we should share in our future blog posts please [get in touch](mailto\:contact@flowfuse.com).

You can read our previous Node-RED tips here.

[Node-RED Tips - Smooth, Catch, and Math](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-4/):br[Node-RED Tips - Exec, Filter, and Debug](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-3/):br[Node-RED Tips - Deploying, Debugging, and Delaying](https://flowfuse.com/blog/2023/02/3-quick-node-red-tips-2/):br[Node-RED Tips - Wiring Shortcuts](https://flowfuse.com/blog/2023/02/3-quick-node-red-tips-1/)

## Version Control and Collaboration for Your Node-RED Flows

[FlowFuse](https://flowfuse.com) simplifies managing and collaborating on your Node-RED flows with seamless version control. You can easily track changes, take snapshots, and revert to previous versions, ensuring your work is always safe and recoverable.

With FlowFuse [Team Library](https://flowfuse.com/docs/user/shared-library/#shared-team-library), sharing flows across different Node-RED instances is effortless. This Library feature allows you to organize and share flows among team members without the need for manual copying, making collaboration more efficient and effective.

**[Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} for a free trial today and discover how FlowFuse can enhance your Node**\*


# Community News March 2023

Welcome to the FlowFuse newsletter for March 2023, a monthly roundup of what’s been happening with both FlowFuse and the wider Node-RED community.

## Upcoming events

### Node-RED Ask Me Anything

Back by popular demand, FlowFuse is hosting a monthly Node-RED Ask Me Anything session on March 9th. This is a great opportunity to ask Nick O’Leary, co-creator of Node-RED & FlowFuse CTO, and Rob Marcer, Node-RED FlowFuse Developer Educator your questions about Node-RED.

### DevOps for Node-RED: An Introduction to FlowFuse Webinar

Join Nick O'Leary, FlowFuse CTO, as he presents an Introduction to FlowFuse and demonstrates FlowFuse’s platform for providing DevOps for Node-RED. This webinar will be on March 30th. [Register today](https://flowfuse.com/webinars/2023/introduction-to-flowforge/).

## From our Blog

[Toward Highly Available Node-RED](https://flowfuse.com/blog/2023/02/highly-available-node-red/) - High availability is an often requested feature for Node-RED. This post from FlowFuse CEO discusses our approach to HA for Node-RED.

[MING Stack for IoT](https://flowfuse.com/blog/2023/02/ming-blog/) - MING technology stack include M (Mosquitto/MQTT), InfluxDB, Node-RED and Grafana. Ian Skerrett, FlowFuse Head of Marketing discusses how this tech stack is used for IoT.

[Introduction to Node-RED](https://www.youtube.com/watch?v=47EvfmJji-k){rel="&#x22;nofollow&#x22;"} - An in-depth webinar recording on key Node-RED concepts and demonstration on how to get started with Node-RED.

Node-RED Quick Tips - Rob Marcer, FlowFuse Developer Educator has a weekly series of Node-RED hints and tips

- [Tips #1](https://flowfuse.com/blog/2023/02/3-quick-node-red-tips-1/)
- [Tips #2](https://flowfuse.com/blog/2023/02/3-quick-node-red-tips-2/)

## From the Community

### Node-RED Community Survey

The Node-RED open source project is running an Node-RED Community Survey. Give your [feedback on how you are using Node-RED](https://nodered.org/blog/2023/02/23/community-survey){rel="&#x22;nofollow&#x22;"}.

### Good alternatives to Pis for your next project

Raspberry Pis continue to be difficult to purchase. Eben Upton of the Raspberry Pi Foundation has said that [supply should improve this year](https://www.raspberrypi.com/news/supply-chain-update-its-good-news/){rel="&#x22;nofollow&#x22;"} but in the mean-time there are some good alternatives you could consider. The Youtube channel [ExplainingComputers](https://www.youtube.com/@ExplainingComputers){rel="&#x22;nofollow&#x22;"} has shared a [great video covering some of the most popular SBCs](https://www.youtube.com/watch?v=k8clrUclPIs){rel="&#x22;nofollow&#x22;"} you could use for your next project, it’s worth a watch.

### Custom Node Spotlight - node-red-contrib-os

[OS](https://flows.nodered.org/node/node-red-contrib-os){rel="&#x22;nofollow&#x22;"} is a great custom node which allows you to monitor the performance of the device you are running Node-RED on. It can check RAM usage, disk space, CPU load, and a lot more. It’s really easy to use, we recommend you [take a look](https://flows.nodered.org/node/node-red-contrib-os){rel="&#x22;nofollow&#x22;"}.

## Join Our Team

FlowFuse is expanding our team. We have two openings right now:

- **[Developer Advocate - Manufacturing & Industrial Automation](https://boards.greenhouse.io/flowfuse/jobs/4798023004){rel="&#x22;nofollow&#x22;"}**
- **[DevOps Engineer](https://boards.greenhouse.io/flowfuse/jobs/4796271004){rel="&#x22;nofollow&#x22;"}**


# Comparing Node-RED Dashboards Solutions

Dashboards are a great feature of Node-RED, allowing you to easily expose data visualisations and interactive elements of your flows to users via a web browser. I often see discussions in the community about which dashboard option is best for any given scenario, I wanted to compare the most popular options as they stand in early 2023.

::div{.blog-update-notes}
**UPDATE:** Since this article was published, it's worth noting a couple of important updates:

- FlexDash is no longer maintained and supported.
- [Node-RED Dashboard 2.0](https://dashboard.flowfuse.com) has been released, which is a new, modern dashboard stack for Node-RED, and offers all of the benefits of the original "Node-RED Dashboard", plus more.
::

## Which dashboards am I going to consider?

Based on their downloads per week and active development, I believe there are 3 main dashboards worth considering. In no particular order, they are [Dashboard](https://flows.nodered.org/node/node-red-dashboard){rel="&#x22;nofollow&#x22;"}, [uibuilder](https://flows.nodered.org/node/node-red-contrib-uibuilder){rel="&#x22;nofollow&#x22;"}, and [FlexDash](https://flows.nodered.org/node/@flexdash/node-red-fd-corewidgets){rel="&#x22;nofollow&#x22;"}.

It's not to say that there are not other options, I am focusing on the dashboards I believe are popular in the Node-RED community.

I'd like to take this opportunity to thank the project leads for each of the three dashboards for responding to me and providing their take on the current state and future development of each. Where possible I have quoted their words, either from their messages to me or from the projects' documentation. Thanks to [Dave](https://github.com/dceejay){rel="&#x22;nofollow&#x22;"}, [Julian](https://github.com/TotallyInformation){rel="&#x22;nofollow&#x22;"}, and [Thorsten](https://github.com/tve){rel="&#x22;nofollow&#x22;"} for their replies as well as all the work they've put into these great projects!

## Methodology

To compare these dashboards, I am going to consider each of them based on the following factors:

- How easy is it to install?
- How easy is it to get your first demo dashboard running?
- How extensive is the collection of UI elements?
- How good is the support and documentation?
- How 'cloud native' is the dashboard?
- How active is each project's development?
- What are the future development plans?

I am assuming the user is a low-code developer. They may have limited experience with coding and are most comfortable working in visual interfaces.

So, that's the methodology, let's get on with looking at the strengths of each project.

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

## How easy is it to install?

### uibuilder - 1st place

A search on Google for uibuilder returns the correct custom node. When searching for the custom node in the palette manager there is only one result, this is great as users are very likely to install what they were searching for. Once you've found the correct custom node, the installation takes just a few moments using the palette manager.

### Dashboard - 2nd place

As Dashboard is currently the most popular solution to build dashboards in Node-RED, it's very easy to find both in search engines and in the Node-RED interface. A Google search brings up the correct custom node. Finding this custom node in Node-RED's palette manager is not quite as easy, at the time of writing it's the third from top result for the search term 'dashboard'. Some users might not select the intended item from the palette manager on first attempt. However, once you have found the correct custom node, installation is easy and takes just a few moments.

### FlexDash - 3rd place

When searching for 'FlexDash node red' on Google, the top result is the Node-RED website for the custom node. The issue with this, and this is also a problem when searching in the palette manager, is the project 'FlexDash' is apparently not what we actually need to install. When reading the readme for the project on Github it says &#x2A;'You most likely do not want to explicitly install this package, you want to install the [core widgets](https://github.com/flexdash/node-red-fd-corewidgets){rel="&#x22;nofollow&#x22;"}, which will bring in this package and more and will provide a usable whole'.*

Credit to the developers for adding in this helpful text but I suspect most users will start off by installing FlexDash then later discover that was not the correct way to proceed. It would be great if the custom node which needs to be installed was the one called 'FlexDash' in my opinion.

This problem is compounded by there being no help file at all for 'FlexDash' showing up on the Node-RED web site. That may well be a deliberate attempt to help users get the right custom node installed, but it was still a confusing start for me and I suspect other users will have a similar experience.

When setting up FlexDash, one thing that wasn't immediately obvious was that I needed to restart Node-RED before the custom node showed in the palette. This step is [covered in the docs](https://flexdash.github.io/docs/quick-start/#installing-flexdash-in-node-red){rel="&#x22;nofollow&#x22;"} but I suspect a lot of users will get stuck working out why the palette manager says the custom node is installed but nothing new has been added to the palette.

There is also an [ongoing discussion](https://github.com/node-red/node-red/issues/569){rel="&#x22;nofollow&#x22;"} about a way to resolve issue by changing how Node-RED deals with dependencies which sounds promising.

I believe a few improvements to the install process could make FlexDash a much more popular custom node.

## How easy is it to get your first demo dashboard running?

### FlexDash - 1st place

Getting an example dashboard up and running in FlexDash is very easy thanks to the example flows which are included in the package. Simply go to 'Import', 'Examples' then select 'Hello-world' from the example flows. Now deploy and add /flexdash to the end of the URL of your Node-RED editor and you should have your first dashboard running.

### uibuilder - 2nd place

It was quite simple to get an example dashboard up and running in uibuilder. As with FlexDash, there are examples you can import. Once we import an example we do start to see the significantly different approach to delivering dashboards with uibuilder to the other two solutions. The examples seem to demonstrate how you could build a dashboard rather than showing specific UI elements such as charts in use.

### Dashboard - 3rd place

Getting your first dashboard running in Dashboard is quite easy, once installed you need to drag in a Dashboard UI element then assign that to a UI group and tab. The group and tab can be left as their default options (home) which I suspect most users will work out quickly.

You then need to deploy your flow and visit the dashboard using '/ui' on the end of the URL of your Node-RED editor and you are up and running.

Dashboard would benefit from some example flows as we see with the other two custom nodes.

## How extensive is the collection of UI elements?

### FlexDash and Dashboard - joint 1st place

It's really hard to separate these two, when considering the UI elements they come with. They both have out of the box solutions for charts, gauges, buttons, drop downs, toggles, text etc. I think they both deserve 1st place in this category.

### uibuilder - 3rd place

This is possibly a little unfair on uibuilder. Arguably by design, uibuilder does not currently include many UI elements. To add most useful elements (charts, gauges etc) to your dashboard, you will need to set out your design in HTML or look at using one of the supported frontend frameworks. This makes uibuilder more versatile for users who are comfortable using code to set out dashboards but for the low-coders among us it's less ideal.

## How good is the support and documentation?

### All three - joint first place

All three projects have an active community and good support documentation. Where as I may have a personal preference about how I like documentation to be set out, I don't think that makes any one project better than the rest.

## How 'cloud native' is the dashboard?

In the words of the [Cloud Native Computing Foundation](https://www.cncf.io/){rel="&#x22;nofollow&#x22;"} '*Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach*'.

'*These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil*'.

So, how well does each project conform to these ideals?

### Dashboard - 1st place

Dashboard stores all configuration data within the Node-RED instance. When deploying an existing Node-RED project to a new instance everything just works exactly as it did previously.

### FlexDash - 2nd place

As with Dashboard, everything required to define each dashboard is stored within Node-RED. This makes redeployment trivial. Unfortunately, as the Node-RED instance currently needs to be restarted before FlexDash works, it just missed out on joint first place. It would be great to see that issue resolved in future versions. There is also an [ongoing discussion](https://github.com/node-red/node-red/issues/569){rel="&#x22;nofollow&#x22;"} about a way to resolve issue by changing how Node-RED deals with dependencies.

### uibuilder - 3rd place

uibuilder uses the filesystem of the host instance to store its configuration. In practice this means that if you migrate the Node-RED project files to a new location you probably will find your dashboard no longer works. This can be mitigated by also migrating the filesystem (for example using persistent storage in Docker) and re-deploying via a Docker registry but it would be great to see uibuilder move towards not being dependant on the filesystem as it will make DevOps tasks that much easier.

## How active is each project's development?

### uibuilder - 1st place

![Image showing the uibuilder Github Commits](https://flowfuse.com/blog/2023/03/images/uibuilder-activity.png "Image showing the uibuilder Github Commits")

uibuilder has has consistent commits to the project going back several years with even greater activity since the start of 2022.

### FlexDash - 2nd place

![Image showing the FlexDash Github Commits](https://flowfuse.com/blog/2023/03/images/flexdash-activity.png "Image showing the FlexDash Github Commits")

The commits to FlexDash have been regular since mid 2022.

### Dashboard - 3rd place

![Image showing the Dashboard Github Commits](https://flowfuse.com/blog/2023/03/images/dashboard-activity.png "Image showing the Dashboard Github Commits")

Dashboard is now in a a maintenance only state. In the words of the project lead, &#x2A;'Angular 1 (the framework used to build Dashboard) is now unsupported and it's just a matter of time before there is a serious security hole raised against it, for which there will be no fix. Of course we don't use all the features of it so we may be lucky that an exploit doesn't necessarily expose us directly but it will compromise any audits people may wish to do'*.

In practice, this means that sooner or later using Dashboard might become a significant security risk.

## What are the future development plans?

### uibuilder - joint firstplace

During the writing of this article, uibuilder released a new version with some significant new features. In the words of the project lead when talking about version 6.1.0, '*It feels like uibuilder really is growing up. No more apologising for not being a direct Node-RED Dashboard replacement, uibuilder has its own path*.

*You can now create and update visible web page elements direct from Node-RED data without needing to understand all of the intricacies and inconsistencies of HTML. You can create your own utility tools either in Node-RED or in front-end code that leverages the low-code UI features of uibuilder*'.

It's great to see projects under active development. My greatest difficulty when using uibuilder, is I found it hard to create the UI elements I needed based on low-code workflows. According to the [development roadmap for uibuilder](https://totallyinformation.github.io/node-red-contrib-uibuilder/#/roadmap){rel="&#x22;nofollow&#x22;"} the project should progress towards being easier and easier for low-coders to make use of.

To again quote the project lead, '*In general, the ongoing direction of travel is to enable more zero-code features that will work both in Node-RED flows and in front-end custom code. The low-code feature set is already quite mature now and is well documented enough that it can be used by other tools should anyone wish to do so. I will be making sure that both the zero-code and low-code features are as easy to use as possible both from Node-RED and front-end code for maximum flexibility*'.

### FlexDash - joint firstplace

The project Lead for FlexDash had the following to say about the future development of the project. '*FlexDash currently has a fairly rigid overall page structure: there's a tab bar and each tab's content is organized in grids of widgets. The plan is to open this up fully so the user can start from a blank page and place containers which contain widgets. This way almost any layout could be implemented in FlexDash*'.

'*I also would like to improve the multi-user capabilities of FlexDash by supporting authentication and making it easier for users to implement flows that present per-user data in the dashboard*'.

After using FlexDash over the past couple of weeks and finding it to be already be a strong contender for all my Node-RED dashboard needs, it's great to see it continuing to be improved.

### Dashboard - third place

***Important Update: New Generation of Node-RED Dashboard Released:*** &#x2A;A new generation of the outdated and unmaintained Node-RED Dashboard has been released to replace it. Introducing [Node-RED Dashboard 2.0](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"}, built on Vue.js, offering significantly more versatility than its predecessor. This new dashboard, managed by FlowFuse, is designed to allow full customization, addressing the limitations of the previous version.*

\*Node-RED Dashboard 2.0 retains most of the widgets and concepts from the old version, so transitioning from Node-RED Dashboard 1.0 to 2.0 is easy. For a full feature comparison you can check out the [Migration Guide](https://dashboard.flowfuse.com/user/migration.html){rel="&#x22;nofollow&#x22;"}.

Dashboard 2.0 includes various chart types such as line, scatter, bar, gauge, and more, and it's compatible with all the [Vuetify component library](https://vuetifyjs.com/en/components/all/#containment){rel="&#x22;nofollow&#x22;"}, making it easier to build advanced dashboards.\*

*Furthermore, the team is continuously working on adding more amazing features to enhance the user experience. For a smooth transition, FlowFuse provides easy-to-follow guides. Refer to [Node-RED Dashboard 2.0 Guides](https://flowfuse.com/blog/dashboard/) for more information.*

As mentioned above, Dashboard is no longer in active development. This is due to the framework upon which it was build [(AngularJS)](https://angularjs.org/){rel="&#x22;nofollow&#x22;"} now being unsupported as of the end of 2021. You can read a lot more detail on why ongoing development of Dashboard is not practical in this [thread on the Node-RED forums](https://discourse.nodered.org/t/discussion-about-a-new-dashboard/51119/3){rel="&#x22;nofollow&#x22;"}.

There could possibly be new effort put into porting Dashboard over to a new framework but that is a significant amount of work. I suspect it would take hundreds of hours development just to get the feature set back to the same state as the current version so I suspect it won't ever happen.

## Conclusions

Personally, I was a little surprised by these results. I have used Dashboard for around 3 years and always found it to be a great tool for putting together quick and informative dashboards. That being said, when attempting to objectively compare it to uibuilder and FlexDash, the other two projects often are individually better in a given category. That coupled with the halt of development for Dashboard due to AngularJS being no longer supported, it's hard to recommend Dashboard for totally new Node-RED users in 2023, especially for commercial projects.

If you already use Dashboard, in a non-commercial setting you should probably continue to do so, you might find that its development slows down to a near stall due to the underlying framework now being abandoned but for at least as of right now it's a great solution to build your Node-RED dashboards in.

FlexDash is probably the best low-code solution for building dashboards in Node-RED. If you don't get blocked by the confusing install process I believe it's the one to pick up at the time of writing due to it's ongoing support and low-code interface.

uibuilder is currently not what I would consider a truly low-code option for creating dashboards but it is moving in that direction. It has some great features and is extremely flexible so it has a good chance of ending up as the most popular solution to build dashboards in Node-RED in the long term. That being said, as of time of writing unless you are a 'coder' you will may struggle to build a dashboard using it.


# FlowFuse v1.5 Now Available

For FlowFuse 1.5 we have been busy making a lot of UX changes and upgrading our underlying architecture to enable future innovations on the FlowFuse platform.

With our recently announced [Terminology Changes](https://flowfuse.com/blog/2023/03/terminology-changes/), we have introduced some new concepts into FlowFuse.

- **Application**: A group of Node-RED Instances Each instance can run locally (in FlowFuse) or remotely (on Devices)
- **Instances**: We renamed "Projects" to "Instances" to be more inline with the terminology used in the Node-RED community

As such, our User Experience has been updated to reflect these changes, and allow for further functionality to be introduced with our plans for [Multiple Instances per Application](https://github.com/FlowFuse/flowfuse/issues/1689){rel="&#x22;nofollow&#x22;"}.

### "Applications" View

At the top-level in FlowFuse, you can now see a list of your "Appications". In FlowFuse 1.5, as we still have a 1:1 relationship of Applications to Local Instances, this will be the same as the list of "Projects" that you're used to seeing.

!\[Screenshot to show the new "Applications" view]\(./images/screenshot-applications.png "Screenshot to show the new "Applications" view")

**"Applications" view in FlowFuse, listing all available Applications**

For 1.5, all of your settings, environment variables, etc. are all now at the "Instance" level. Applications will gain a lot more functionality in future releases.

### "Instances" View

When clicking on one of your Applications, you will see a list of Node-RED instances bound to that Application.

!\[Screenshot to show the new "Instances" view]\(./images/screenshot-instances.png "Screenshot to show the new "Instances" view")

**A list of Instances contained within a single Application.**

Clicking on this Instance, will open up the "Instance" view, this is an exact replica of the "Project" view you'll be used to seeing in FlowFuse, and contains all of the same functionality:

!\[Screenshot to show the new "Instances" view]\(./images/screenshot-instance.png "Screenshot to show the new "Instances" view")

**FlowFuse 1.5's "Instance" view. This contains all of the functionality previously found in the "Project" view.**

### Devices & Managing Remote Instances

Devices are now bound to "Instances", you'll see these in the "Devices" view, and can be managed and deployed to in exactly the same way as before. Devices will run whatever you've selected as your "Target Snapshot" for this Instance.

!["Screenshot to show an Instance's 'Devices' view"](https://flowfuse.com/blog/2023/03/images/screenshot-devices.png "Screenshot to show an Instance's 'Devices' view")

**"Devices" view, available for a given Node-RED Instance. This lists all of the connected devices to a given instance, that will automatically update when a new Target Snapshot is set.**

## Node-RED 3.1 Beta Available

FlowFuse Cloud is a great place to try out the new Node-RED features, with FlowFuse Cloud now including the [Node-RED 3.1.0-beta.2](https://discourse.nodered.org/t/node-red-3-1-0-beta-2-released/76192){rel="&#x22;nofollow&#x22;"}. If you want to try this version you can [duplicate your application](https://flowfuse.com/docs/user/instance-settings/#copy-instance) or [upgrade your stack](https://flowfuse.com/docs/user/changestack/).

## Other Improvements

- Update to audit logs to improve usability \[[#1800](https://github.com/FlowFuse/flowfuse/issues/1800){rel="&#x22;nofollow&#x22;"}] \[[#1785](https://github.com/FlowFuse/flowfuse/issues/1785){rel="&#x22;nofollow&#x22;"}]
- Improve how licensing works with overages, for easier scaling of FlowFuse and your Node-RED Instances \[[#1639](https://github.com/FlowFuse/flowfuse/issues/1639){rel="&#x22;nofollow&#x22;"}] \[[#1739](https://github.com/FlowFuse/flowfuse/issues/1739){rel="&#x22;nofollow&#x22;"}]

## Bug Fixes

- Device "Last Seen" status shows "never" even though it has previously been seen \[[#1723](https://github.com/FlowFuse/flowfuse/issues/1723){rel="&#x22;nofollow&#x22;"}]
- Improved Safe Mode launch for small projects \[[#1579](https://github.com/FlowFuse/flowfuse/issues/1579){rel="&#x22;nofollow&#x22;"}]

## Try it out

We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.5.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there.

If you hit any problems with the platform please raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That's also a great place to send us any feedback or feature requests.

You can also get help on [the Node-RED forums](https://discourse.nodered.org/){rel="&#x22;nofollow&#x22;"}

As well as in the [forum within our Github project](https://github.com/FlowFuse/flowfuse/discussions){rel="&#x22;nofollow&#x22;"}

Chat with us on the `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}

You can raise a support ticket by emailing <support@flowfuse.com>

We've also added a live chat widget to our website, you can access it using the icon on the bottom right corner of our website. We'd love to hear from you.


# IBM Cloud removes Node-RED starter application

IBM Cloud has [recently announced](https://www.ibm.com/cloud/blog/announcements/deprecation-of-ibm-cloud-starter-kits){rel="&#x22;nofollow&#x22;"} that they will no longer be providing their Cloud App Service Starter Kits, including the [Node-RED Starter Application](https://developer.ibm.com/tutorials/how-to-create-a-node-red-starter-application/){rel="&#x22;nofollow&#x22;"}.

## Node-RED Starter Application

If you're looking for an alternative place to get started with Node-RED then FlowFuse, founded by Node-RED co-creator Nick O'Leary, are here to help you with Cloud-hosted Node-RED as well as infrastructure and tooling to scale your Node-RED instances in production.

As an ex-IBM Employee myself, over the years, I've been very dependant upon the Node-RED Starter Application in IBM Cloud. I'd used it dozens of times with clients to showcase the value of Node-RED and how easy it is to spin up integrations between hardware devices, APIs and online services.

If you're now looking for somewhere to rely on in order to easily spin up new instance of Node-RED, then FlowFuse is the obvious answer. If you're completely new for Node-RED too, we can also help you there with our [Getting Started](https://flowfuse.com/blog/2023/01/getting-started-with-node-red/) guide.

You can sign up for a [free FlowFuse Cloud Account](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} where you'll be given one small Node-RED instance for free, for your first month.

## Integrations

If you've seen the excellent ["Create a Node-RED starter application"](https://developer.ibm.com/tutorials/how-to-create-a-node-red-starter-application/){rel="&#x22;nofollow&#x22;"} article on IBM Developer, you'll probably be looking to connect up to a Cloudant Instance, or other IBM Cloud Services. Don't worry. All of that is still available through Node-RED on FlowFuse.

You can install the relevant nodes in one of two places:

1. **Node-RED Palette Manager:** Click "Menu > Manage Palette > Install". The menu is available via the icon in the top-right of your running Node-RED Instance)

![Screenshot of Node-RED's Manage Palette menu](https://flowfuse.com/blog/2023/03/images/nr-manage-palette-cloudant.png "Screenshot of Node-RED's Manage Palette menu")

2. **FlowFuse Instance Settings:** For a given Instance in FlowFuse, click "Settings > Palette". You can then define the npm module name and versions explicitely in the "Installed Modules" section

![Screenshot of FlowFuse's "Installed Modules" option in Instance > Settings > Palette](https://flowfuse.com/blog/2023/03/images/ff-installed-modules.png "Screenshot of FlowFuse's 'Installed Modules' option in Instance > Settings > Palette")

It's also easy to setup [Environment Variables](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/) for Node-RED in FlowFuse for when you integrate with external services like APIs too.

## Security

As with IBM Cloud, FlowFuse makes it very easy to secure your Node-RED Applications. [FlowFuse offers three tiers of security](https://flowfuse.com/docs/user/instance-settings/#security) options on your Node-RED Instances to secure any exposed HTTP routes on your Node-RED instance, e.g. REST API endpoints or Node-RED Dashboard.

- **None**: Anyone will be able to access the exposed routes.
- **Basic Auth**: Setup a single, dedicated username and password combination that is required in order to access the routes.
- **FlowFuse Credentials**: Visitors can use their FlowFuse username/password in order to access the endpoints. This also includes SSO if you have that configured for your FlowFoerge Team.

## Migrating Existing Instances

If you're looking to move your Node-RED applications from IBM Cloud, then you can do so through one of two options:

### Node-RED Tools Plugin

You can use our Node-RED Tools plugin to migrate your flows and credentials over to FlowFuse. You can read the details in our [Migration Guide](https://flowfuse.com/docs/migration/introduction/), which also includes instructions on how to export your environment variables too.

### Manual Import

This will only enable you to import your Flows, not the associated credentials.

1. Export your existing `flows.json` from your IBM Cloud-hosted Node-RED instance by choosing "Export > All Flows > Download" within Node-RED
2. Create a new Application on FlowFuse
3. Once created, click the Node-RED instance that has been generated within your Application
4. Click "Settings"
5. Scroll down and select the "Import Instance" option
6. Choose your `flows.json` file that you downloaded earlier.

*If you have any questions about the above, or more generally about Node-RED or FlowFuse, then please do reach out and [get in touch](https://flowfuse.com/contact-us).*


# Node-RED: The Integration Platform for IIoT Edge Computing & PLCs

Node-RED has become a widely adopted integration platform for IoT edge computing and PLCs. Discover why!

## The Integration Platform for IIoT Edge Computing & PLCs

Node-RED is a widely adopted open-source low-code development tool that makes it easy to connect and integrate different sources of data. With a visual programming interface and drag-and-drop functionality, [Node-RED](https://flowfuse.com/node-red/) makes it possible for software developers and non-professional software developers to create sophisticated applications.

In the manufacturing and industrial automation industry, the focus of the Industrial Internet of Things (IIoT) has been on integrating industrial processes and equipment to enable real-time monitoring, control, and analysis of data. For many use cases, instead of sending all the data to the cloud, the best practice for processing industrial data is to deploy the application to the edge of the network, referred to as edge computing. By processing the data closer to the data source, edge computing has many benefits, including reduced latency, limited downtime, conserving bandwidth, and increased privacy, and security.

## How Node-RED fits into IIoT Edge Computing

A key challenge for IIoT edge computing is the wide variety of different hardware platforms, protocols and sources of data and processes. Over the years, the Node-RED community has built [thousands of nodes and flow](https://flows.nodered.org/){rel="&#x22;nofollow&#x22;"}s to support a wider range of these sources of data, including support for [Modbus](https://flows.nodered.org/node/node-red-contrib-modbus){rel="&#x22;nofollow&#x22;"}, [OPC-UA](https://flows.nodered.org/node/node-red-contrib-opcua){rel="&#x22;nofollow&#x22;"}, [S7](https://flows.nodered.org/node/node-red-contrib-s7){rel="&#x22;nofollow&#x22;"}, [MQTT](https://cookbook.nodered.org/mqtt/){rel="&#x22;nofollow&#x22;"}, etc. Node-RED also has nodes for graphics and dashboards to make it trivial to visualize industrial data.

Node-RED’s visual programming environment makes it accessible to non-developers. Manufacturing, mechanical, and electrical engineers in the factories are typically the domain experts in understanding the existing systems and often lead IIoT initiatives. Node-RED enables these engineers to quickly innovate and create real value for their organizations. This makes it a popular choice for engineers looking to create edge computing solutions.

## PLC and IoT Gateway Vendors Embrace Node-RED

PLC and IoT Gateway vendors are at the forefront of promoting edge computing. They see edge computing as a way to modernize hardware in the factory and for remote asset management. PLC and IoT gateways often sit in front of old legacy systems that don’t have the connectivity or compute platform to enable IIoT applications.

Many of these hardware vendors realized they need an application delivery platform for their devices. Traditional OT hardware vendors often implement proprietary software stacks that are often difficult to use and closed to integrating with other hardware and software. Forward thinking hardware vendors realized having an open platform is the future of their industry and customers have begun to demand more open platforms. Node-RED’s ease of use, open community and open source license provided the solution many of these hardware vendors were looking for.

## The Standard for Edge Computing and PLCs

Today, Node-RED has been adopted by some of the leading PLC and IoT Gateway vendors. The hardware vendor community appears to have standardized on Node-RED as being the edge computing platform for IIoT.

Below is a sample of the vendors offering a Node-RED solution:

1. [Advantech](https://www.advantech.com/en-eu/products/node-red-gateways/sub_fb7246cc-cc10-486f-806b-30bb50a90f28){rel="&#x22;nofollow&#x22;"} Node-RED Field Gateway
2. [Bechhoff](https://infosys.beckhoff.com/english.php?content=../content/1033/tf6720_tc3_iot_data_agent/3260672139.html&id=){rel="&#x22;nofollow&#x22;"} TwinCAT
3. [Bivocom](https://www.bivocom.com/products/iot-gateways/edge-iot-gateway-tg452){rel="&#x22;nofollow&#x22;"} TG452 IoT Edge Gateway
4. [BLIIOT Edge Computing Gateway](https://bliiot.com/products/){rel="&#x22;nofollow&#x22;"} EdgeCom BL302
5. [Bosch CtrlX Core](https://developer.community.boschrexroth.com/t5/Store-and-How-to/ctrlX-CORE-Node-RED-App/ba-p/22366){rel="&#x22;nofollow&#x22;"}
6. [Broadsens](https://www.broadsens.com/wireless-gateway/){rel="&#x22;nofollow&#x22;"} GU200 & GU 200S
7. [Emerson](https://www.emerson.com/documents/automation/product-datasheet-pacedge-software-computing-devices-pacsystems-en-7205588.pdf){rel="&#x22;nofollow&#x22;"} PACEdge
8. [Hilscher Automation](https://github.com/HilscherAutomation/netPI-nodered){rel="&#x22;nofollow&#x22;"}
9. [Opto22](https://developer.opto22.com/nodered/general/){rel="&#x22;nofollow&#x22;"} groov RIO & EPIC
10. [Parallax AV](https://www.parallaxcontrol.com/){rel="&#x22;nofollow&#x22;"} Control System
11. [Particle.io](https://docs.particle.io/reference/cloud-apis/node-red/){rel="&#x22;nofollow&#x22;"} Particle
12. [Pepperl+Fuchs](https://www.pepperl-fuchs.com/usa/en/classid_199.htm?view=productdetails&prodid=93839){rel="&#x22;nofollow&#x22;"} AS-Interface gateway
13. [Raspberry Pi](https://projects.raspberrypi.org/en/projects/getting-started-with-node-red){rel="&#x22;nofollow&#x22;"}
14. [Renesas](https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/mixed-signal-asics/communication-asics/ftclick-mikrobus-compatible-interface-module){rel="&#x22;nofollow&#x22;"} FT Click
15. [Revolution Pi](https://revolutionpi.com/revpi-connect/){rel="&#x22;nofollow&#x22;"} RevPi Connect
16. [Schneider Electric](https://shop.exchange.se.com/en-US/apps/59823/ecostruxure-plant-data-expert/features){rel="&#x22;nofollow&#x22;"} ExoStructure Plant Data Expert
17. [Siemens](https://github.com/SIMATICmeetsLinux/IOT2050-NodeRed-OPCUA-Server){rel="&#x22;nofollow&#x22;"} S7 PLC
18. [ST-One](https://st-one.io/en/){rel="&#x22;nofollow&#x22;"}
19. [Tulip](https://support.tulip.co/docs/using-node-red-with-edge-mc){rel="&#x22;nofollow&#x22;"} Edge MC & Edge IO
20. [Wago](https://www.wago.com/us/edge-devices-overview){rel="&#x22;nofollow&#x22;"} Edge Controller & Computer
21. [Weidmueller](https://catalog.weidmueller.com/procat/Group.jsp;jsessionid=C885C404E7B4B798B23B8A9BB2200513?groupId=\(%22group14048963834797%22\)&page=Group){rel="&#x22;nofollow&#x22;"} control web

There are several key reason Node-RED is so popular for IIoT edge computing, including:

- Easy User-friendly interface that makes it accessible to manufacturing engineers that might not have a lot of programming experience.
- Large community of open source nodes that integrate with many different OT hardware and protocols.
- Open source community and license making it vendor neutral so competing hardware vendors feel comfortable embracing the platform.

## Conclusion

IIoT and edge computing is making software more critical to the manufacturing industry. The flexibility to integrate data from different sources to create innovative data centric solutions is primarily software driven. In partnership with OT hardware vendors, Node-RED’s flexible and easy to use environment provides the platform for manufacturing companies to embrace software to develop IIoT solutions.


# Terminology Changes

As a new product in the market, we constantly have to make choices on how to name things. Naming things is hard! As you name a thing, say "Project", it might be suitable now, but the product evolves, and may outgrow the name such that it doesn’t fit anymore.

We are at this point with FlowFuse, and want to walk you through what we have planned, and why we are changing a couple of things.

### Enter the "Application"

In [FlowFuse 1.5](https://flowfuse.com/blog/2023/03/flowforge-1-5-0-released/), we have introduced a new concept called an **Application**.

An Application will allow you to organize multiple Node-RED instances into a single managed group.

As of the 1.5 release, an Application can still only have a single Node-RED instance, but in future releases, Applications will allow for multiple Node-RED instances and will allow us to implement capabilities such as **DevOps Pipelines** and **High Availability**.

### "Projects" to "Instances"

Until now, 'Project' encapsulated both the Node-RED instance that was running in FlowFuse, and the associated devices (remote instances), settings and environment variables. It was an overloaded term, and it caused confusion with our users.

To simplify things, and to adhere more to the terminology familiar with the Node-RED community, we are renaming Projects to **Instances**.

An **Instance** is a customized version of Node-RED that includes various FlowFuse plugins to integrate it with the FlowFuse platform. It can also be used to manage the environment variables used in your Node-RED flows.

Instances can either be:

- **Local** - An instance of Node-RED running in FlowFuse.
- **Remote** - An instance of Node-RED, managed by FlowFuse, running on a Device.

In future releases, environment variables will also be able to be stored at the Application level, and shared across multiple Node-RED Instances.

### Devices

FlowFuse can also be used to manage remote Node-RED instances. This is typically useful when you have a number of remote devices that are required to run the same Node-RED instance, and may have variation in configuration or environment variables for example.

Devices are registered to an Instance, and can be configured to run [Snapshots](https://flowfuse.com/docs/user/concepts/#snapshot) of the Instance running in FlowFuse.

To accomplish this remote management capability, the [FlowFuse Device Agent](https://github.com/FlowFuse/device-agent){rel="&#x22;nofollow&#x22;"} needs to be installed on each device. Devices are registered with a Team, and then the appropriate device(s) are assigned to a Node-RED instance that should be deployed to the device(s). When the Node-RED instance is ready for deployment, a user creates a snapshot of the instance and marks it as a target snapshot for the device.

We hope these changes will simplify the FlowFuse terminology for our users and allow us to grow the FlowFuse platform. If you have any feedback or thoughts, please do reach out to us.


# The benefits and drawbacks of using Node-RED function nodes

Function nodes are an essential part of Node-RED. They allow you to write custom JavaScript functions that can be used in your Node-RED flows. In this blog post, I will discuss some of the benefits and drawbacks of using Function nodes in your next project.

## 5 Benefits of using Function Nodes:

:video{ariaLabel="Example showing how to use the function node" autoPlay="true" height="394" loop="true" muted="true" playsInline="true" preload="none" width="642"}

1. **Customisation:** Function nodes allow you to write custom JavaScript functions that can be tailored to your specific needs. You can create complex functions that perform a variety of tasks, the only limit is your programming skills.
2. **Reusability:** Function nodes can be reused in multiple flows, saving you time and effort. You can create a library of custom functions that can be easily accessed and reused in different flows.
3. **Debugging:** Function nodes provide an easy way to debug your code. You can use console.log statements to output debug information to the Node-RED debug panel, making it easier to identify and fix issues.
4. **Performance:** Function nodes can be more performant than using multiple nodes to achieve the same result. By combining multiple tasks into a single function, you can improve performance, assuming your code is efficient.
5. **Flexibility:** Function nodes provide a high degree of flexibility. You can use them to perform tasks that are not possible using a single, standard Node-RED node, such as complex data manipulation.

## 5 Benefits of avoiding Function Nodes:

:video{ariaLabel="Example showing how to not use the function node" autoPlay="true" height="394" loop="true" muted="true" playsInline="true" preload="none" width="642"}

1. **Simplicity:** Not using function nodes can make your flows simpler and easier to understand. By using standard Node-RED nodes, you can create flows that are easy to follow and maintain for both you and your team.
2. **Ease of Use:** Standard Node-RED nodes are easy to use and require no programming knowledge. This makes it easier for non-technical users to create and maintain flows.
3. **Modularity:** By using standard Node-RED nodes, you can create modular flows that can be easily modified and extended. This makes it easier to add new functionality to your flows as your needs change.
4. **Community Support:** Standard Node-RED nodes have a large and active community, providing support and resources for users. This can make it easier to find solutions to common problems and share knowledge with others.
5. **Compatibility:** Standard Node-RED nodes are usually compatible with all versions of Node-RED, making it easier to migrate flows between different environments.

## How to Easily Create Function Nodes in FlowFuse

FlowFuse offers a robust platform for building, scaling, and securing your Node-RED applications.

We are constantly adding new features to make it easy to use in the enterprise where you can rapidly improve your industrial processes. The &#x2A;*"FlowFuse Assistant."** for example is an AI-powered tool that simplifies the creation of Function nodes. You only need to provide a prompt, and the assistant generates the Function nodes for you.

For more details on using the FlowFuse Assistant, visit [the Assistants Documentation](https://flowfuse.com/docs/user/expert/).

## Conclusion:

Function nodes are particularly valuable for users who possess JavaScript programming skills. They allow for complex tasks, advanced data manipulation, and integration with external APIs, providing a high level of customization and flexibility. However, they require a good understanding of JavaScript to implement effectively and can be more challenging to manage and debug compared to standard Node-RED nodes.

On the other hand, standard Node-RED nodes offer a simpler and more accessible approach, making it easy for users without programming expertise to create and maintain flows. They are designed for straightforward tasks and provide modularity, benefiting from a supportive community for troubleshooting and knowledge sharing.

Ultimately, the choice between using function nodes and standard nodes will depend on your project's requirements and your familiarity with JavaScript. If you seek deep customization and flexibility, function nodes, enhanced by tools like FlowFuse Assistant, might be the best choice. For those who value simplicity and ease of use, standard Node-RED nodes are a great fit.


# Node-RED Tips - Subflows, Link Nodes, and the Range Node

There is usually more than one way to complete a given task in software, and Node-RED is no exception. In each of this series of blog posts, we are going to share three useful tips to save yourself time when working on your flows.

### 1. Subflows

Subflows are a great way to reuse sections of your flows. Once you have created a subflow, it can easily be dropped into your workspace one or more times.

#### Why use subflows?

Without using a subflow, you can copy and paste a flow into each place you need to use it. This takes up quite a bit of workspace, and makes it harder to update your flow in the future as you'll have to update each copy.

![Duplication of the flow](https://flowfuse.com/blog/2023/04/images/no-subflow.png "Duplication of the flow")

If we instead put the flow into a subflow we'll save a lot of workspace and it will be easier to update the reused sections of the flow if we need to in the future.

#### Creating a subflow

You can create a subflow using the burger menu in the top right corner of Node-RED, select Subflows, then Create Subflow. Lay out your subflow, making sure you create an input and output. You can even have more than one output if you want.

![Contents of the subflow](https://flowfuse.com/blog/2023/04/images/subflow.png "Contents of the subflow")

You can now drop the subflow into your workspace as needed, saving space and making it easier to manage changes to your flow.

![Using the subflow to reduce duplication of flows](https://flowfuse.com/blog/2023/04/images/using-the-subflow.png "Using the subflow to reduce duplication of flows")

### 2. Link Nodes

Link Nodes allow you to separate your flows into distinct sections. The wires between the link nodes are not visible until you select that part of the flow. You can also link flows on different tabs together.

Formatting your flows into distinct sections using link nodes can make it easier to read and update your work.

To use the link node, drag a link in and out node into your flow's workspace. Now draw a wire as you usually would to link to two nodes together. You should see a link between the nodes but it only shows when you have the link nodes selected.

:video{ariaLabel="Linking two link nodes together" autoPlay="true" height="164" loop="true" muted="true" playsInline="true" preload="none" width="532"}

In this example below, the first and second flows have the same nodes and functionality. In the second image of the workspace I've split the flow into specific groups of nodes.

![A flow without link nodes](https://flowfuse.com/blog/2023/04/images/flow-without-link-nodes.png "A flow without link nodes")

It's easier to read and understand the flow once it's split up using the link nodes and groups.

![The same flow as above, now split up using link nodes](https://flowfuse.com/blog/2023/04/images/flow-with-link-nodes.png "The same flow as above, now split up using link nodes")

### 3. Range Node

Sometimes you might need to map one numbering scale onto another. For example, where a user has selected a value between 0 and 10 but you want to use and store their response as a percentage. The Range node makes this task very easy.

![Example of using the range node](https://flowfuse.com/blog/2023/04/images/flow-using-range.png "Example of using the range node")

To configure the node, set it up as follows:

![Configuration of the range node](https://flowfuse.com/blog/2023/04/images/range-config.png "Configuration of the range node")

You should now see that the input values are translated to the appropriate value out of 100.

:video{ariaLabel="The range note in use" autoPlay="true" height="164" loop="true" muted="true" playsInline="true" preload="none" width="534"}

We hope you found these tips useful, if you'd like to suggest some of your own tips which you think we should share in our future blog posts please [get in touch](mailto\:contact@flowfuse.com). You can also read some of our previous Node-RED tips using the links below.

[Node-RED Tips - Importing, Exporting, and Grouping Flows](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-5/):br[Node-RED Tips - Smooth, Catch, and Maths](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-4/):br[Node-RED Tips - Exec, Filter, and Debug](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-3/):br[Node-RED Tips - Deploying, Debugging, and Delaying](https://flowfuse.com/blog/2023/02/3-quick-node-red-tips-2/):br[Node-RED Tips - Wiring Shortcuts](https://flowfuse.com/blog/2023/02/3-quick-node-red-tips-1/)


# Community News April 2023

Welcome to the FlowFuse newsletter for April 2023, a monthly roundup of what’s been happening with both FlowFuse and the wider Node-RED community.

## Upcoming events

### Node-RED Ask Me Anything

Back by popular demand, FlowFuse is hosting a monthly Node-RED Ask Me Anything session on April 13th. This is a great opportunity to ask Nick O’Leary, co-creator of Node-RED & FlowFuse CTO, and Rob Marcer, Node-RED FlowFuse Developer Educator your questions about Node-RED.

### Connect, Integrate, Visual Industrial Production Metrics with Node-RED

Join Steve McLaughlin from FlowFuse as he showcases how easy it is to use Node-RED to visualize popular production metrics using Node-RED. [Register today](https://flowfuse.com/webinars/2023/industrial-data-node-red/).

## From our Blog

[Comparing Node-RED Dashboards Solutions](https://flowfuse.com/blog/2023/03/comparing-node-red-dashboards/) - A popular article comparing Node-RED Dashboard, uibuilder and FlexDash.

[IBM Cloud removes Node-RED starter application](https://flowfuse.com/blog/2023/03/ibmcloud-starter-removed/) - IBM has discontinued their Node-RED Starter Application, discover how to migrate to FlowFuse.

[The benefits and drawbacks of using Node-RED function nodes](https://flowfuse.com/blog/2023/03/why-should-you-use-node-red-function-nodes/) - Node-RED function nodes provide a great deal of flexibility in Node-RED. Discover the benefits and drawbacks of using them.

[FlowFuse 15. Now Available](https://flowfuse.com/blog/2023/03/flowforge-1-5-0-released/) - FlowFuse 1.5 included updates to the UI and architecture to allow for future features.

Node-RED Quick Tips - Rob Marcer, FlowFuse Developer Educator has a weekly series of Node-RED hints and tips

- [Node-RED Tips - Importing, Exporting, and Grouping Flows](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-5/)
- [Node-RED Tips - Smooth, Catch, and Math](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-4/)

## From the Community

### Quantum for Node-RED

Discover how you can incorporate [quantum technologies](https://theailaboratory.wordpress.com/2023/03/24/quantum-for-everyone/){rel="&#x22;nofollow&#x22;"} into your Node-RED flows.

### Image recognition within Node-RED

Kazuhito Yokoi, a researcher at Hitachi, has published an [interesting article](https://kazuhitoyokoi.medium.com/sharing-node-red-flow-of-image-recognition-application-on-github-4d667cdea9f7){rel="&#x22;nofollow&#x22;"} detailing how to incorporate TensorFlow into a Node-RED application to do image recognition.

### Custom Node Spotlight - node-red-contrib-web-worldmap

If you would like to include a map in your next project Worldmap is a really good place to start. You can pass coordinates in to set the map to a location or you can use the built in search tool to find a location. As a user manipulates the map a stream of updated coordinates can be passed back to your flows to trigger additional actions. It's a really useful tool, take a [look here](https://flows.nodered.org/node/node-red-contrib-web-worldmap){rel="&#x22;nofollow&#x22;"}.

## Join Our Team

FlowFuse is expanding our team. Check out the current openings:

- **[Developer Advocate - Manufacturing & Industrial Automation](https://boards.greenhouse.io/flowfuse/jobs/4798023004){rel="&#x22;nofollow&#x22;"}**


# FlowFuse v1.6 Now Available

The new FlowFuse 1.6 adds new support for multi-instance Node-RED within a single application and support for logging from remote devices.

## FlowFuse Applications Can Now Support Multi-Instance Node-RED

FlowFuse 1.6 expands the scope of applications to now allow for multiple instances of Node-RED. For complex Node-RED applications, it is common to have different flows interacting with other flows or flows deployed to different target environments. The ability to associate all these different flows with a single application makes it easier for the development, test and deployment of these types of complex applications.

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: OHChdWeRI9Q
---
::

## Access Node-RED logs from remote devices

FlowFuse makes it easy to deploy Node-RED out to remote devices. However, once Node-RED has been deployed to the remote device it is often difficult to troubleshoot or debug. Now with FlowFuse 1.6, you can get access to the Node-RED logs from remote devices. This makes it much easier to understand and debug the behavior of a remote device.

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: yW1zxwiCmto
---
::

## Other Improvements

Update email address verification [#813](https://github.com/FlowFuse/flowfuse/issues/813){rel="&#x22;nofollow&#x22;"}

Reminder email about trial doesn't include a link to FF Cloud [#1815](https://github.com/FlowFuse/flowfuse/issues/1815){rel="&#x22;nofollow&#x22;"}

Sign-up coupons improvement [#1788](https://github.com/FlowFuse/flowfuse/issues/1788){rel="&#x22;nofollow&#x22;"}

New FF\_Instance\_\* envvars inline with new terminology [#1844](https://github.com/FlowFuse/flowfuse/issues/1844){rel="&#x22;nofollow&#x22;"}

Deprecate FF\_PROJECT\_\* envvars [#1844](https://github.com/FlowFuse/flowfuse/issues/1844){rel="&#x22;nofollow&#x22;"}

Integrate with PostHog events [#1922](https://github.com/FlowFuse/flowfuse/pull/1922){rel="&#x22;nofollow&#x22;"}

Introduce search bar to docs/handbook [#620](https://github.com/FlowFuse/website/pull/620){rel="&#x22;nofollow&#x22;"}

## Bug Fixes

Deleting instances from the instance list fails [#1859](https://github.com/FlowFuse/flowfuse/issues/1859){rel="&#x22;nofollow&#x22;"}

Removing old projects with missing subscriptions fails [#1837](https://github.com/FlowFuse/flowfuse/issues/1837){rel="&#x22;nofollow&#x22;"}

Changing to a team as a member shows unauthorized error [#1845](https://github.com/FlowFuse/flowfuse/issues/1845){rel="&#x22;nofollow&#x22;"}

Application Overview: “Open Editor” shouldn’t show (or should be disabled) if in “Starting” state [#1931](https://github.com/FlowFuse/flowfuse/issues/1931){rel="&#x22;nofollow&#x22;"}

## Try it out

We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.6.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there.

If you hit any problems with the platform please raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That's also a great place to send us any feedback or feature requests.

You can also get help on [the Node-RED forums](https://discourse.nodered.org/){rel="&#x22;nofollow&#x22;"}

As well as in the [forum within our Github project](https://github.com/FlowFuse/flowfuse/discussions){rel="&#x22;nofollow&#x22;"}

Chat with us on the `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}

You can raise a support ticket by emailing <support@flowfuse.com>

We've also added a live chat widget to our website, you can access it using the icon on the bottom right corner of our website. We'd love to hear from you.


# FlowFuse's visit to Hannover Messe 2023

"Do you use Node-RED?" This simple question became our favorite conversation opener as ZJ and I attended Hannover Messe, the world's leading industrial trade fair.

To our delight, the answer was almost always "Yes." This allowed us to dive into truly fruitful discussions with Node-RED experts, exploring the latest industry trends, connecting with potential partners, and sharing our vision for the future of Node-RED in the manufacturing sector. During our visit, we had the pleasure of engaging with several vendors, including Bosch Rexroth, Siemens, Wago, Weidmüller, RevolutionPi, and more. It was genuinely inspiring to see the widespread adoption and usage of Node-RED across the entire industry. See also our [arcticle](https://flowfuse.com/blog/2023/03/integration-platform-for-edge-computing/#the-standard-for-edge-computing-and-plcs) about the adoption of Node-RED for PLCs and Gateways.

FlowFuse's innovative solutions, such as remote deployment of Node-RED instances, seamless updates, effortless rollbacks, and built-in security, are already addressing many challenges faced by Node-RED users in the industry today. The positive feedback we received at Hannover Messe has bolstered our commitment to making Node-RED more accessible and production-ready for industrial and enterprise scenarios. As we forge ahead, we are eager to collaborate with more partners, learn from industry leaders, and remain at the forefront of Node-RED development. Together, we can build a more connected, efficient, and innovative manufacturing industry. With each new booth we visited and every conversation we had, it became increasingly clear that Node-RED and FlowFuse are well on their way to becoming an integral part of the industrial landscape.


# Node-RED Community Health

It is often a challenge to measure the health of an open source project, like Node-RED. Individuals can download and use Node-RED without any indication or feedback to their ongoing satisfaction or usage. However, it is still interesting to look at a variety of metrics to understand the size of the Node-RED community.

**GitHub Stars**

A popular method for demonstrating popularity of an open source project are GitHub stars. Node-RED has over 16K stars and when [compared to other low-code platforms](https://synodus.com/blog/low-code/open-source-low-code-platforms/){rel="&#x22;nofollow&#x22;"} on GitHub has a strong showing. FWIW, GitHub stars are open to gaming so it is not a great long-term indicator of community health and engagement.

**Node-RED Library**

At the core of the Node-RED community is the library of nodes and flows that have been developed by community members. The current library has over [4300 nodes available](https://flows.nodered.org/search?type=node&sort=downloads){rel="&#x22;nofollow&#x22;"}, some of the more popular nodes are downloaded more than 10K times per week. The large library of community nodes supports a wide range of protocols, data sources, data stores, and much more. This makes Node-RED more relevant and useful to many more potential users.

**Node-RED Website Traffic**

In the last year, Node-RED has had over 1.9 million unique visitors to the [nodered.org](https://nodered.org/){rel="&#x22;nofollow&#x22;"} website, over 160K on a monthly basis. The most popular pages, after the home page, are the getting started pages. This demonstrates a strong interest in learning more about how to use Node-RED.

**NPM Downloads & Docker Pull Requests**

Node-RED is installed by lots of people using Docker and NPM. The project averages over 500K/month pull requests from [Docker Hub](https://hub.docker.com/r/nodered/node-red){rel="&#x22;nofollow&#x22;"} and 100K/month pull requests on [NPM](https://npm-stat.com/charts.html?package=node-red&from=2017-03-22&to=2023-03-22){rel="&#x22;nofollow&#x22;"}.

**Node-RED Forums**

The [Node-RED community forum](https://discourse.nodered.org/){rel="&#x22;nofollow&#x22;"} is the go to place to get community support. It is a very popular community with over 900K page views per month. The amazing thing is that a very large percentage of questions receive replies from other community members. A great sign of a healthy community.

Overall, the Node-RED community is large, healthy and engaged.


# Securing Node-RED (2026)

Node-RED is very easy to get up and running. Whether you run it locally, in Docker, on a Raspberry Pi, or on a service such as FlowFuse Cloud you can have a project up and running in minutes.

One thing that can get overlooked is the security of Node-RED. From personal experience, the first few times I installed Node-RED I was more focussed on the possibilities of what I could do with this new tool than I was keeping my projects secure.

In this article I’m going to look at some easy ways to make your Node-RED project more secure, even when first learning about it in a hobby environment.

## Protecting access from your LAN to Node-RED

Once you have an instance of Node-RED running it can usually be accessed from anywhere on your LAN (local area network) by pointing a web browser to the relevant IP address and port.

`http://192.168.0.3:1880`

With a URL similar to the one above, depending on your specific network and Node-RED configuration, anyone on your LAN can view but more importantly edit your flows. This can be really useful when you are first learning about Node-RED but it’s always a good idea to get into the habit of locking down access to the editor, even if you trust everyone who can access your LAN.

One of the easiest ways to protect your flows is to add a username and password to your Node-RED instance.

:cta-image{alt="Power Workplace relies on FlowFuse for scalability, reliability and security audits - book a demo" cta="demo" src="https://flowfuse.com/images/cta/power-workplace-book-demo.png"}

The first step is to find your Node-RED settings.js file. It's not always in the same place but on a default Debian Linux installation it can be found in this directory.

`cd ~/.node-red`

If you list that directory you should now see something like this:

![Where your settings file should show](https://flowfuse.com/blog/2023/04/images/ls.png "Where your settings.js should show")

We now need to edit settings.js, I'm going to use my favourite text editor, [Nano](https://www.nano-editor.org/){rel="&#x22;nofollow&#x22;"} to do that.

`nano settings.js`

We now need to find and edit the following section of the settings file:

![The settings file before being edited](https://flowfuse.com/blog/2023/04/images/without-password.png "The settings file before being edited")

For this example, I'm going to add a password and uncomment the relevant section of the settings file, you could also change the username for additional security.

To create the password we'll need to use a command line tool which is included in Node-RED. Open a second terminal then run this command:

`node-red admin hash-pw`

Put in your new password, I'll use the password 'flowforge' in this example. The tool returns your password in a hashed format:

![The Node-RED tool outputs the hashed password](https://flowfuse.com/blog/2023/04/images/password.png "The Node-RED tool outputs the hashed password")

We can now return to the other terminal window, uncomment the section then paste in the new password, this is how it looks for me:

![The settings file with the relevant section uncommented and the password set](https://flowfuse.com/blog/2023/04/images/with-password.png "The settings file with the relevant section uncommented and the password set")

We can now save and exit out of the settings file.

The last step is to restart Node-RED, I'm using Debian so the command is:

`node-red-restart`

Now, when we try to access Node-RED I will need to provide a username and password.

:video{ariaLabel="Using the username and password to login to Node-RED" autoPlay="true" height="476" loop="true" muted="true" playsInline="true" preload="none" width="708"}

You might also want to consider turning off the editor interface once you are happy with your flows. This can make it a little harder to make changes to your project but it also gives you peace of mind that nobody has accidentally or deliberately changed your flows. You can turn off the editor interface as follows.

Edit your settings.js file as explained above, look for the following section:

![The setting file before turning off the editor](https://flowfuse.com/blog/2023/04/images/editor-on.png "The setting file before turning off the editor")

All you need to do is uncomment the bottom line then change the value from false to true, once done it should look something like this:

![The setting file after turning off the editor](https://flowfuse.com/blog/2023/04/images/editor-off.png "The setting file after turning off the editor")

Now restart Node-RED as covered above, then try accessing your Node-RED instance again. You will no longer be able to edit or view your flows.

Using these two features, we now have much better control over who can access the design interface for Node-RED.

## Traffic to your Node-RED instance is unencrypted

Hopefully, we all know the importance of encrypting your connections between devices to stop people intercepting your traffic. This isn't a huge concern when working on your home LAN but what if you want to access your Node-RED instance from a remote location?

There are two obvious options, HTTPS, and a VPN (Virtual Private Network).

We could setup your Node-RED traffic to run over HTTPS, this solution ensures that all traffic to and from your Node-RED is encrypted. The downside to this approach is it's quite complex to set up. We will need to have a domain name, open up ports on our LAN's firewall, use a HTTPS certificate provider and then make sure we remember to renew the certificates as needed. It's doable if you are comfortable with those concepts (I covered how to do this as part of my blog [hosting FlowFuse on Google Cloud](https://flowfuse.com/blog/2022/12/flowforge-gcp-https-set-up/)) but there is an easier way to get started, using a VPN.

A VPN provides a lot of security advantages depending on which you are using and how it is configured. To secure my traffic I'm going to use a great service call [Tailscale](https://tailscale.com/){rel="&#x22;nofollow&#x22;"} which is free for personal projects.

I'm going to install Tailscale on the Raspberry Pi I'm running Node-RED on as well as any other devices I want to access my project from. Once that's done I can access Node-RED from anywhere with internet access but more importantly the traffic to and from my devices is also encrypted.

Before we start, it's important to remember that a VPN is only as secure as the company who runs it. You should always consider if you trust the VPN provider as they could potentially access your devices. I trust Tailscale but please do your own research before using a VPN provider.

The first step we need to take is creating a Tailscale account, [you can sign up for free here](https://login.tailscale.com/start){rel="&#x22;nofollow&#x22;"}. We next need to add our devices to our VPN using their software, I'm installing Tailscale on my Apple laptop, Google phone as well as the Raspberry Pi I'm running Node-RED on.

The install process is really easy, even on the Pi running Raspbian the steps you need to take are well explained in the [Tailscale docs](https://tailscale.com/download/linux/debian-bullseye){rel="&#x22;nofollow&#x22;"}.

For the Pi, these are the commands we need to run.

1. Add Tailscale to the Apt package manager.

`curl -fsSL https://pkgs.tailscale.com/stable/debian/bullseye.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null`

`curl -fsSL https://pkgs.tailscale.com/stable/debian/bullseye.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list`

`sudo apt-get update`

2. Install Tailscale

`sudo apt-get install tailscale`

3. Start Tailscale and connect your device

`sudo tailscale up`

After running the last command, we need to follow the on screen prompts to link our devices to your VPN.

One last thing which you might want to consider doing, every few months you will need to reconnect your devices to your VPN, if you are only going to be accessing your Node-RED device over the VPN you should consider [disabling your Tailscale key expiry](https://tailscale.com/kb/1028/key-expiry/){rel="&#x22;nofollow&#x22;"}.

OK, now we've got our devices all connected you should see something like this in the Tailscale dashboard.

![Tailscale dashboard showing my three devices](https://flowfuse.com/blog/2023/04/images/tailscale.png "Tailscale dashboard showing my three devices")

I can now access Node-RED on my Pi from my laptop and phone by pointing a browser to the correct IP address (as shown in the image above) with the port for Node-RED:

`http://100.71.28.60:1880`

I’ve now secured all traffic between my devices and Node-RED project, I can access Node-RED from anywhere on the internet.

![Accessing Node-RED via the VPN](https://flowfuse.com/blog/2023/04/images/nr-via-vpn.png "Accessing Node-RED via the VPN")

If you follow these steps you should be on the right path to running a more secure Node-RED instance. There is a lot more you can do and I recommend you read the [relevant docs on the Node-RED](https://nodered.org/docs/user-guide/runtime/securing-node-red){rel="&#x22;nofollow&#x22;"} website to gain some more ideas.

## What about hosting Node-RED on a cloud solution such as FlowFuse?

In this article, I've focussed on hosting Node-RED on a Pi on your own LAN but if you use FlowFuse Cloud to host Node-RED the solutions discussed above are either ready out of the box or are not needed.

By default, the Node-RED editor is secured using your FlowFuse user credentials. You can also enable SSO to enhance account security and easily grant access to team members. With role-based access control, you can further protect your flows by managing who can view or edit them.

All traffic to FlowFuse and your Node-RED instances is protected by HTTPS. FlowFuse has set up the domain name and manages the certificates, so you can spend time on your flows rather than configuring security. Additionally, remote device access is secured through encrypted tunnels, providing comprehensive protection for your deployments.

FlowFuse has a [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} if you'd like to see how we've made secure hosting of Node-RED easy.

## Conclusion

How ever you host Node-RED, it's a great idea to get into good security practices as early as possible to ensure that no unsecured Node-RED instances are exposed to the internet. I hope some of the tips above help you get started down the path to creating more secure Node-RED projects.


# Bringing High Availability to Node-RED

Many companies look to deploy Node-RED into use cases that require the application
to have a high degree of availability, reliability, and scalability. Following up
our [previous post on the subject](https://flowfuse.com/blog/2023/02/highly-available-node-red/), in this
post I’m going to look at some of the technical details of achieving HA, the
approaches available and what that means for the work we’re doing at FlowFuse
and upstream in Node-RED.

Everyone we speak to has a different set of requirements for this topic. To help
with the discussion, I’m going to look at two ways of approaching it:

- The **hot-spare approach** where you have a second instance of the application
  ready to take over when the primary fails. This achieves availability but
  doesn’t contribute to scalability.
- The **load-balanced approach** where you have a second active instance of the
  application and work is shared between them. If either fails, the other
  continues running. A side-effect of this approach is a higher potential
  through-put and scalability; although in practice you need to ensure capacity
  to tolerate an instance failing.

To consider which approach is most appropriate in the context of Node-RED, we
need to look at the benefits and complications of each approach. It comes down
to two factors; statefulness and how work is routed.

### Statefulness

There are two types of state to consider when thinking about a Node-RED flow:
**explicit** and **implicit** state.

Explicit state is what is programmed into the flow. For example, a flow may store
state in Context or use an external database service. Within FlowFuse we provide
two types of context - the default in-memory context store and a database-backed
persistent store. Currently the database-backed store includes a memory-caching
layer to provide better performance and interoperability. That gets tricky when
you want to have multiple instances sharing the same store. The context API
doesn’t provide a way to atomically update values - so you can get into classic
concurrency issues around two applications trying to update the same value.

The other type of state is that which is implicitly maintained in a flow - even
if the user hasn’t explicitly configured it. For example, the Smooth node can be
used to calculate a running average value of messages passing through it. The
node does that by keeping in memory the recent values so it can recalculate the
average with each update. If you have multiple instances, then the node will be
calculating the average for just the message its instances sees.

Another example of implicit state is the Batch node that can be used to group
messages into batches. Again - it will only be able to do that for the selection
of messages the instance receives.

It very much depends on the requirements of a flow and what nodes it uses, as to
how the state can be handled.

In the hot-spare approach, as only one instance is active at any time, a lot of
the explicit state handling will work as expected. However the implicit state
remains bound to the individual Node-RED instances.

In the load-balanced approach, care has to be taken to ensure any state generated
by the flow is done in a way that copes with multiple instances accessing it at
the same time.

A key take-away from this being that a flow has to be created with HA and/or scaling
in mind.

### Routing work

Node-RED makes it easy to integrate with lots of different sources of events.
A couple of the most common being HTTP and MQTT. When considering how to handle
multiple instances of an application we need to think about how work is routed
to those instances.

HTTP is the most well understood; you put a load-balancing proxy in front of the
Node-RED instances and it takes care of sharing out the incoming requests. In
the hot-spare scenario, the proxy needs to know which instance is active - that
requires some coordination within the platform to track that properly.

MQTT is commonly used with Node-RED, but unlike HTTP which is in-bound, MQTT
works by having Node-RED create an out-bound connection to a broker and then
subscribing to the topics of interest. In the early days of MQTT that would mean
each instance would subscribe to the same set of topics and receive every message.
That doesn’t really fit any HA model.

With the publication of MQTTv5, the concept of Shared Subscriptions was added;
the ability for a group of clients to connect, subscribe to the same topic and
have the broker distribute messages between them. At this point you do get load
balancing across your Node-RED instances - as long as the MQTT nodes are suitably
configured.

There are lots of other nodes that can be used to trigger flows, whether by
listening for events on an API, connecting to locally attached hardware and many
things in between. Typically, those that are more cloud-aligned, such as messaging
systems like Kafka and AMQP will have very well established ways of doing load
balancing.

Managing out-bound connections gets more complicated in the hot-spare scenario.

If we only had to deal with in-bound connections, the hot-spare instance can just
sit there waiting for work to be passed its way. But once you have out-bound
connections, then you have a problem. The hot-spare instance should only create
its out-bound connections when it becomes the active instance. In real terms,
that means the Node-RED flows should only be started when the instance becomes
active.

With our goal to minimize the Mean Time To Recovery (MTTR), we need to find a
way to get that spare instance running as quickly as possible; if it takes just
as long to start the spare instance as it does to restart the failed primary
instance, then it isn’t much of an improvement.

The key here is that Node-RED allows you to start the runtime without the flows
running. That gets everything loaded and the runtime ready ahead of time. It can
then start the flows at a moment's notice with a simple call to the runtime admin
API.

### Detecting failure

A key requirement of the hot-spare approach to HA is knowing when to failover to
the spare.

This requires close monitoring of the active instance to know whether it's still
working. How quickly you can detect failure is key to reducing the time to recovery.
This is where you have to think about the different ways an instance could fail -
has it crashed, has it hung, has it got ‘stuck’?

Detecting failure usually involves some combination of heartbeat ‘pings’ between
the instances to check each is able to respond to requests. The spare instance
then needs to be able to decide for itself whether it should become the active
instance - and do so safely. You do not want to accidentally have two instances
active at the same time. This can get quite complicated to achieve safely, but
there are a number of approaches that can be used. We’ll be exploring them as we
continue our journey towards HA.

### Editing Flows

Within the Node-RED architecture, each instance also serves up its own editor.
This is what you get when you point your web browser at it.

In a HA world, once you have multiple instances running behind an HTTP load
balancer, there is a tricky question of how you edit the flows. If each request
hits a different instance, just loading the editor will result in different bits
coming from different instances. That can typically be solved at the load balancer
level by creating sticky-sessions; ensuring for a given client, each request is
routed to a consistent instance. That solves part of the issue, but the next
challenge is what to do when the Deploy button is pressed. That is how new flows
are passed from the editor to the runtime. When you have multiple instances, we
need to make sure that they all get updated. That is quite a tricky problem to
solve with the current Node-RED APIs - and something we’ll be working on both in
FlowFuse and in the upstream Node-RED project to resolve.

That said, a more immediate solution could well be to take advantage of separate
development/production instances. You develop in a single instance and, when happy
with what you’ve got, roll it out to your HA-ready production instance. This
bypasses the need to edit the flows in the HA environment at all.

Whichever method is used, there is a question of how you minimize downtime whilst
deploying an update. In a purely in-bound environment, solutions can be built
where the new application is deployed alongside the old version and, when everything
is ready, the in-bound events are redirected to the new version. But that isn’t
feasible when you have out-bound connections to deal with as well. For some users,
having a scheduled maintenance window for doing updates will be completely acceptable.

As with the hot-spare approach to failover, a similar method could be used that
starts new instances of Node-RED alongside the old, but with the flows all stopped.
Then, once everything is ready, the old instances are stopped and the new instances
started - minimizing the downtime, although not completely removing it.

### Continuing the HA journey at FlowFuse

So the question is how are we going to apply all of this to what we’re building
at FlowFuse. We cannot do everything at once, so we have to prioritize which
scenarios we’re going to address first. Consequently, drawing from customer
feedback, we have chosen to start with the scaling side of high availability -
allowing multiple copies of an instance to be run with appropriate load
balancing put in front of it.

We are building FlowFuse as an open platform with the ability to run on top of
Docker Compose and Kubernetes. As we get into some of these HA features, we will
need to look carefully at where we can lean on these underlying technologies -
we don’t want to reinvent the wheel here.

Our initial focus is going to be when running in a Kubernetes environment - just
as we do with our hosted FlowFuse Cloud platform. Kubernetes provides lots of
the building blocks for creating a scalable and highly available solution, but
it certainly doesn’t do all of the work for you.

We've identified our initial set of tasks and changes to how we'll run Node-RED
instance with the k8s environment. You can follow our progress with this
[issue](https://github.com/FlowFuse/flowfuse/issues/2156){rel="&#x22;nofollow&#x22;"} on our backlog.

I hope this post has given some useful insight into the problems we’re looking
to solve at FlowFuse. As it's such an important requirement for many users we’ll
keep you updated as we make progress.


# Chat GPT in Node-RED Function Nodes

Recently we [posted a demo of ChatGPT integration in a Node-RED function node](https://www.linkedin.com/posts/flowforge_chatgpt-with-node-red-function-nodes-activity-7052725869684953088-2yOA?utm_source=share&utm_medium=member_desktop){rel="&#x22;nofollow&#x22;"}
onto our social media accounts. We have now [open-sourced](https://github.com/FlowFuse/node-red-function-gpt) this for all to play with, and **welcome any and all contributions**.

## How it Works - Prompt Engineering

OpenAI make a collection of their [Generative AI models](https://platform.openai.com/docs/models){rel="&#x22;nofollow&#x22;"} available
via an API. We are wrapping OpenAI's [node.js module](https://www.npmjs.com/package/openai){rel="&#x22;nofollow&#x22;"}, and in particular
using the `openai.createChatCompletion()` functionality. For this API, you provide a chat history, and ChatGPT will
respond with the next entry in that conversation.

In order to "train" ChatGPT for our use case of populating Node-RED function nodes, we first tried a collection of prompts, defining specific
requirements for the contents, e.g. &#x2A;"Always write Javascript"&#x2A;, &#x2A;"Never include the wrapping function definition"&#x2A;,
&#x2A;"Assume the input is always msg"*.

It turns out though, that we were over-engineering it, we were not getting reliable results and ended up
realising that ChatGPT's existing knowledge of Node-RED was sufficient such that we could use that as a prompt:

Here's what we settled on:

```javascript
messages: [
    {role: "system", content: "always respond with content for a Node-RED function node, and don't add any commentary, always use const or let instead of var. Always return msg, unless told otherwise."},
    {role: "user", content: prompt}
],
```

Here we send a `system` prompt in order to setup ChatGPT, and then follow that immediately with whatever the user has typed.
From our (limited) testing, this has given us fairly reliable results.

Breaking this prompt down:

- ***"Always respond with content for a Node-RED function node"***: Ensured no surrounding `function () {}` definition and set expectations that the function would deal with a `msg` and likely `msg.payload` object.
- ***"Don't add any commentary"***: ChatGPT likes to, well, chat. It would always return raw text justifying decisions, etc. Here, we just wanted the code.
- ***"Always use const or let instead of var"***: This was Steve being picky.
- ***"Always return msg, unless told otherwise"***: We found this wasn't mostly required, but occasionally it would try to return a different variable, and we'd lose context of `msg.payload`, or other data stored in `msg`. So this just made sure we had the consistency.

The response from this API call is then populated into the contents of the active tab in the function node:

![Screenshot 2023-04-21 at 16 08 47](https://user-images.githubusercontent.com/99246719/233671631-fefa36c1-6db4-4392-a057-314c16fd91b7.png){width="1728"}

In order to use it yourself, you will need a [valid API Key from OpenAI](https://platform.openai.com/account/api-keys){rel="&#x22;nofollow&#x22;"}.

## Additional Features

This was built in about a day by Steve and Joe, and we had plenty of ideas on what we'd like to add to it. We've
[open-sourced](https://github.com/FlowFuse/node-red-function-gpt){rel="&#x22;nofollow&#x22;"} it, and will add these as issues to the repo, but if anyone want so take a stab at contributing - that'd be most welcome!

- **Insert at Cursor ([issue](https://github.com/FlowFuse/node-red-function-gpt/issues/11){rel="&#x22;nofollow&#x22;"}):** Currently, the Ask GPT call will replace *all* of the content of that tab. Would be great
  to have the code insert wherever the cursor last was in order to add to existing code.
- **Retain Conversation History ([issue](https://github.com/FlowFuse/node-red-function-gpt/issues/12){rel="&#x22;nofollow&#x22;"}):** Each time a new prompt is provided by the Node-RED user, we send a fresh conversation to OpenAI,
  meaning that knowledge of previously asked questions are not retained.
- **Client side ChatGPT Config ([issue](https://github.com/FlowFuse/node-red-function-gpt/issues/13){rel="&#x22;nofollow&#x22;"}):** Currently, when you add a new "function-gpt" node you need to select the ChatGTP
  Config node and click "Deploy" before you can ask it a question. Our ChatGPT interaction operates server-side (to
  protect your API key), so Node-RED needs that in the runtime first, before a call to ChatGPT can be made. Ideally,
  we'd be smarter here and pass client-side creds along with the call such that we can use any changes made by the
  user at the time of the call.

## FlowFuse Assistant - No API Keys Required!

Great news! You no longer need to manage OpenAI API keys or configure ChatGPT nodes. The [FlowFuse Assistant](https://flowfuse.com/docs/user/expert/) is now built directly into Node-RED on FlowFuse Cloud, making AI-powered development even easier.

Available on FlowFuse Cloud, the Assistant offers:

- **Quick Function Node Creation**: Add function nodes to your flow without dragging from the palette
- **In-line Code Generation**: Generate JavaScript code for function nodes, JSON for JSON editors, and Vue.js for FlowFuse Dashboard ui-template widgets
- **Flow Explainer**: Select nodes and click "Explain Flows" to understand what they do

FlowFuse Assistant helps developers work faster and smarter with Node-RED. [Start your free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} to experience AI-powered Node-RED development on FlowFuse Cloud.


# Community News May 2023

Welcome to the FlowFuse newsletter for May 2023, a monthly roundup of what’s been happening with both FlowFuse and the wider Node-RED community.

## Upcoming events

### Ask Me Anything about Debugging Node-RED

Our monthly Node-RED AMA session will have a special focus on debugging. Nick and Rob will lead us through some useful debug workflows to show how they approach debugging Node-RED applications. During the live coding sessions there will be opportunities for attendees to ask questions in real-time. Join us to learn from the experts on the tips and tricks for debugging Node-RED flows.

### Getting Started with Node-RED Dashboard

How can you use Node-RED to create dashboards and interactive graphs of your data? The answer is the Node-RED Dashboard node, the most popular node in the Node-RED community. In this webinar, Rob Marcer will take you through the steps of how to get started with the Node-RED Dashboard. [Register today](https://flowfuse.com/webinars/2023/getting-started-nodered-dashboard/).

## From our Blog

[Chat GPT in Node-RED Function Nodes](https://flowfuse.com/blog/2023/05/chatgpt-nodered-fcn-node/) - Use Chat GPT to write Node-RED functions directly in the Node-RED interface.

[Securing Node-RED](https://flowfuse.com/blog/2023/04/securing-node-red-in-production/) - A look at how you can secure Node-RED deployments.

[Node-RED Community Health](https://flowfuse.com/blog/2023/04/nodered-community-health/) - Some key community metrics for the Node-RED community.

[FlowFuse's visit to Hannover Messe 2023](https://flowfuse.com/blog/2023/04/hannover-messe/) - Our CEO and Product Manager visited Hannover Messe in Germany; one of the largest trade shows for manufacturing.

[FlowFuse 1.6 Now Available](https://flowfuse.com/blog/2023/04/flowforge-1-6-released/) - FlowFuse 1.6 included support for multi-instance Node-RED within a single application as well as support for logging from remote devices.

[Node-RED Tips - Subflows, Link Nodes, and the Range Node](https://flowfuse.com/blog/2023/04/3-quick-node-red-tips-6/)

## From the Community

Jsonata is a very useful and often underutilised tool built into Node-RED. Steve over at [Steve's Node-RED Guide](https://stevesnoderedguide.com){rel="&#x22;nofollow&#x22;"} has published a great beginners guide. If you are new to Jsonata and want to learn more we recommend you [take a look](https://stevesnoderedguide.com/node-red-and-jsonata-for-beginners){rel="&#x22;nofollow&#x22;"}.

### Custom Node Spotlight - node-red-contrib-queue-gate

[Queue Gate](https://flows.nodered.org/node/node-red-contrib-queue-gate){rel="&#x22;nofollow&#x22;"} is a handy custom node which allows you to control the flow of messages. You might wish to queue up all the messages in a flow and then release them all, once an hour. Maybe you want to release just one message at a time and wait until the prior message completed a section of your flow. Queue Gate makes message queuing really easy without the need to use an external queue solution.

## Join Our Team

FlowFuse is expanding our team. Check out the current openings:

- **[Developer Advocate - Manufacturing & Industrial Automation](https://boards.greenhouse.io/flowfuse/jobs/4798023004){rel="&#x22;nofollow&#x22;"}**
- **[Sales Representative](https://boards.greenhouse.io/flowfuse/jobs/4843566004){rel="&#x22;nofollow&#x22;"}**


# Running the FlowFuse Device Agent as a service on a Raspberry Pi

FlowFuse's device agent allows you to manage and run your Node-RED instances on
your own hardware such as a Raspberry Pi. This can be very useful where an
application you've written needs to run flows with direct access to hardware sensors.

In this article I'm going to explain the steps to configure our device agent to run as a service in Raspbian OS,
or any other OS that uses systemd.

## Why run the device agent as a service?

The standard process for running FlowFuse's device agent is to start it on the
command line using the command `flowforge-device-agent`. This works fine for testing
but for long-term installations it's useful to run the device agent as a service.
Once running as a service, the device agent will continue to run even if your
device is restarted or your SSH connection to your Pi fails.

## Set up steps

### Create the Service File

The first step is creating the systemd unit file for your service. You can start by creating a new file in the
`/etc/systemd/system` directory with a .service file extension:

`sudo nano /etc/systemd/system/flowforge-device-agent.service`

### Define the Service

In the service file, you'll need to define the following parameters:

- `Description`: A brief description of what the service does.
- `ExecStart`: The command(s) to execute to start the service.
- `User and Group`: The user and group that the service runs as.
- `Type`: Whether the service is a simple or a forking type.

We've created the content you'll need for this file and shared it via [this GitHub page](https://github.com/FlowFuse/device-agent/blob/main/service/flowfuse-device.service){rel="&#x22;nofollow&#x22;"}.

Copy the code from that page into the nano window you created in step 1, then save and exit out of nano.

### Starting the service on boot (optional)

If you want Node-RED to run when the Pi is turned on, or re-booted, you can enable the service to autostart by running the command:

`sudo systemctl enable flowforge-device-agent.service`

To disable the service, run the command:

`sudo systemctl disable flowforge-device-agent.service`

### Using your new service

You can now start your service with the start command:

`sudo systemctl start flowforge-device-agent`

You can check the current status with the status command:

`sudo systemctl status flowforge-device-agent`

Finally, if you need to stop your agent you can do so with the command:

`sudo systemctl stop flowforge-device-agent`

## Further reading

If you'd like to learn about using services via the systemctl command you can access
the help text by running `systemctl -h` from your Pi terminal.


# FlowFuse 1.7 Now Available with Remote Node-RED Editor Access

FlowFuse 1.7 adds new support for accessing the Node-RED Editor on Devices via FlowFuse.

## Further improving fleet management and maintenance of remote Node-RED instances

We are excited to introduce a new feature that will simplify the process of debugging and developing flows for devices. Our latest feature, "Editing Flows on Devices" allows users to access the editor directly on their device without the need for complex network configurations or firewalls. This feature will significantly improve the user experience, making it easier and more efficient to work with devices.

This update is a part of our ongoing commitment to making FlowFuse the best possible solution for developing your Node-RED flows, no matter where they're running. In fact, as part of our last release 1.6, we already introduced the feature: ["Access Node-RED logs from remote devices"](https://flowfuse.com/blog/2023/04/flowforge-1-6-released/#access-node-red-logs-from-remote-devices). This feature made it easy for users to troubleshoot and debug. Building on that, we've taken the next step, and it's now possible to access the Device Editor.

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: zS6P3RR86vE
---
::

## Device Status Visualisation

This FlowFuse version upgrades device monitoring. It's made easier to manage your devices effectively, especially when there's many of them. Now we offer an intuitive, user-friendly method for users to keep an eye on their devices' status and evaluate the health of their team's devices overall. Creating an overview of your fleet's health, however large your fleet might be.

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: S--viuPhrS8
---
::

## Auto Restart for Hung Node-RED Instances

This enhancement ensures a more robust and reliable experience when working with Node-RED flows. The launcher now actively monitors the Node-RED process to detect if it has become unresponsive or hung, in addition to the existing checks for start-up and unexpected process exits. This advancement takes us one step further in improving the availability of our Node-RED instances.

## Ongoing Topics

### High Availability

We're actively progressing on the topic of enhancing High Availability in FlowFuse for Node-RED. Our initial tasks and modifications have been identified, specifically pertaining to the operation of Node-RED instances within the k8s environment. These adjustments are aimed at constructing a more resilient system. Stay tuned for a comprehensive update regarding our advancements in High Availability.

### SOC2 Certification

Dedicated to upholding the highest levels of security and privacy, our company acknowledges the significance of industry-standard certifications like SOC2 in fostering trust with our customers and partners. We aim to achieve SOC2 Type 1 certification by the end of Q2 and subsequently maintain a continuous SOC2 Type 2 certification. We will keep you informed on our progress as we reach essential milestones in our SOC2 certification journey. Rest assured, our commitment to delivering the utmost security and privacy for our customers and partners remains unwavering.

### AWS Marketplace onboarding

We are excited to provide an update on our ongoing task of onboarding Node-RED instances to AWS Marketplace via FlowFuse Cloud, which we have started in this Iteration. By offering Node-RED instances through AWS Marketplace, we aim to simplify the deployment process for our customers.

One of the significant challenges we are currently addressing is handling our current payment system in parallel with a new method. This will ensure a seamless billing experience for our customers, as they will be able to manage their Node-RED instance subscriptions through their existing AWS accounts.

## Contributors

We'd like the thank the following for their contributions to this release:

- [@andreikop](https://github.com/andreikop){rel="&#x22;nofollow&#x22;"} for their work on the [flowforge-driver-k8s #80](https://github.com/FlowFuse/flowforge-driver-k8s/pull/80){rel="&#x22;nofollow&#x22;"} and [flowforge/helm #125](https://github.com/FlowFuse/helm/pull/125){rel="&#x22;nofollow&#x22;"}
- [@elenaviter](https://github.com/elenaviter){rel="&#x22;nofollow&#x22;"} for their work on [flowforge/helm #126](https://github.com/FlowFuse/helm/pull/126){rel="&#x22;nofollow&#x22;"}

As an open-source project, we welcome community involvement in what we're building. If you're interested in contributing, checkout our [guide in the docs](https://flowfuse.com/docs/contribute/).

## What's next?

We're always working to enhance your experience with FlowFuse. Here's how you can stay informed and contribute:

- **Roadmap Overview**: Check out our \[Product Roadmap Page/changelog/) to see what we're planning for future updates.
- **Entire Roadmap**: Visit our [Roadmap on GitHub](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"} to follow our progress and contribute your ideas.
- **Feedback**: We're interested in your thoughts about FlowFuse. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Bug Fixes

Incorrect number of days displayed when adding a new license [#1895](https://github.com/FlowFuse/flowfuse/issues/1895){rel="&#x22;nofollow&#x22;"}

Users were unable to upgrade modules in Manage Palette, even after restarting Node-RED. [#2005](https://github.com/FlowFuse/flowfuse/issues/2005){rel="&#x22;nofollow&#x22;"}

Enable 'Delete Team' Button [#2031](https://github.com/FlowFuse/flowfuse/issues/2031){rel="&#x22;nofollow&#x22;"}

Triggering a Node-RED restart using the action button resulted in two instances of Node-RED running in the container, causing one instance to crash due to port 1880 being already in use. [#2031](https://github.com/FlowFuse/flowfuse/issues/1860){rel="&#x22;nofollow&#x22;"}

Error deleting instance with missing subscription [#2080](https://github.com/FlowFuse/flowfuse/issues/2080){rel="&#x22;nofollow&#x22;"}

Snapshot Rollback no longer working [#2026](https://github.com/FlowFuse/flowfuse/issues/2026){rel="&#x22;nofollow&#x22;"}

Users receiving an unauthorized error when attempting to switch to a team in which they are a member [#1845](https://github.com/FlowFuse/flowfuse/issues/1845){rel="&#x22;nofollow&#x22;"}

Cannot select "Member" option when inviting a team member [#2084](https://github.com/FlowFuse/flowfuse/issues/2084){rel="&#x22;nofollow&#x22;"}

## Try it out

We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.7.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there.

If you hit any problems with the platform please raise an [issue on GitHub](https://github.com/FlowFuse/flowfuse/issues){rel="&#x22;nofollow&#x22;"}.
That's also a great place to send us any feedback or feature requests.

You can also get help on [the Node-RED forums](https://discourse.nodered.org/){rel="&#x22;nofollow&#x22;"}

As well as in the [forum within our Github project](https://github.com/FlowFuse/flowfuse/discussions){rel="&#x22;nofollow&#x22;"}

Chat with us on the `#flowfuse` channel on the [Node-RED Slack workspace](https://nodered.org/slack){rel="&#x22;nofollow&#x22;"}

You can raise a support ticket by emailing <support@flowfuse.com>

We've also added a live chat widget to our website, you can access it using the icon on the bottom right corner of our website. We'd love to hear from you.


# Best Practices Integrating a Modbus Device With Node-RED (2026)

The world of industrial automation is slow to adopt new technology. With legacy equipment already working and in place, paralyzing down-time costs, and fears of introducing instability into a plant, technology change has a cautious pace.

Node-RED provides a way to extend the capabilities of the simpler, proven technology, allowing connections with modern systems. However, the same fundamentals that have made industrial equipment dependable, must be incorporated into your Node-RED architecture. And, inversely, the same abstraction and simplicity that makes a low-code, Node-RED environment fast, and easy to work with, can also make it difficult to interface with a lower-level system.

Modbus is a widely adopted protocol for accessing data from existing legacy manufacturing equipment. Node-RED makes it very easy to connect to Modbus enabled equipment. However, there are some best practices we have developed to maintain system integrity when integrating Modbus devices with Node-RED:

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

### Add Watchdogs to Node-RED Flows

To keep your automation system running with peace of mind and little human intervention, use a watchdog timer. A watchdog timer is typically used to detect and recover from system malfunctions. In Node-RED a watchdog timer can be tied to a broadcast messaging system to get push alerts directly to cell phones, as well as to an auto-reset to try to get your Flows back online automatically. A simple implementation of this is to just put two Trigger nodes in a loop, the first one to send an alert when it hasn’t seen any recent events, and the second to to reset the first one.

![Example watchdog flow](https://flowfuse.com/blog/2023/05/images/integrating-modbus-3.png "Example watchdog flow")

Each of the trigger nodes are setup with similar parameters, only the delay values differ.

![Trigger node configuration](https://flowfuse.com/blog/2023/05/images/integrating-modbus-14.png "Trigger node configuration")

Sending a payload of {"connectorType":"TCP"} to the Modbus Flex Connector is enough to reset the connection without needing to send all the other parameters.

![Change node configuration](https://flowfuse.com/blog/2023/05/images/integrating-modbus-10.png "Change node configuration")

### Choosing a Safe Poll Rate

Be careful when adding new traffic to an industrial network, which might not be able to handle the extra load. Some networks have low-bandwidth, especially at large plants that might be using antiquated IP devices and long-distance, Wi-Fi bridges in electrically noisy environments. Furthermore, some PLCs and other Modbus devices have limits as to how many other devices can connect to them, and a new connection might not work, or worse, bump off an old connection. A PLC’s general operation is to poll its inputs every cycle and react accordingly, running logic and triggering outputs as quickly as possible. The general use-case for Node-RED with a PLC is to create an HMI or broader, SCADA system. A poll rate of every second suffices for a simple HMI. For dashboards published to a greater audience, rather than just the operator, poll rates of several minutes to hours might be adequate. If this is a new integration, it’s better to start slow and make sure the current infrastructure can handle the extra load.

![Modbus node configuration](https://flowfuse.com/blog/2023/05/images/integrating-modbus-7.png "Modbus node configuration")

### Coil/Register Grouping

Modbus works more efficiently when it is reading and writing addresses as groups. Creating banks of consecutively numbered coils or registers can help with this. If Modbus is already in use, perhaps for an existing HMI, but for your Node-RED dashboard you just want a selection of these addresses and they are too scattered to be read all at once, pick a starting address numbered far higher than what you will use for any HMI work and create a new bank of coils or registers just for the Node-RED dashboard. The PLC can handle this easily and it greatly simplifies the polling for your Node-RED dashboard. On the Node-RED side of the connection, it’s a good idea to parse and to filter this data as soon as it enters the flow. Below, the first node creates an appropriate message for each coil, with a topic name and a true/false payload. This message is then filtered by the “block unless value changes” mode in the filter node and finally a switch (by topic) node separates out each message. In this example, every Tag coming in from the PLC only triggers downstream nodes when there is a change and each Tag has its own output to connect a wire, and subsequent nodes to.

![Using a switch node to separate the messages](https://flowfuse.com/blog/2023/05/images/integrating-modbus-5.png "Using a switch node to separate the messages")

The filter node blocks redundant data from triggering subsequent nodes.

![Filter node configuration](https://flowfuse.com/blog/2023/05/images/integrating-modbus-12.png "Filter node configuration")

The function node, “modbusMapArray,” creates messages that are much more user-friendly in the Node-RED environment.

![Modbus function node](https://flowfuse.com/blog/2023/05/images/integrating-modbus-1.png "Modbus function node")

Quick tip: If your PLC environment has limits on the number of addresses allowed and you want to read a lot of coils, you can work with registers bitwise and stuff 16 coils into one register.

### Reading Data Types

No matter what data type the PLC is sending over Modbus, it’s going to be sent using the 16-bit registers. For example, to send 1234.5678 as a 32-bit Float (little-endian), the payload from the PLC will be a seemingly unhelpful array, [21035,17562]. I can simulate this with the [Productivity Suite Programming Software](https://www.automationdirect.com/adc/overview/catalog/software_products/programmable_controller_software/productivity_suite_programming_software){rel="&#x22;nofollow&#x22;"} from Automation Direct set to simulator mode. Below, I have created a 32-bit float “Tag,” named “mySampleFloat32,” using modbus registers 40001 and 40002, and set the “Init Value” to 1234.5678.

![Productivity Suite Programming Software](https://flowfuse.com/blog/2023/05/images/integrating-modbus-11.png "Productivity Suite Programming Software")

Node-RED is typically used at a much higher level, but luckily there is still a way to work with this low-level data. Node-RED uses the Buffer Class to work with this type of data stream, but it’s a little tricky. First the 16-bit registers have to be broken into 8-bit chunks, here we use msg.responseBuffer.buffer to retrieve each octet. Once our buffer is properly filled, there are many built-in functions to reconstruct the data into the actual number you are looking for.

![Using msg.responseBuffer.buffer to retrieve each octet](https://flowfuse.com/blog/2023/05/images/integrating-modbus-4.png "Using msg.responseBuffer.buffer to retrieve each octet")

Notice below that to read these 2 registers at 400001 and 400002 I have set my Modbus-Read node to start at “Address” 0 and ready “Quantity” 2 registers. Unfortunately, there are two different standards for writing Modbus addresses and my PLC uses the traditional convention (400001 to 465536) and this Modbus node uses the hexadecimal convention (4x0000 to 4xFFFF).

![Modbus node configuration](https://flowfuse.com/blog/2023/05/images/integrating-modbus-8.png "Modbus node configuration")

In this example the byte order from msg.responseBuffer.buffer doesn’t quite match the data type, so we have to rebuild the buffer.

![Mapping the data in a function node](https://flowfuse.com/blog/2023/05/images/integrating-modbus-13.png "Mapping the data in a function node")

Amazingly after all that work we get the response: 1234.5677490234375. This is the shortcoming of the 32-bit float data type. Although it can handle a huge range of values, they aren’t very accurate. For this reason, many times PLCs will send a number as an integer, say 12345678, and the documentation will prescribe 4 decimal place accuracy to bring the number back to 1234.5678. Find out more ways to work with a Buffer at <https://nodejs.org/dist/latest-v10.x/docs/api/buffer.html>{rel="&#x22;nofollow&#x22;"}.

### General Architecture

Although you can off-load some of the higher-level logic from the PLC into Node-RED, it’s important to remember that Node-RED augments, but doesn’t create a replacement for a PLC’s IDE and the IEC 61131-3 suite of languages. Make a conscious distinction between the type of work the PLC should handle and what you expect from Node-RED. Any real-time responses to inputs should strictly be handled by the PLC.

### Security

Connecting Node-RED to your PLC also creates a larger attack surface for cyber threats. Make sure that you follow the guidelines found on the Node-RED.org site at [Securing Node-RED](https://nodered.org/docs/user-guide/runtime/securing-node-red){rel="&#x22;nofollow&#x22;"}. Node-RED’s strength is its ability to make connections where they weren’t possible before, but this can be taken advantage of by a hacker. For instance, maybe it’s tempting to make Node-RED a transparent gateway and make a RESTful API fully exposing a modbus-flex-write node. This is amazingly easy and powerful with Node-RED, but anyone who can access your IP could send `http://<yourIP>:1880/careful?value=true&fc=15&unitid=1&address=0&quantity=10` and remotely turn on and off whatever they wanted.

![Example endpoint flow](https://flowfuse.com/blog/2023/05/images/integrating-modbus-6.png "Example endpoint flow")

Instead, a better practice would be to more narrowly define what you want to accomplish and only allow Node-RED to do exactly that. In this case you might send `http://<yourIP>:1880/honkTheLunchHorn?honk=true`

![Locking down the endpoint](https://flowfuse.com/blog/2023/05/images/integrating-modbus-2.png "Locking down the endpoint")

### Final Thoughts

If not done right, there could be some hard lessons, so it’s best to monitor the processes to help track down bugs. Add a log, keep your eyes out, and as a community let’s work to create stable systems.

[Opto 22 customers rely on this same Node-RED-to-Modbus pattern in production](https://flowfuse.com/customer-stories/opto22-embraces-node-red/), transforming Modbus registry data from groov EPIC controllers into human-readable, contextual data for other applications.

![Logging failures](https://flowfuse.com/blog/2023/05/images/integrating-modbus-9.png "Logging failures")

How readily upper management gives an “okay” to this new technology comes with how well it is implemented. There will be some growing pains, but by the end, you will have supercharged your plant, bringing it into the 21st century.


# Node-RED Community Survey Results

The Node-RED community recently published the results of their [2023 Community Survey](https://nodered.org/about/community/survey/2023/){rel="&#x22;nofollow&#x22;"}, building upon their [2019 survey](https://nodered.org/about/community/survey/2019/){rel="&#x22;nofollow&#x22;"}. The findings reveal some interesting trends within the Node-RED community that are worth highlighting.

1. **Passionate and Experienced Community**. The Node-RED community has shown a remarkable increase in experience. In 2019, only 28.3% of users had been utilizing Node-RED for over two years. However, in 2023, this number has grown to an impressive 65.2%. This indicates that Node-RED has become a go-to tool for many individuals, demonstrating their continued loyalty to the platform. Moreover, the community highly regards Node-RED, with 94% of respondents rating it as a 4 or 5 on a scale of 1 to 5. :br Developer tools can fall out of fashion but it is clear Node-RED is providing value and is being used by developers.
2. **Increasing Adoption in Industrial and Manufacturing Automation**. The survey also revealed a significant increase in Node-RED usage within the manufacturing and industrial automation industries. Several data points support this finding, including a rise from 31.5% to 40.3% in respondents identifying themselves as working in the manufacturing industry. Additionally, there has been an increase in the use of Node-RED applications for Industrial IoT/PLC devices, which grew from 24% to 35.8% in 2023. Furthermore, the adoption of popular manufacturing industry protocols like [OPC-UA](https://opcfoundation.org/){rel="&#x22;nofollow&#x22;"} and [Modbus](https://modbus.org/){rel="&#x22;nofollow&#x22;"} has also increased, with OPC-UA usage rising from 9.3% to 16.7% and Modbus usage increasing from 15.8% to 27.6%.
3. **InfluxDB dominance in the Node-RED community**.[ InfluxDB](https://www.influxdata.com/){rel="&#x22;nofollow&#x22;"} has emerged as the leading database within the Node-RED community. Its usage has grown significantly, from 24.2% in 2019 to 43.9% in 2023. On the other hand, MySQL, the next most popular database, experienced a slight decrease in usage, dropping from 32.4% to 31.4%. :br It is evident that the MING stack (MQTT/Mosquitto, InfluxDB, Node-RED, and Grafana) is gaining momentum and becoming a preferred choice for developers.
4. **Limitations to Node-RED Adoption**. This year's survey also explored factors that might limit the adoption of Node-RED. Approximately 27.9% of respondents stated that they perceived no additional need for Node-RED. However, the next most common responses were related to the perception that Node-RED is only suitable for proof-of-concept (POC) projects (19.9%), the lack of specific Node-RED features (13.3%), and the absence of professional support (10.1%). :br It is important for the Node-RED community to demonstrate the platform's usage in production environments. Although changing the perception of Node-RED as solely a POC tool may take time, FlowFuse is committed to helping shift this perspective. Moreover, FlowFuse aims to address other identified issues by developing the FlowFuse platform, which will provide the necessary features to create reliable, secure, and dependable Node-RED applications. FlowFuse will also offer professional support to all its customers, ensuring that users have the assistance they need.

Thank you to everyone that completed the Node-RED Survey. The insights from the survey will help the community to build a better Node-RED. Check out the detailed results on the [nodered.org website](https://nodered.org/about/community/survey/2023/){rel="&#x22;nofollow&#x22;"}.


# Persisting chart data in Node-RED Dashboard 1

Node-RED makes it easy to create HMI (Human Machine Interfaces) using [Node-RED Dashboard](https://flows.nodered.org/node/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.

One of the most useful features of Dashboard 1 is the ability to store historic data passed to a chart within the chart node itself. This makes your flows far simpler than would be the case if you needed to send the entire data set to the chart for each update.

::div{.blog-update-notes}
**UPDATE:** Since this article was published, Node-RED Dashboard (1.0) has been [deprecated](https://discourse.nodered.org/t/announcement-node-red-dashboard-v1-deprecation-notice/89006).

Instead, it is recommended to use [FlowFuse Dashboard (Dashboard 2.0)](https://dashboard.flowfuse.com/) which is a more modern and feature-rich dashboard solution for Node-RED.
::

### The Importance of Persisting Chart Data

Storing the data in the chart node is fine to show prototypes of HMIs, but where it's vital the correct data is always shown we are going to need a backup. Data can easily be lost when you move your flow to a new device, restart your instance, or simply when upgrading Node-RED.

How can we store our chart data so we can be confident it will be there each time a user views your HMI?

### Example Dashboard

In this example, we are passing in a random number between one and 10 each second. With each new value received the chart updates and as mentioned about, the values are also stored in the chart node.

If you'd like to see and edit the flows I've created, you can copy and paste the JSON below into your Node-RED import feature.

::render-flow
```json
[{"id":"c6825b1001216b89","type":"inject","z":"668c56888fd0f960","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":110,"y":220,"wires":[["6b609d978540fb2a"]]},{"id":"6b609d978540fb2a","type":"Number","z":"668c56888fd0f960","name":"Random Number","minimum":"1","maximum":"10","roundTo":"0","Floor":true,"x":270,"y":220,"wires":[["794846db6dc8cef8"]]},{"id":"794846db6dc8cef8","type":"ui_chart","z":"668c56888fd0f960","name":"","group":"af1535b39b74f94a","order":0,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"3600","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":430,"y":220,"wires":[["ad53848ee4b0d91e"]]},{"id":"ad53848ee4b0d91e","type":"debug","z":"668c56888fd0f960","name":"debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":550,"y":220,"wires":[]},{"id":"af1535b39b74f94a","type":"ui_group","name":"Example","tab":"14f1442eb7525190","order":1,"disp":true,"width":"6","collapse":false,"className":""},{"id":"14f1442eb7525190","type":"ui_tab","name":"Home","icon":"dashboard","disabled":false,"hidden":false}]
```
::

x

### How can we store and recall the chart data?

The chart node has a really useful feature which allows us to access all the data currently shown in the chart. Each time the chart receives new data, it's added to the existing values then the whole data set is sent out the outbound port of the chart node.

Now that we have a way to easily access the chart data in a single payload, we next need to store that data somewhere safer. I'm going to explain 3 potential solutions, which I use on a regular basis.

#### 1. Node-RED file-out and file-in nodes

Node-RED can read and write data to a local filesystem. Being that we already have the chart data in a single payload, we just need to write that payload to a file for later use, which we can do using the file-out node.

This example flow shows how to use the file-out node to write the chart data to your local filesystem.

::render-flow
```json
[{"id":"ead9df683d29fb8a","type":"inject","z":"668c56888fd0f960","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":110,"y":560,"wires":[["ef5359b8bd3f78b3"]]},{"id":"ef5359b8bd3f78b3","type":"Number","z":"668c56888fd0f960","name":"Random Number","minimum":"1","maximum":"10","roundTo":"0","Floor":true,"x":270,"y":560,"wires":[["69ad440cd8d1ce30"]]},{"id":"69ad440cd8d1ce30","type":"ui_chart","z":"668c56888fd0f960","name":"","group":"af1535b39b74f94a","order":0,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"3600","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":430,"y":560,"wires":[["e4e7758028477505","d9d6a2e34767f568"]]},{"id":"e4e7758028477505","type":"debug","z":"668c56888fd0f960","name":"debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":550,"y":560,"wires":[]},{"id":"d9d6a2e34767f568","type":"json","z":"668c56888fd0f960","name":"","property":"payload","action":"","pretty":false,"x":550,"y":600,"wires":[["b5b020fb17f615df"]]},{"id":"b5b020fb17f615df","type":"file","z":"668c56888fd0f960","name":"","filename":"example.json","filenameType":"str","appendNewline":true,"createDir":false,"overwriteFile":"true","encoding":"none","x":690,"y":600,"wires":[["a6d9eab41d4dcf97"]]},{"id":"a6d9eab41d4dcf97","type":"debug","z":"668c56888fd0f960","name":"debug 92","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":840,"y":600,"wires":[]},{"id":"af1535b39b74f94a","type":"ui_group","name":"Example","tab":"14f1442eb7525190","order":1,"disp":true,"width":"6","collapse":false,"className":""},{"id":"14f1442eb7525190","type":"ui_tab","name":"Home","icon":"dashboard","disabled":false,"hidden":false}]
```
::

As the chart node sends the full data set each time new data is added, we overwrite the content of the file rather than append the new values.

The next step is to pull the data back from the filesystem to your Node-RED instance. Node-RED makes this very easy using the file-in node.

::render-flow
```json
[{"id":"ead9df683d29fb8a","type":"inject","z":"668c56888fd0f960","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":110,"y":560,"wires":[["ef5359b8bd3f78b3"]]},{"id":"ef5359b8bd3f78b3","type":"Number","z":"668c56888fd0f960","name":"Random Number","minimum":"1","maximum":"10","roundTo":"0","Floor":true,"x":270,"y":560,"wires":[["69ad440cd8d1ce30"]]},{"id":"69ad440cd8d1ce30","type":"ui_chart","z":"668c56888fd0f960","name":"","group":"af1535b39b74f94a","order":0,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"3600","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":430,"y":560,"wires":[["e4e7758028477505","d9d6a2e34767f568"]]},{"id":"e4e7758028477505","type":"debug","z":"668c56888fd0f960","name":"debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":550,"y":560,"wires":[]},{"id":"d9d6a2e34767f568","type":"json","z":"668c56888fd0f960","name":"","property":"payload","action":"","pretty":false,"x":550,"y":600,"wires":[["b5b020fb17f615df"]]},{"id":"b5b020fb17f615df","type":"file","z":"668c56888fd0f960","name":"","filename":"example.json","filenameType":"str","appendNewline":true,"createDir":false,"overwriteFile":"true","encoding":"none","x":690,"y":600,"wires":[["a6d9eab41d4dcf97"]]},{"id":"a6d9eab41d4dcf97","type":"debug","z":"668c56888fd0f960","name":"debug 92","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":840,"y":600,"wires":[]},{"id":"e9cb9350f1aaeb38","type":"inject","z":"668c56888fd0f960","name":"import data","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":110,"y":660,"wires":[["600f014947f73d8f"]]},{"id":"600f014947f73d8f","type":"file in","z":"668c56888fd0f960","name":"","filename":"example.json","filenameType":"str","format":"utf8","chunk":false,"sendError":false,"encoding":"none","allProps":false,"x":270,"y":660,"wires":[["972118c0e114f47b","69ad440cd8d1ce30"]]},{"id":"972118c0e114f47b","type":"debug","z":"668c56888fd0f960","name":"debug 93","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":420,"y":660,"wires":[]},{"id":"af1535b39b74f94a","type":"ui_group","name":"Example","tab":"14f1442eb7525190","order":1,"disp":true,"width":"6","collapse":false,"className":""},{"id":"14f1442eb7525190","type":"ui_tab","name":"Home","icon":"dashboard","disabled":false,"hidden":false}]
```
::

When you press the 'import data' trigger node, the data is loaded in from the filesystem and shown in the chart. You may want to automate that task to run each you deploy your Node-RED instance.

![Import data on deploy](https://flowfuse.com/blog/2023/05/images/inject-on-deploy.png "Import data on deploy")

Bear in mind that your data is stored in your filesystem, if your storage drive fails you will lose your data, you might want to consider taking backups and storing elsewhere for emergencies.

#### 2. FlowFuse's persistent context

FlowFuse Cloud and premium self hosted version provides persistent context storage as part of its Node-RED instances. This allows you to create, read, update, and delete data as needed, even if you have restarted a Node-RED instance.

This flow shows chart data being sent to persistent context so we can access it later. The process is very similar to using the file-out and file-in nodes.

::render-flow
```json
[{"id":"c6825b1001216b89","type":"inject","z":"4767c2f7095bee53","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":170,"y":100,"wires":[["6b609d978540fb2a"]]},{"id":"794846db6dc8cef8","type":"ui_chart","z":"4767c2f7095bee53","name":"","group":"af1535b39b74f94a","order":0,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"3600","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":490,"y":100,"wires":[["ad53848ee4b0d91e","938c7d878545e623"]]},{"id":"ad53848ee4b0d91e","type":"debug","z":"4767c2f7095bee53","name":"debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":610,"y":100,"wires":[]},{"id":"6b609d978540fb2a","type":"Number","z":"4767c2f7095bee53","name":"Random Number","minimum":"1","maximum":"10","roundTo":"0","Floor":true,"x":330,"y":100,"wires":[["794846db6dc8cef8"]]},{"id":"938c7d878545e623","type":"change","z":"4767c2f7095bee53","name":"","rules":[{"t":"set","p":"#:(persistent)::chart-data","pt":"global","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":660,"y":140,"wires":[["3792cc96a748e75a"]]},{"id":"3792cc96a748e75a","type":"debug","z":"4767c2f7095bee53","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":840,"y":140,"wires":[]},{"id":"af1535b39b74f94a","type":"ui_group","name":"Example","tab":"14f1442eb7525190","order":1,"disp":true,"width":"6","collapse":false,"className":""},{"id":"14f1442eb7525190","type":"ui_tab","name":"Home","icon":"dashboard","disabled":false,"hidden":false}]
```
::

We now need to have a method to load the data back into our chart. We will again use a manual 'import data' trigger to load the full set of data from the persistent context, and then push it back into the chart.

::render-flow
```json
[{"id":"c6825b1001216b89","type":"inject","z":"4767c2f7095bee53","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":170,"y":100,"wires":[["6b609d978540fb2a"]]},{"id":"794846db6dc8cef8","type":"ui_chart","z":"4767c2f7095bee53","name":"","group":"af1535b39b74f94a","order":0,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"3600","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":490,"y":100,"wires":[["ad53848ee4b0d91e","938c7d878545e623"]]},{"id":"ad53848ee4b0d91e","type":"debug","z":"4767c2f7095bee53","name":"debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":610,"y":100,"wires":[]},{"id":"6b609d978540fb2a","type":"Number","z":"4767c2f7095bee53","name":"Random Number","minimum":"1","maximum":"10","roundTo":"0","Floor":true,"x":330,"y":100,"wires":[["794846db6dc8cef8"]]},{"id":"938c7d878545e623","type":"change","z":"4767c2f7095bee53","name":"","rules":[{"t":"set","p":"#:(persistent)::chart-data","pt":"global","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":660,"y":140,"wires":[["3792cc96a748e75a"]]},{"id":"3792cc96a748e75a","type":"debug","z":"4767c2f7095bee53","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":840,"y":140,"wires":[]},{"id":"3379276c77b4691c","type":"inject","z":"4767c2f7095bee53","name":"import data","props":[],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":150,"y":180,"wires":[["ddd1ef41321fb4a6"]]},{"id":"ddd1ef41321fb4a6","type":"change","z":"4767c2f7095bee53","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"#:(persistent)::chart-data","tot":"global"}],"action":"","property":"","from":"","to":"","reg":false,"x":320,"y":180,"wires":[["794846db6dc8cef8","fa65b958e34bc971"]]},{"id":"fa65b958e34bc971","type":"debug","z":"4767c2f7095bee53","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":480,"y":180,"wires":[]},{"id":"af1535b39b74f94a","type":"ui_group","name":"Example","tab":"14f1442eb7525190","order":1,"disp":true,"width":"6","collapse":false,"className":""},{"id":"14f1442eb7525190","type":"ui_tab","name":"Home","icon":"dashboard","disabled":false,"hidden":false}]
```
::

You may have noticed that when we are pushing duplicate data into the chart it automatically checks to see if the data is already stored. If the data points are already in the chart the new data is disregard. This saves us writing an extra section of the flow to delete the data before we load it in.

#### 3. Expose the data via an API then manually import it

In some cases you may want to copy your chart data to somewhere outside of your Node-RED instances. You can do this by creating a simple API which allows an outside system to request the chart data. You can also manually go to the URL of the API in a web browser to get your data. This example flow allows a user or system to access the chart data via a URL.

::render-flow
```json
[{"id":"6523e86042252710","type":"inject","z":"4767c2f7095bee53","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":150,"y":540,"wires":[["d51aba5f9a808592"]]},{"id":"427c60f2c4f523b7","type":"ui_chart","z":"4767c2f7095bee53","name":"","group":"af1535b39b74f94a","order":0,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"3600","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":470,"y":540,"wires":[["ba84cd1820120139","d9087436f4769691"]]},{"id":"ba84cd1820120139","type":"debug","z":"4767c2f7095bee53","name":"debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":590,"y":540,"wires":[]},{"id":"d51aba5f9a808592","type":"Number","z":"4767c2f7095bee53","name":"Random Number","minimum":"1","maximum":"10","roundTo":"0","Floor":true,"x":310,"y":540,"wires":[["427c60f2c4f523b7"]]},{"id":"d9087436f4769691","type":"change","z":"4767c2f7095bee53","name":"","rules":[{"t":"set","p":"chart-data","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":630,"y":580,"wires":[[]]},{"id":"4dd97b29430ad2ba","type":"http in","z":"4767c2f7095bee53","name":"","url":"/data","method":"get","upload":false,"swaggerDoc":"","x":200,"y":640,"wires":[["b4f0eb085cc91834"]]},{"id":"7ca49e5465699355","type":"http response","z":"4767c2f7095bee53","name":"","statusCode":"","headers":{},"x":670,"y":640,"wires":[]},{"id":"b4f0eb085cc91834","type":"change","z":"4767c2f7095bee53","name":"Get the chart data from flow.chart-data","rules":[{"t":"set","p":"payload","pt":"msg","to":"chart-data","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":440,"y":640,"wires":[["7ca49e5465699355"]]},{"id":"af1535b39b74f94a","type":"ui_group","name":"Example","tab":"14f1442eb7525190","order":1,"disp":true,"width":"6","collapse":false,"className":""},{"id":"14f1442eb7525190","type":"ui_tab","name":"Home","icon":"dashboard","disabled":false,"hidden":false}]
```
::

We can now access the data by simply visiting the URL of the API.

![The chart data accessed via the API in a web browser](https://flowfuse.com/blog/2023/05/images/data-in-browser.png "The chart data accessed via the API in a web browser")

Bear in mind that you should secure the API as appropriate for the data. If you don't put security around the API, anyone on the same network as your Node-RED instance can access your chart data. Potentially that could give access to our data to the whole internet, so where needed take steps to keep your data safe. You can read more about securing Node-RED in our [blog post here](https://flowfuse.com/blog/2023/04/securing-node-red-in-production/).

We now need to get that data back into a Node-RED instance. We can do that by editing a node and pasting in the data we got from the API. The flow below shows where you can paste in your data, you will then need to deploy and manually trigger 'import data'.

![Inject the data in JSON format](https://flowfuse.com/blog/2023/05/images/inject-the-json.png "Inject the data in JSON format")

::render-flow
```json
[{"id":"6523e86042252710","type":"inject","z":"4767c2f7095bee53","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":150,"y":540,"wires":[["d51aba5f9a808592"]]},{"id":"427c60f2c4f523b7","type":"ui_chart","z":"4767c2f7095bee53","name":"","group":"af1535b39b74f94a","order":0,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"3600","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":470,"y":540,"wires":[["ba84cd1820120139","d9087436f4769691"]]},{"id":"ba84cd1820120139","type":"debug","z":"4767c2f7095bee53","name":"debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":590,"y":540,"wires":[]},{"id":"d51aba5f9a808592","type":"Number","z":"4767c2f7095bee53","name":"Random Number","minimum":"1","maximum":"10","roundTo":"0","Floor":true,"x":310,"y":540,"wires":[["427c60f2c4f523b7"]]},{"id":"d9087436f4769691","type":"change","z":"4767c2f7095bee53","name":"","rules":[{"t":"set","p":"chart-data","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":630,"y":580,"wires":[[]]},{"id":"4dd97b29430ad2ba","type":"http in","z":"4767c2f7095bee53","name":"","url":"/data","method":"get","upload":false,"swaggerDoc":"","x":200,"y":660,"wires":[["b4f0eb085cc91834"]]},{"id":"7ca49e5465699355","type":"http response","z":"4767c2f7095bee53","name":"","statusCode":"","headers":{},"x":670,"y":660,"wires":[]},{"id":"b4f0eb085cc91834","type":"change","z":"4767c2f7095bee53","name":"Get the chart data from flow.chart-data","rules":[{"t":"set","p":"payload","pt":"msg","to":"chart-data","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":440,"y":660,"wires":[["7ca49e5465699355"]]},{"id":"d13d16b33ec638b2","type":"inject","z":"4767c2f7095bee53","name":"import data","props":[{"p":"payload"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"[{\"series\":[\"\"],\"data\":[[{\"x\":1684841975036,\"y\":8},{\"x\":1684841976037,\"y\":6},{\"x\":1684841977038,\"y\":7},{\"x\":1684841978037,\"y\":7}]],\"labels\":[\"\"]}]","payloadType":"json","x":170,"y":600,"wires":[["427c60f2c4f523b7"]]},{"id":"af1535b39b74f94a","type":"ui_group","name":"Example","tab":"14f1442eb7525190","order":1,"disp":true,"width":"6","collapse":false,"className":""},{"id":"14f1442eb7525190","type":"ui_tab","name":"Home","icon":"dashboard","disabled":false,"hidden":false}]
```
::

Each of these solutions has strengths and weaknesses but there are many other ways to persist your chart data. You should consider which approach is the best fit for your needs. To be as confident as possible that you data is safe, you may decide to push your data to dedicate external storage such as a database or backup solution.

### Conclusion

Node-RED Dashboard 1 allows you to easily make informative HMIs, but it's important to make sure the chart data you are showing is stored safely. The approaches we have discussed above should give you a good start in ensuring your charts are populated with the correct data, even if your Node-RED instance crashes or you need to move it to a new hosting location.


# Node-RED Tips - Dashboard Edition

There is usually more than one way to complete a given task in software, and Node-RED is no exception. In each of this series of blog posts, we are going to share three useful tips to save yourself time when working on your flows.

In this Node-RED Tips article, we are going to focus on [Node-RED Dashboard](https://flows.nodered.org/node/node-red-dashboard){rel="&#x22;nofollow&#x22;"}. Dashboard is a great tool for creating HMI (Human Machine Interfaces), it's also the most popular custom node for Node-RED with thousands of downloads per week.

### 1. Responsive layouts (almost)

Responsive design is the ability for a webpage to change its content to best fit the features of a device used to view the page. For example, when viewing a graph on a mobile phone or a laptop the available screen space differs significantly in size as well as aspect-ratio.

Dashboard doesn't offer the feature to change graph sizes based on the screen of a viewing device. That being said, there is one trick you can use to make your dashboards a lot more useful on small and large screens alike.

Place your content into Dashboard 'groups', those groups can make use of wider screens by sitting side by side where the screen is big enough while stacking vertically on smaller devices.

The image below shows what happens when you change the screen size for this dashboard.

:video{ariaLabel="Changing the aspect ratio of the screen" autoPlay="true" height="437" loop="true" muted="true" playsInline="true" preload="none" width="600"}

If you'd like to try this out on your own Node-RED, you can import the flow below.

::render-flow{:height='500'}
```json
[{"id":"e351b1251dfbc2f7","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"d388b48fcbed93a1","type":"ui_gauge","z":"e351b1251dfbc2f7","name":"","group":"ba1ff527abfa5261","order":2,"width":0,"height":0,"gtype":"gage","title":"gauge","label":"units","format":"{{value}}","min":0,"max":"100","colors":["#00b500","#e6e600","#ca3838"],"seg1":"","seg2":"","diff":false,"className":"","x":350,"y":80,"wires":[]},{"id":"80780894450cfb6d","type":"ui_button","z":"e351b1251dfbc2f7","name":"","group":"ba1ff527abfa5261","order":1,"width":0,"height":0,"passthru":false,"label":"Update","tooltip":"","color":"","bgcolor":"","className":"","icon":"","payload":"","payloadType":"str","topic":"topic","topicType":"msg","x":80,"y":80,"wires":[["49e78ff51c3a1ea3"]]},{"id":"07b44990e5d5b5f6","type":"ui_chart","z":"e351b1251dfbc2f7","name":"","group":"ba1ff527abfa5261","order":3,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"60","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":350,"y":120,"wires":[[]]},{"id":"1482bcf69325aa92","type":"inject","z":"e351b1251dfbc2f7","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":90,"y":120,"wires":[["49e78ff51c3a1ea3"]]},{"id":"49e78ff51c3a1ea3","type":"random","z":"e351b1251dfbc2f7","name":"","low":"0","high":"100","inte":"true","property":"payload","x":220,"y":100,"wires":[["d388b48fcbed93a1","07b44990e5d5b5f6"]]},{"id":"38996d8eb9f6535d","type":"ui_gauge","z":"e351b1251dfbc2f7","name":"","group":"f6052a3dccc77ea3","order":2,"width":0,"height":0,"gtype":"gage","title":"gauge","label":"units","format":"{{value}}","min":0,"max":"100","colors":["#00b500","#e6e600","#ca3838"],"seg1":"","seg2":"","diff":false,"className":"","x":350,"y":240,"wires":[]},{"id":"cf5599fbda28e614","type":"ui_button","z":"e351b1251dfbc2f7","name":"","group":"f6052a3dccc77ea3","order":1,"width":0,"height":0,"passthru":false,"label":"Update","tooltip":"","color":"","bgcolor":"","className":"","icon":"","payload":"","payloadType":"str","topic":"topic","topicType":"msg","x":80,"y":240,"wires":[["f093c63e17a620ba"]]},{"id":"936438ebf9eef986","type":"ui_chart","z":"e351b1251dfbc2f7","name":"","group":"f6052a3dccc77ea3","order":3,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"60","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":350,"y":280,"wires":[[]]},{"id":"60a40faa335f943e","type":"inject","z":"e351b1251dfbc2f7","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":90,"y":280,"wires":[["f093c63e17a620ba"]]},{"id":"f093c63e17a620ba","type":"random","z":"e351b1251dfbc2f7","name":"","low":"0","high":"100","inte":"true","property":"payload","x":220,"y":260,"wires":[["38996d8eb9f6535d","936438ebf9eef986"]]},{"id":"e284b90164e648e6","type":"ui_gauge","z":"e351b1251dfbc2f7","name":"","group":"1e4a72d62ed7564c","order":2,"width":0,"height":0,"gtype":"gage","title":"gauge","label":"units","format":"{{value}}","min":0,"max":"100","colors":["#00b500","#e6e600","#ca3838"],"seg1":"","seg2":"","diff":false,"className":"","x":350,"y":380,"wires":[]},{"id":"cabe7a8150dbfaf6","type":"ui_button","z":"e351b1251dfbc2f7","name":"","group":"1e4a72d62ed7564c","order":1,"width":0,"height":0,"passthru":false,"label":"Update","tooltip":"","color":"","bgcolor":"","className":"","icon":"","payload":"","payloadType":"str","topic":"topic","topicType":"msg","x":80,"y":380,"wires":[["7b9862186954c4b3"]]},{"id":"ac116116c56e6c3c","type":"ui_chart","z":"e351b1251dfbc2f7","name":"","group":"1e4a72d62ed7564c","order":3,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"60","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":350,"y":420,"wires":[[]]},{"id":"bb27ef41380ec1d2","type":"inject","z":"e351b1251dfbc2f7","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":90,"y":420,"wires":[["7b9862186954c4b3"]]},{"id":"7b9862186954c4b3","type":"random","z":"e351b1251dfbc2f7","name":"","low":"0","high":"100","inte":"true","property":"payload","x":220,"y":400,"wires":[["e284b90164e648e6","ac116116c56e6c3c"]]},{"id":"e891f555bad51f01","type":"ui_gauge","z":"e351b1251dfbc2f7","name":"","group":"fcc4481a9e329266","order":2,"width":0,"height":0,"gtype":"gage","title":"gauge","label":"units","format":"{{value}}","min":0,"max":"100","colors":["#00b500","#e6e600","#ca3838"],"seg1":"","seg2":"","diff":false,"className":"","x":350,"y":500,"wires":[]},{"id":"fa090cd1a0e97885","type":"ui_button","z":"e351b1251dfbc2f7","name":"","group":"fcc4481a9e329266","order":1,"width":0,"height":0,"passthru":false,"label":"Update","tooltip":"","color":"","bgcolor":"","className":"","icon":"","payload":"","payloadType":"str","topic":"topic","topicType":"msg","x":80,"y":500,"wires":[["bb4e945a2a8e681c"]]},{"id":"1c3a8aa84dfc85fe","type":"ui_chart","z":"e351b1251dfbc2f7","name":"","group":"fcc4481a9e329266","order":3,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"60","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":350,"y":540,"wires":[[]]},{"id":"796f79538c15dd66","type":"inject","z":"e351b1251dfbc2f7","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":90,"y":540,"wires":[["bb4e945a2a8e681c"]]},{"id":"bb4e945a2a8e681c","type":"random","z":"e351b1251dfbc2f7","name":"","low":"0","high":"100","inte":"true","property":"payload","x":220,"y":520,"wires":[["e891f555bad51f01","1c3a8aa84dfc85fe"]]},{"id":"ba1ff527abfa5261","type":"ui_group","name":"Machine 1","tab":"39383a7a648193dd","order":1,"disp":true,"width":"6","collapse":false,"className":""},{"id":"f6052a3dccc77ea3","type":"ui_group","name":"Machine 2","tab":"39383a7a648193dd","order":2,"disp":true,"width":"6","collapse":false,"className":""},{"id":"1e4a72d62ed7564c","type":"ui_group","name":"Machine 3","tab":"39383a7a648193dd","order":3,"disp":true,"width":"6","collapse":false,"className":""},{"id":"fcc4481a9e329266","type":"ui_group","name":"Machine 4","tab":"39383a7a648193dd","order":4,"disp":true,"width":"6","collapse":false,"className":""},{"id":"39383a7a648193dd","type":"ui_tab","name":"Node-RED Tips","icon":"dashboard","disabled":false,"hidden":false}]
```
::

### 2. Add more than one series of data to a line chart

Being able to add more than one series of data to a single chart can make the data far more useful. One great way to use this is to compare the same data from different sensors. In this example I'm going to show the external and internal temperature at a location on the same chart.

![Graphing two series on the same line chart](https://flowfuse.com/blog/2023/06/images/temp-graph.png "Graphing two series on the same line chart")

To do this you need to give a different msg.topic to each series, you can add that using a change node before passing the data to the chart.

If you'd like to view this chart on your own Node-RED, you can import the flow below.

::render-flow
```json
[{"id":"3eb08d4843164efc","type":"ui_chart","z":"58569b35dacd54f3","name":"","group":"41e847ff22249c0e","order":3,"width":"12","height":"5","label":"Celsius","chartType":"line","legend":"true","xformat":"dd HH:mm","interpolate":"linear","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":1,"removeOlderPoints":"","removeOlderUnit":"604800","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"outputs":1,"useDifferentColor":false,"className":"","x":280,"y":180,"wires":[[]]},{"id":"c4a13220356f76d3","type":"inject","z":"58569b35dacd54f3","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"[{\"series\":[\"inside\",\"outside\"],\"data\":[[{\"x\":1685015544647,\"y\":20.8},{\"x\":1685015844687,\"y\":20.8},{\"x\":1685016144791,\"y\":20.8},{\"x\":1685016444933,\"y\":20.8},{\"x\":1685016745032,\"y\":20.8},{\"x\":1685017045123,\"y\":20.8},{\"x\":1685017345223,\"y\":20.8},{\"x\":1685017645339,\"y\":20.8},{\"x\":1685017945424,\"y\":20.8},{\"x\":1685018245500,\"y\":20.8},{\"x\":1685018545670,\"y\":20.8},{\"x\":1685018860580,\"y\":20.8},{\"x\":1685019160814,\"y\":20.8},{\"x\":1685019460832,\"y\":20.8},{\"x\":1685019760943,\"y\":20.8},{\"x\":1685020061037,\"y\":20.8},{\"x\":1685020361249,\"y\":20.8},{\"x\":1685020661264,\"y\":20.8},{\"x\":1685020961381,\"y\":20.8},{\"x\":1685021261473,\"y\":20.8},{\"x\":1685021561721,\"y\":20.8},{\"x\":1685021876580,\"y\":20.6},{\"x\":1685022176696,\"y\":20.7},{\"x\":1685022476852,\"y\":20.8},{\"x\":1685022776957,\"y\":20.8},{\"x\":1685023077032,\"y\":20.8},{\"x\":1685023377120,\"y\":20.8},{\"x\":1685023677234,\"y\":20.8},{\"x\":1685023977339,\"y\":20.8},{\"x\":1685024277455,\"y\":20.8},{\"x\":1685024577576,\"y\":20.8},{\"x\":1685024892578,\"y\":20.8},{\"x\":1685025192616,\"y\":20.8},{\"x\":1685025492757,\"y\":20.8},{\"x\":1685025792847,\"y\":20.7},{\"x\":1685026092949,\"y\":20.8},{\"x\":1685026393052,\"y\":20.8},{\"x\":1685026693174,\"y\":20.8},{\"x\":1685026993234,\"y\":20.8},{\"x\":1685027293387,\"y\":20.8},{\"x\":1685027593514,\"y\":20.8},{\"x\":1685027908550,\"y\":20.8},{\"x\":1685028208624,\"y\":20.8},{\"x\":1685028508708,\"y\":20.8},{\"x\":1685028808828,\"y\":20.8},{\"x\":1685029108909,\"y\":20.8},{\"x\":1685029409026,\"y\":20.8},{\"x\":1685029709096,\"y\":20.8},{\"x\":1685030009262,\"y\":20.8},{\"x\":1685030309361,\"y\":20.8},{\"x\":1685030609541,\"y\":20.8},{\"x\":1685030924565,\"y\":20.8},{\"x\":1685031239588,\"y\":20.8},{\"x\":1685031539702,\"y\":20.8},{\"x\":1685031839784,\"y\":20.8},{\"x\":1685032139922,\"y\":20.8},{\"x\":1685032440027,\"y\":20.8},{\"x\":1685032740134,\"y\":20.6},{\"x\":1685033040252,\"y\":20.7},{\"x\":1685033340317,\"y\":20.5},{\"x\":1685033640450,\"y\":20.5},{\"x\":1685033940507,\"y\":20.6},{\"x\":1685034240592,\"y\":20.5},{\"x\":1685034540633,\"y\":20.4},{\"x\":1685034840784,\"y\":20.4},{\"x\":1685035140888,\"y\":20.5},{\"x\":1685035441026,\"y\":20.4},{\"x\":1685035741107,\"y\":20.5},{\"x\":1685036041205,\"y\":20.5},{\"x\":1685036341328,\"y\":20.5},{\"x\":1685036641457,\"y\":20.5},{\"x\":1685036941583,\"y\":20.4},{\"x\":1685037256578,\"y\":20.5},{\"x\":1685037556715,\"y\":20.5},{\"x\":1685037856773,\"y\":20.5},{\"x\":1685038156902,\"y\":20.5},{\"x\":1685038457023,\"y\":20.5},{\"x\":1685038757090,\"y\":20.5},{\"x\":1685039057219,\"y\":20.5},{\"x\":1685039357278,\"y\":20.5},{\"x\":1685039657449,\"y\":20.5},{\"x\":1685039957553,\"y\":20.5},{\"x\":1685040257570,\"y\":20.5},{\"x\":1685040557615,\"y\":20.5},{\"x\":1685040857735,\"y\":20.4},{\"x\":1685041157843,\"y\":20.4},{\"x\":1685041457971,\"y\":20.5},{\"x\":1685041758072,\"y\":20.5},{\"x\":1685042058154,\"y\":20.5},{\"x\":1685042358273,\"y\":20.5},{\"x\":1685042658392,\"y\":20.5},{\"x\":1685042958486,\"y\":20.6},{\"x\":1685043258518,\"y\":20.6},{\"x\":1685043558568,\"y\":20.6},{\"x\":1685043858688,\"y\":20.5},{\"x\":1685044158769,\"y\":20.5},{\"x\":1685044458908,\"y\":20.5},{\"x\":1685044758984,\"y\":20.5},{\"x\":1685045059095,\"y\":20.5},{\"x\":1685045359169,\"y\":20.5},{\"x\":1685045659320,\"y\":20.5},{\"x\":1685045959367,\"y\":20.5},{\"x\":1685046259469,\"y\":20.7},{\"x\":1685046559497,\"y\":20.6},{\"x\":1685046859589,\"y\":20.5},{\"x\":1685047159647,\"y\":20.6},{\"x\":1685047459714,\"y\":20.6},{\"x\":1685047759793,\"y\":20.7},{\"x\":1685048059921,\"y\":20.7},{\"x\":1685048359994,\"y\":20.6},{\"x\":1685048659997,\"y\":20.7},{\"x\":1685048960056,\"y\":20.7},{\"x\":1685049260070,\"y\":20.8},{\"x\":1685049560116,\"y\":20.8},{\"x\":1685049860167,\"y\":20.8},{\"x\":1685050160212,\"y\":20.8},{\"x\":1685050460281,\"y\":20.8},{\"x\":1685050760368,\"y\":20.8},{\"x\":1685051060400,\"y\":20.7},{\"x\":1685051360435,\"y\":20.8},{\"x\":1685051660553,\"y\":20.8},{\"x\":1685051960585,\"y\":20.8},{\"x\":1685052260665,\"y\":20.8},{\"x\":1685052560675,\"y\":20.8},{\"x\":1685052860700,\"y\":20.7},{\"x\":1685053160749,\"y\":20.8},{\"x\":1685053460790,\"y\":20.8},{\"x\":1685053760855,\"y\":20.7},{\"x\":1685054060931,\"y\":20.7},{\"x\":1685054361019,\"y\":20.7},{\"x\":1685054661030,\"y\":20.7},{\"x\":1685054961121,\"y\":20.7},{\"x\":1685055261227,\"y\":20.7},{\"x\":1685055576250,\"y\":20.7},{\"x\":1685055891289,\"y\":20.5},{\"x\":1685056191290,\"y\":20.6},{\"x\":1685056491397,\"y\":20.7},{\"x\":1685056791444,\"y\":20.7},{\"x\":1685057091489,\"y\":20.7},{\"x\":1685057391516,\"y\":20.7},{\"x\":1685057691607,\"y\":20.7},{\"x\":1685057991660,\"y\":20.7},{\"x\":1685058291741,\"y\":20.6},{\"x\":1685058606760,\"y\":20.5},{\"x\":1685058906775,\"y\":20.5},{\"x\":1685059206866,\"y\":20.5},{\"x\":1685059506900,\"y\":20.5},{\"x\":1685059806979,\"y\":20.4},{\"x\":1685060107035,\"y\":20.5},{\"x\":1685060407099,\"y\":20.5},{\"x\":1685060707132,\"y\":20.4},{\"x\":1685061007199,\"y\":20.5},{\"x\":1685061307220,\"y\":20.4},{\"x\":1685061607228,\"y\":20.5},{\"x\":1685061907286,\"y\":20.6},{\"x\":1685062207289,\"y\":20.7},{\"x\":1685062507315,\"y\":20.6},{\"x\":1685062807355,\"y\":20.7},{\"x\":1685063107395,\"y\":20.7},{\"x\":1685063407413,\"y\":20.7},{\"x\":1685063707465,\"y\":20.7},{\"x\":1685064007492,\"y\":20.7},{\"x\":1685064307565,\"y\":20.7},{\"x\":1685064607587,\"y\":20.7},{\"x\":1685064907609,\"y\":20.7},{\"x\":1685065207618,\"y\":20.5},{\"x\":1685065507642,\"y\":20.4},{\"x\":1685065807670,\"y\":20.4},{\"x\":1685066107679,\"y\":20.4},{\"x\":1685066407758,\"y\":20.5},{\"x\":1685066707760,\"y\":20.3},{\"x\":1685067007798,\"y\":20.4},{\"x\":1685067307865,\"y\":20.4},{\"x\":1685067622903,\"y\":20.4},{\"x\":1685067937922,\"y\":20.4},{\"x\":1685068237945,\"y\":20.4},{\"x\":1685068537971,\"y\":20.3},{\"x\":1685068838009,\"y\":20.3},{\"x\":1685069138060,\"y\":20.2},{\"x\":1685069453065,\"y\":20.3},{\"x\":1685069753104,\"y\":20.3},{\"x\":1685070053108,\"y\":20.2},{\"x\":1685070353140,\"y\":20.3},{\"x\":1685070653170,\"y\":20.2},{\"x\":1685070953219,\"y\":20.2},{\"x\":1685071253232,\"y\":20.2},{\"x\":1685071553258,\"y\":20},{\"x\":1685071853260,\"y\":20},{\"x\":1685072153324,\"y\":20.2},{\"x\":1685072453329,\"y\":20.2},{\"x\":1685072753343,\"y\":19.9},{\"x\":1685073053359,\"y\":20},{\"x\":1685073353402,\"y\":19.9},{\"x\":1685073653411,\"y\":19.9},{\"x\":1685073953453,\"y\":20},{\"x\":1685074253462,\"y\":20},{\"x\":1685074553509,\"y\":20},{\"x\":1685074853529,\"y\":20},{\"x\":1685075153554,\"y\":20},{\"x\":1685075453556,\"y\":20},{\"x\":1685075753590,\"y\":20},{\"x\":1685076053642,\"y\":20.2},{\"x\":1685076368644,\"y\":20},{\"x\":1685076668676,\"y\":20.2},{\"x\":1685076968685,\"y\":20.3},{\"x\":1685077268752,\"y\":20.3},{\"x\":1685077583729,\"y\":20.3},{\"x\":1685077883800,\"y\":20.2},{\"x\":1685078198760,\"y\":20.2},{\"x\":1685078498762,\"y\":20.4},{\"x\":1685078798782,\"y\":20.4},{\"x\":1685079098837,\"y\":20.5},{\"x\":1685079398903,\"y\":20.5},{\"x\":1685079698965,\"y\":20.6},{\"x\":1685079999013,\"y\":20.7},{\"x\":1685080299091,\"y\":20.8},{\"x\":1685080599234,\"y\":20.8},{\"x\":1685080899276,\"y\":20.8},{\"x\":1685081199340,\"y\":20.8},{\"x\":1685081499403,\"y\":20.8},{\"x\":1685081799441,\"y\":20.8},{\"x\":1685082099467,\"y\":20.9},{\"x\":1685082399584,\"y\":20.8},{\"x\":1685082699624,\"y\":21},{\"x\":1685082999670,\"y\":21},{\"x\":1685083299724,\"y\":21.2},{\"x\":1685083599810,\"y\":21.2},{\"x\":1685083899884,\"y\":21.2},{\"x\":1685084199935,\"y\":21.2},{\"x\":1685084500001,\"y\":21.3},{\"x\":1685084800063,\"y\":21.4},{\"x\":1685085115072,\"y\":21.5},{\"x\":1685085415170,\"y\":21.5},{\"x\":1685085715226,\"y\":21.5},{\"x\":1685086015289,\"y\":21.5},{\"x\":1685086315365,\"y\":21.5},{\"x\":1685086615447,\"y\":21.5},{\"x\":1685086915501,\"y\":21.7},{\"x\":1685087215603,\"y\":21.7},{\"x\":1685087515642,\"y\":21.6},{\"x\":1685087815732,\"y\":21.6},{\"x\":1685088115759,\"y\":21.7},{\"x\":1685088415793,\"y\":21.9},{\"x\":1685088715840,\"y\":21.9},{\"x\":1685089015891,\"y\":21.9},{\"x\":1685089315950,\"y\":21.9},{\"x\":1685089616045,\"y\":21.9},{\"x\":1685089916094,\"y\":21.9},{\"x\":1685090216153,\"y\":21.9},{\"x\":1685090516202,\"y\":21.9},{\"x\":1685090816299,\"y\":21.9},{\"x\":1685091116304,\"y\":22},{\"x\":1685091416326,\"y\":22},{\"x\":1685091716409,\"y\":22},{\"x\":1685092016500,\"y\":22},{\"x\":1685092316555,\"y\":21.9},{\"x\":1685092616597,\"y\":21.9},{\"x\":1685092916687,\"y\":21.9},{\"x\":1685093216749,\"y\":21.9},{\"x\":1685093516770,\"y\":21.9},{\"x\":1685093816833,\"y\":21.8},{\"x\":1685094116862,\"y\":21.8},{\"x\":1685094416941,\"y\":21.9},{\"x\":1685094717014,\"y\":21.8},{\"x\":1685095017079,\"y\":21.8},{\"x\":1685095317146,\"y\":21.9},{\"x\":1685095617198,\"y\":21.9},{\"x\":1685095917267,\"y\":22},{\"x\":1685096217380,\"y\":22},{\"x\":1685096517436,\"y\":22.2},{\"x\":1685096817481,\"y\":22.1},{\"x\":1685097117519,\"y\":21.9},{\"x\":1685097417582,\"y\":21.9},{\"x\":1685097717607,\"y\":21.9},{\"x\":1685098017734,\"y\":21.9},{\"x\":1685098317791,\"y\":21.9},{\"x\":1685098617850,\"y\":21.9},{\"x\":1685098917939,\"y\":21.9},{\"x\":1685099218020,\"y\":21.9},{\"x\":1685099518088,\"y\":21.9},{\"x\":1685099818190,\"y\":21.9},{\"x\":1685100118269,\"y\":21.9},{\"x\":1685100418304,\"y\":21.9},{\"x\":1685100718355,\"y\":21.9},{\"x\":1685101018437,\"y\":22},{\"x\":1685101318544,\"y\":22.1},{\"x\":1685101618646,\"y\":22},{\"x\":1685101918720,\"y\":22},{\"x\":1685102218803,\"y\":22},{\"x\":1685102518914,\"y\":21.9},{\"x\":1685102818997,\"y\":21.9},{\"x\":1685103119093,\"y\":21.9},{\"x\":1685103419119,\"y\":21.9},{\"x\":1685103719183,\"y\":21.9},{\"x\":1685104019263,\"y\":21.9},{\"x\":1685104319361,\"y\":21.9},{\"x\":1685104619467,\"y\":21.9},{\"x\":1685104919565,\"y\":21.9},{\"x\":1685105219692,\"y\":21.9},{\"x\":1685105261657,\"y\":21.9},{\"x\":1685105275726,\"y\":21.9},{\"x\":1685105316848,\"y\":21.9},{\"x\":1685105388676,\"y\":21.9},{\"x\":1685105475001,\"y\":21.9},{\"x\":1685105501466,\"y\":21.9},{\"x\":1685105576628,\"y\":21.9},{\"x\":1685105627162,\"y\":21.9},{\"x\":1685105653330,\"y\":21.9},{\"x\":1685105684112,\"y\":21.9},{\"x\":1685105722222,\"y\":21.9},{\"x\":1685105769629,\"y\":21.9},{\"x\":1685105825666,\"y\":21.9},{\"x\":1685105889137,\"y\":21.9},{\"x\":1685105910507,\"y\":21.9},{\"x\":1685105970749,\"y\":21.9},{\"x\":1685106270828,\"y\":21.9},{\"x\":1685106570844,\"y\":21.9},{\"x\":1685106870845,\"y\":21.9},{\"x\":1685107170872,\"y\":21.9},{\"x\":1685107485846,\"y\":21.9},{\"x\":1685107785884,\"y\":21.9},{\"x\":1685108100859,\"y\":21.9},{\"x\":1685108400859,\"y\":21.9},{\"x\":1685108700881,\"y\":21.9},{\"x\":1685109000885,\"y\":21.9},{\"x\":1685109300898,\"y\":21.9},{\"x\":1685109615915,\"y\":21.8},{\"x\":1685109930873,\"y\":21.9},{\"x\":1685110230928,\"y\":21.9},{\"x\":1685110545931,\"y\":21.7},{\"x\":1685110845948,\"y\":21.7},{\"x\":1685111145989,\"y\":21.7},{\"x\":1685111460988,\"y\":21.7},{\"x\":1685111761062,\"y\":21.8},{\"x\":1685112061067,\"y\":21.6},{\"x\":1685112361107,\"y\":21.7},{\"x\":1685112661141,\"y\":21.7},{\"x\":1685112961145,\"y\":21.8},{\"x\":1685113261191,\"y\":21.8},{\"x\":1685113561195,\"y\":21.8},{\"x\":1685113861234,\"y\":21.8},{\"x\":1685114161272,\"y\":21.8},{\"x\":1685114461288,\"y\":21.7},{\"x\":1685114761326,\"y\":21.7},{\"x\":1685115061359,\"y\":21.7},{\"x\":1685115361389,\"y\":21.7},{\"x\":1685115661413,\"y\":21.6},{\"x\":1685115961522,\"y\":21.7},{\"x\":1685116276440,\"y\":21.7},{\"x\":1685116576471,\"y\":21.5},{\"x\":1685116876500,\"y\":21.5},{\"x\":1685117176511,\"y\":21.5},{\"x\":1685117476538,\"y\":21.6},{\"x\":1685117776599,\"y\":21.6},{\"x\":1685118091580,\"y\":21.8},{\"x\":1685118391620,\"y\":21.6},{\"x\":1685118691646,\"y\":21.7},{\"x\":1685118991656,\"y\":21.7},{\"x\":1685119291661,\"y\":21.5},{\"x\":1685119591684,\"y\":21.5},{\"x\":1685119891711,\"y\":21.5},{\"x\":1685120191732,\"y\":21.5},{\"x\":1685120491763,\"y\":21.5},{\"x\":1685120791797,\"y\":21.4},{\"x\":1685121091832,\"y\":21.2},{\"x\":1685121406802,\"y\":21.2},{\"x\":1685121706853,\"y\":21.1},{\"x\":1685122021885,\"y\":21.1},{\"x\":1685122336872,\"y\":21.2},{\"x\":1685122636878,\"y\":21.2},{\"x\":1685122936903,\"y\":21.1},{\"x\":1685123236933,\"y\":21},{\"x\":1685123536988,\"y\":21},{\"x\":1685123837007,\"y\":21.1},{\"x\":1685124137007,\"y\":21},{\"x\":1685124437098,\"y\":21},{\"x\":1685124737193,\"y\":21},{\"x\":1685125037270,\"y\":21},{\"x\":1685125337370,\"y\":20.9},{\"x\":1685125637493,\"y\":20.9},{\"x\":1685125937530,\"y\":21},{\"x\":1685126237627,\"y\":20.9},{\"x\":1685126537712,\"y\":20.8},{\"x\":1685126837733,\"y\":20.8},{\"x\":1685127137746,\"y\":20.8},{\"x\":1685127437870,\"y\":20.8},{\"x\":1685127737940,\"y\":20.8},{\"x\":1685128038026,\"y\":20.8},{\"x\":1685128338109,\"y\":20.8},{\"x\":1685128638215,\"y\":20.8},{\"x\":1685128938321,\"y\":20.8},{\"x\":1685129238409,\"y\":20.8},{\"x\":1685129538484,\"y\":20.8},{\"x\":1685129838514,\"y\":20.8},{\"x\":1685130138614,\"y\":20.8},{\"x\":1685130438644,\"y\":20.8},{\"x\":1685130738716,\"y\":20.8},{\"x\":1685131038856,\"y\":20.8},{\"x\":1685131338912,\"y\":20.8},{\"x\":1685131639028,\"y\":20.8},{\"x\":1685131939140,\"y\":20.8},{\"x\":1685132239222,\"y\":20.8},{\"x\":1685132539344,\"y\":20.8},{\"x\":1685132839390,\"y\":20.8},{\"x\":1685133154381,\"y\":20.8},{\"x\":1685133454402,\"y\":20.8},{\"x\":1685133754494,\"y\":20.8},{\"x\":1685134054557,\"y\":20.8},{\"x\":1685134354644,\"y\":20.8},{\"x\":1685134654753,\"y\":20.8},{\"x\":1685134954810,\"y\":20.8},{\"x\":1685135254894,\"y\":20.7},{\"x\":1685135554961,\"y\":20.8},{\"x\":1685135854990,\"y\":20.8},{\"x\":1685136155013,\"y\":20.8},{\"x\":1685136455070,\"y\":20.8},{\"x\":1685136755172,\"y\":20.8},{\"x\":1685137055242,\"y\":20.8},{\"x\":1685137355339,\"y\":20.8},{\"x\":1685137655440,\"y\":20.7},{\"x\":1685137955504,\"y\":20.7},{\"x\":1685138255592,\"y\":20.6},{\"x\":1685138555675,\"y\":20.6},{\"x\":1685138855742,\"y\":20.6},{\"x\":1685139155750,\"y\":20.6},{\"x\":1685139455841,\"y\":20.5},{\"x\":1685139755904,\"y\":20.6},{\"x\":1685140055961,\"y\":20.5},{\"x\":1685140356100,\"y\":20.6},{\"x\":1685140656187,\"y\":20.5},{\"x\":1685140956268,\"y\":20.4},{\"x\":1685141256384,\"y\":20.4},{\"x\":1685141556467,\"y\":20.4},{\"x\":1685141856547,\"y\":20.4},{\"x\":1685142156630,\"y\":20.3},{\"x\":1685142456678,\"y\":20.2},{\"x\":1685142756713,\"y\":20.3},{\"x\":1685143056833,\"y\":20.3},{\"x\":1685143356922,\"y\":20.3},{\"x\":1685143657019,\"y\":20.3},{\"x\":1685143957116,\"y\":20.2},{\"x\":1685144257203,\"y\":20.2},{\"x\":1685144557262,\"y\":20.1},{\"x\":1685144857393,\"y\":20.2},{\"x\":1685145157511,\"y\":20.2},{\"x\":1685145457515,\"y\":20.2},{\"x\":1685145757583,\"y\":20},{\"x\":1685146057687,\"y\":20},{\"x\":1685146357780,\"y\":20.1},{\"x\":1685146657878,\"y\":19.9},{\"x\":1685146957969,\"y\":19.9},{\"x\":1685147258066,\"y\":20},{\"x\":1685147558163,\"y\":20},{\"x\":1685147858255,\"y\":19.9},{\"x\":1685148158303,\"y\":19.9},{\"x\":1685148458377,\"y\":19.9},{\"x\":1685148758392,\"y\":19.9},{\"x\":1685149058441,\"y\":19.9},{\"x\":1685149358550,\"y\":19.9},{\"x\":1685149658652,\"y\":19.5},{\"x\":1685149958735,\"y\":19.5},{\"x\":1685150258816,\"y\":19.5},{\"x\":1685150558892,\"y\":19.5},{\"x\":1685150858996,\"y\":19.5},{\"x\":1685151159109,\"y\":19.5},{\"x\":1685151459166,\"y\":19.5},{\"x\":1685151759230,\"y\":19.5},{\"x\":1685152059291,\"y\":19.5},{\"x\":1685152359350,\"y\":19.5},{\"x\":1685152659430,\"y\":19.5},{\"x\":1685152959526,\"y\":19.5},{\"x\":1685153259622,\"y\":19.5},{\"x\":1685153559728,\"y\":19.5},{\"x\":1685153859883,\"y\":19.5},{\"x\":1685154159899,\"y\":19.5},{\"x\":1685154459974,\"y\":19.5},{\"x\":1685154760016,\"y\":19.5},{\"x\":1685155060096,\"y\":19.5},{\"x\":1685155360142,\"y\":19.5},{\"x\":1685155660284,\"y\":19.5},{\"x\":1685155960372,\"y\":19.5},{\"x\":1685156260469,\"y\":19.5},{\"x\":1685156560559,\"y\":19.5},{\"x\":1685156860664,\"y\":19.5},{\"x\":1685157160732,\"y\":19.5},{\"x\":1685157460827,\"y\":19.5},{\"x\":1685157760925,\"y\":19.5},{\"x\":1685158061041,\"y\":19.4},{\"x\":1685158361093,\"y\":19.4},{\"x\":1685158661174,\"y\":19.4},{\"x\":1685158961238,\"y\":19.4},{\"x\":1685159261356,\"y\":19.4},{\"x\":1685159561460,\"y\":19.4},{\"x\":1685159861591,\"y\":19.4},{\"x\":1685160161622,\"y\":19.5},{\"x\":1685160461727,\"y\":19.4},{\"x\":1685160761798,\"y\":19.3},{\"x\":1685161061899,\"y\":19.3},{\"x\":1685161361960,\"y\":19.3},{\"x\":1685161662030,\"y\":19.3},{\"x\":1685161962083,\"y\":19.2},{\"x\":1685162262205,\"y\":19.2},{\"x\":1685162562329,\"y\":19.2},{\"x\":1685162862420,\"y\":19.2},{\"x\":1685163162514,\"y\":19.3},{\"x\":1685163462630,\"y\":19.4},{\"x\":1685163762689,\"y\":19.5},{\"x\":1685164062785,\"y\":19.5},{\"x\":1685164362862,\"y\":19.5},{\"x\":1685164662929,\"y\":19.5},{\"x\":1685164962989,\"y\":19.5},{\"x\":1685165263080,\"y\":19.5},{\"x\":1685165563213,\"y\":19.5},{\"x\":1685165863284,\"y\":19.5},{\"x\":1685166163398,\"y\":19.7},{\"x\":1685166463432,\"y\":20},{\"x\":1685166763562,\"y\":20},{\"x\":1685167063657,\"y\":20.3},{\"x\":1685167363752,\"y\":20.3},{\"x\":1685167663818,\"y\":20.2},{\"x\":1685167963868,\"y\":20.4},{\"x\":1685168263959,\"y\":20.5},{\"x\":1685168564052,\"y\":20.7},{\"x\":1685168864152,\"y\":20.8},{\"x\":1685169164297,\"y\":20.8},{\"x\":1685169464371,\"y\":20.8},{\"x\":1685169764428,\"y\":20.9},{\"x\":1685170064553,\"y\":21},{\"x\":1685170364630,\"y\":20.8},{\"x\":1685170664689,\"y\":20.8},{\"x\":1685170964744,\"y\":20.9},{\"x\":1685171264839,\"y\":21},{\"x\":1685171564944,\"y\":21},{\"x\":1685171865046,\"y\":21.1},{\"x\":1685172165136,\"y\":21.1},{\"x\":1685172465216,\"y\":21.2},{\"x\":1685172765270,\"y\":21.5},{\"x\":1685173065378,\"y\":21.5},{\"x\":1685173365491,\"y\":21.5},{\"x\":1685173665574,\"y\":21.5},{\"x\":1685173965634,\"y\":21.5},{\"x\":1685174265651,\"y\":21.5},{\"x\":1685174565770,\"y\":21.5},{\"x\":1685174865842,\"y\":21.5},{\"x\":1685175165962,\"y\":21.5},{\"x\":1685175466056,\"y\":21.5},{\"x\":1685175766151,\"y\":21.6},{\"x\":1685176066247,\"y\":21.7},{\"x\":1685176366347,\"y\":21.6},{\"x\":1685176666421,\"y\":21.6},{\"x\":1685176966481,\"y\":21.7},{\"x\":1685177266535,\"y\":21.7},{\"x\":1685177566618,\"y\":21.7},{\"x\":1685177866715,\"y\":21.8},{\"x\":1685178166786,\"y\":21.7},{\"x\":1685178466868,\"y\":21.7},{\"x\":1685178766964,\"y\":21.8},{\"x\":1685179067013,\"y\":21.9},{\"x\":1685179367161,\"y\":21.9},{\"x\":1685179667226,\"y\":21.9},{\"x\":1685179967298,\"y\":21.9},{\"x\":1685180267304,\"y\":21.9},{\"x\":1685180567400,\"y\":21.9},{\"x\":1685180867474,\"y\":21.9},{\"x\":1685181167605,\"y\":21.9},{\"x\":1685181467661,\"y\":21.9},{\"x\":1685181767781,\"y\":21.9},{\"x\":1685182067847,\"y\":21.9},{\"x\":1685182367916,\"y\":21.9},{\"x\":1685182668010,\"y\":21.9},{\"x\":1685182968067,\"y\":21.9},{\"x\":1685183268142,\"y\":21.9},{\"x\":1685183568218,\"y\":21.9},{\"x\":1685183868264,\"y\":21.9},{\"x\":1685184168356,\"y\":22},{\"x\":1685184468449,\"y\":22},{\"x\":1685184768557,\"y\":22},{\"x\":1685185068624,\"y\":22.2},{\"x\":1685185368711,\"y\":22.1},{\"x\":1685185668784,\"y\":22.1},{\"x\":1685185968847,\"y\":22},{\"x\":1685186268953,\"y\":21.9},{\"x\":1685186568982,\"y\":21.9},{\"x\":1685186868996,\"y\":21.9},{\"x\":1685187169094,\"y\":21.9},{\"x\":1685187469146,\"y\":21.9},{\"x\":1685187769224,\"y\":21.9},{\"x\":1685188069250,\"y\":21.9},{\"x\":1685188369327,\"y\":21.9},{\"x\":1685188669411,\"y\":21.7},{\"x\":1685188969475,\"y\":21.7},{\"x\":1685189269500,\"y\":21.5},{\"x\":1685189569548,\"y\":21.5},{\"x\":1685189869583,\"y\":21.6},{\"x\":1685190169645,\"y\":21.7},{\"x\":1685190469717,\"y\":21.7},{\"x\":1685190769801,\"y\":21.7},{\"x\":1685191069848,\"y\":21.7},{\"x\":1685191369885,\"y\":21.7},{\"x\":1685191669980,\"y\":21.7},{\"x\":1685191970014,\"y\":21.7},{\"x\":1685192270055,\"y\":21.6},{\"x\":1685192570106,\"y\":21.7},{\"x\":1685192870150,\"y\":21.7},{\"x\":1685193170235,\"y\":21.6},{\"x\":1685193470249,\"y\":21.5},{\"x\":1685193770302,\"y\":21.5},{\"x\":1685194070311,\"y\":21.6},{\"x\":1685194370328,\"y\":21.7},{\"x\":1685194670393,\"y\":21.7},{\"x\":1685194985377,\"y\":21.7},{\"x\":1685195285440,\"y\":21.7},{\"x\":1685195585471,\"y\":21.7},{\"x\":1685195885473,\"y\":21.7},{\"x\":1685196185514,\"y\":21.6},{\"x\":1685196485562,\"y\":21.7},{\"x\":1685196800615,\"y\":21.7},{\"x\":1685197115572,\"y\":21.7},{\"x\":1685197415601,\"y\":21.7},{\"x\":1685197715640,\"y\":21.7},{\"x\":1685198015652,\"y\":21.7},{\"x\":1685198315706,\"y\":21.7},{\"x\":1685198615725,\"y\":21.7},{\"x\":1685198915775,\"y\":21.8},{\"x\":1685199215786,\"y\":21.8},{\"x\":1685199515831,\"y\":21.9},{\"x\":1685199815856,\"y\":21.8},{\"x\":1685200115858,\"y\":21.9},{\"x\":1685200415875,\"y\":21.8},{\"x\":1685200715913,\"y\":21.8},{\"x\":1685201015918,\"y\":21.8},{\"x\":1685201315964,\"y\":21.9},{\"x\":1685201616032,\"y\":21.9},{\"x\":1685201916044,\"y\":21.9},{\"x\":1685202231051,\"y\":21.9},{\"x\":1685202531062,\"y\":21.9},{\"x\":1685202831089,\"y\":21.8},{\"x\":1685203131095,\"y\":21.8},{\"x\":1685203431195,\"y\":21.8},{\"x\":1685203746138,\"y\":21.8},{\"x\":1685204046168,\"y\":21.8},{\"x\":1685204346182,\"y\":21.7},{\"x\":1685204646203,\"y\":21.8},{\"x\":1685204946241,\"y\":21.9},{\"x\":1685205246243,\"y\":21.9},{\"x\":1685205546262,\"y\":21.9},{\"x\":1685205846296,\"y\":21.9},{\"x\":1685206146312,\"y\":21.9},{\"x\":1685206446335,\"y\":21.9},{\"x\":1685206746375,\"y\":21.9},{\"x\":1685207046395,\"y\":21.9},{\"x\":1685207346549,\"y\":21.9},{\"x\":1685207661544,\"y\":21.9},{\"x\":1685207961647,\"y\":21.9},{\"x\":1685208261700,\"y\":21.9},{\"x\":1685208561766,\"y\":21.9},{\"x\":1685208861855,\"y\":21.9},{\"x\":1685209161943,\"y\":21.9},{\"x\":1685209462007,\"y\":21.9},{\"x\":1685209762097,\"y\":21.9},{\"x\":1685210077101,\"y\":21.9},{\"x\":1685210377152,\"y\":21.9},{\"x\":1685210677231,\"y\":21.9},{\"x\":1685210977296,\"y\":21.9},{\"x\":1685211277406,\"y\":21.9},{\"x\":1685211577537,\"y\":21.9},{\"x\":1685211877620,\"y\":21.9},{\"x\":1685212177660,\"y\":21.9},{\"x\":1685212477797,\"y\":21.9},{\"x\":1685212777837,\"y\":21.9},{\"x\":1685213077881,\"y\":21.9},{\"x\":1685213377932,\"y\":21.9},{\"x\":1685213677997,\"y\":21.9},{\"x\":1685213978205,\"y\":21.9},{\"x\":1685214293200,\"y\":21.9},{\"x\":1685214593270,\"y\":21.9},{\"x\":1685214893375,\"y\":21.9},{\"x\":1685215193482,\"y\":21.9},{\"x\":1685215493529,\"y\":21.8},{\"x\":1685215793531,\"y\":21.9},{\"x\":1685216093643,\"y\":21.9},{\"x\":1685216393738,\"y\":22},{\"x\":1685216693784,\"y\":21.9},{\"x\":1685216993880,\"y\":21.9},{\"x\":1685217293962,\"y\":21.7},{\"x\":1685217594100,\"y\":21.7},{\"x\":1685217894151,\"y\":21.7},{\"x\":1685218194256,\"y\":21.6},{\"x\":1685218494376,\"y\":21.5},{\"x\":1685218794467,\"y\":21.5},{\"x\":1685219094477,\"y\":21.5},{\"x\":1685219394675,\"y\":21.5},{\"x\":1685219709688,\"y\":21.5},{\"x\":1685220009789,\"y\":21.5},{\"x\":1685220309889,\"y\":21.5},{\"x\":1685220609986,\"y\":21.4},{\"x\":1685220910080,\"y\":21.5},{\"x\":1685221210236,\"y\":21.5},{\"x\":1685221510267,\"y\":21.5},{\"x\":1685221810331,\"y\":21.5},{\"x\":1685222110381,\"y\":21.4},{\"x\":1685222410481,\"y\":21.4},{\"x\":1685222710598,\"y\":21.3},{\"x\":1685223010661,\"y\":21.5},{\"x\":1685223310759,\"y\":21.5},{\"x\":1685223610881,\"y\":21.5},{\"x\":1685223911009,\"y\":21.5},{\"x\":1685224211106,\"y\":21.5},{\"x\":1685224511191,\"y\":21.5},{\"x\":1685224811272,\"y\":21.4},{\"x\":1685225111309,\"y\":21.4},{\"x\":1685225411398,\"y\":21.3},{\"x\":1685225711438,\"y\":21.2},{\"x\":1685226011552,\"y\":21.2},{\"x\":1685226311659,\"y\":21.2},{\"x\":1685226611773,\"y\":21.2},{\"x\":1685226911876,\"y\":21.2},{\"x\":1685227211995,\"y\":21.2},{\"x\":1685227512070,\"y\":21.2},{\"x\":1685227812175,\"y\":21.2},{\"x\":1685228112250,\"y\":21.2},{\"x\":1685228412314,\"y\":21},{\"x\":1685228712352,\"y\":21},{\"x\":1685229012470,\"y\":21},{\"x\":1685229312587,\"y\":21},{\"x\":1685229612662,\"y\":21.1},{\"x\":1685229912736,\"y\":21},{\"x\":1685230212847,\"y\":20.9},{\"x\":1685230512904,\"y\":21},{\"x\":1685230813034,\"y\":21},{\"x\":1685231113081,\"y\":21},{\"x\":1685231413122,\"y\":20.8},{\"x\":1685231713183,\"y\":20.8},{\"x\":1685232013342,\"y\":20.8},{\"x\":1685232328321,\"y\":20.8},{\"x\":1685232628419,\"y\":20.8},{\"x\":1685232928528,\"y\":20.8},{\"x\":1685233228604,\"y\":20.8},{\"x\":1685233528687,\"y\":20.8},{\"x\":1685233828743,\"y\":20.8},{\"x\":1685234128809,\"y\":20.8},{\"x\":1685234428883,\"y\":20.8},{\"x\":1685234728963,\"y\":20.8},{\"x\":1685235028977,\"y\":20.8},{\"x\":1685235329064,\"y\":20.8},{\"x\":1685235629163,\"y\":20.8},{\"x\":1685235929251,\"y\":20.8},{\"x\":1685236229341,\"y\":20.8},{\"x\":1685236529423,\"y\":20.7},{\"x\":1685236829513,\"y\":20.7},{\"x\":1685237129612,\"y\":20.8},{\"x\":1685237429697,\"y\":20.7},{\"x\":1685237729771,\"y\":20.7},{\"x\":1685238029832,\"y\":20.5},{\"x\":1685238329902,\"y\":20.5},{\"x\":1685238629974,\"y\":20.5},{\"x\":1685238930096,\"y\":20.5},{\"x\":1685239230144,\"y\":20.6},{\"x\":1685239530225,\"y\":20.6},{\"x\":1685239830331,\"y\":20.6},{\"x\":1685240130366,\"y\":20.6},{\"x\":1685240430509,\"y\":20.5},{\"x\":1685240730597,\"y\":20.5},{\"x\":1685241030697,\"y\":20.4},{\"x\":1685241330716,\"y\":20.4},{\"x\":1685241630792,\"y\":20.4},{\"x\":1685241930839,\"y\":20.4},{\"x\":1685242230957,\"y\":20.4},{\"x\":1685242531061,\"y\":20.4},{\"x\":1685242831116,\"y\":20.4},{\"x\":1685243131245,\"y\":20.4},{\"x\":1685243431358,\"y\":20.4},{\"x\":1685243731422,\"y\":20.3},{\"x\":1685244031484,\"y\":20.3},{\"x\":1685244331554,\"y\":20.2},{\"x\":1685244631614,\"y\":20.3},{\"x\":1685244931700,\"y\":20.3},{\"x\":1685245231790,\"y\":20.3},{\"x\":1685245531908,\"y\":20.3},{\"x\":1685245832059,\"y\":20.3},{\"x\":1685246132107,\"y\":20.3},{\"x\":1685246432206,\"y\":20.3},{\"x\":1685246732334,\"y\":20.3},{\"x\":1685247032445,\"y\":20.3},{\"x\":1685247332472,\"y\":20.2},{\"x\":1685247632538,\"y\":20.2},{\"x\":1685247932668,\"y\":20.2},{\"x\":1685248232731,\"y\":20.2},{\"x\":1685248532806,\"y\":20.2},{\"x\":1685248832930,\"y\":20.2},{\"x\":1685249133015,\"y\":20.2},{\"x\":1685249433093,\"y\":20.2},{\"x\":1685249733189,\"y\":20.2},{\"x\":1685250033291,\"y\":20.1},{\"x\":1685250333378,\"y\":20},{\"x\":1685250633446,\"y\":20},{\"x\":1685250933493,\"y\":20},{\"x\":1685251233569,\"y\":20},{\"x\":1685251533627,\"y\":20},{\"x\":1685251833774,\"y\":20.1},{\"x\":1685252133852,\"y\":20.2},{\"x\":1685252433955,\"y\":20.2},{\"x\":1685252734091,\"y\":20.2},{\"x\":1685253034179,\"y\":20},{\"x\":1685253334257,\"y\":19.9},{\"x\":1685253634325,\"y\":20},{\"x\":1685253934367,\"y\":20.2},{\"x\":1685254234489,\"y\":20.2},{\"x\":1685254534587,\"y\":20.2},{\"x\":1685254834680,\"y\":20.2},{\"x\":1685255134805,\"y\":20.3},{\"x\":1685255434885,\"y\":20.3},{\"x\":1685255735002,\"y\":20.3},{\"x\":1685256035085,\"y\":20.5},{\"x\":1685256335179,\"y\":20.5},{\"x\":1685256635254,\"y\":20.3},{\"x\":1685256935309,\"y\":20.3},{\"x\":1685257235338,\"y\":20.3},{\"x\":1685257535440,\"y\":20.3},{\"x\":1685257835520,\"y\":20.4},{\"x\":1685258135635,\"y\":20.5},{\"x\":1685258435709,\"y\":20.5},{\"x\":1685258735790,\"y\":20.5},{\"x\":1685259035904,\"y\":20.5},{\"x\":1685259335965,\"y\":20.4},{\"x\":1685259636005,\"y\":20.4},{\"x\":1685259936052,\"y\":20.4},{\"x\":1685260236148,\"y\":20.5},{\"x\":1685260536249,\"y\":20.4},{\"x\":1685260836320,\"y\":20.5},{\"x\":1685261136489,\"y\":20.5},{\"x\":1685261436489,\"y\":20.6},{\"x\":1685261736607,\"y\":20.5},{\"x\":1685262036710,\"y\":20.5},{\"x\":1685262336806,\"y\":20.4},{\"x\":1685262636943,\"y\":20.4},{\"x\":1685262936991,\"y\":20.3},{\"x\":1685263237019,\"y\":20.3},{\"x\":1685263537113,\"y\":20.3},{\"x\":1685263837223,\"y\":20.3},{\"x\":1685264137303,\"y\":20.3},{\"x\":1685264437449,\"y\":20.4},{\"x\":1685264737520,\"y\":20.3},{\"x\":1685265037596,\"y\":20.4},{\"x\":1685265337653,\"y\":20.3},{\"x\":1685265637725,\"y\":20.3},{\"x\":1685265937773,\"y\":20.3},{\"x\":1685266237884,\"y\":20.3},{\"x\":1685266537917,\"y\":20.3},{\"x\":1685266837940,\"y\":20.3},{\"x\":1685267138006,\"y\":20.3},{\"x\":1685267438089,\"y\":20.3},{\"x\":1685267738177,\"y\":20.3},{\"x\":1685268038239,\"y\":20.4},{\"x\":1685268338288,\"y\":20.3},{\"x\":1685268638340,\"y\":20.4},{\"x\":1685268938413,\"y\":20.3},{\"x\":1685269238479,\"y\":20.4},{\"x\":1685269538567,\"y\":20.4},{\"x\":1685269838641,\"y\":20.4},{\"x\":1685270138681,\"y\":20.3},{\"x\":1685270438761,\"y\":20.3},{\"x\":1685270738813,\"y\":20.3},{\"x\":1685271038911,\"y\":20.3},{\"x\":1685271338993,\"y\":20},{\"x\":1685271638994,\"y\":20},{\"x\":1685271939107,\"y\":20.2},{\"x\":1685272239155,\"y\":20.3},{\"x\":1685272539230,\"y\":20.3},{\"x\":1685272839299,\"y\":20.3},{\"x\":1685273139339,\"y\":20.3},{\"x\":1685273439382,\"y\":20.2},{\"x\":1685273739450,\"y\":19.9},{\"x\":1685274039516,\"y\":19.9},{\"x\":1685274339570,\"y\":20.2},{\"x\":1685274639651,\"y\":20.3},{\"x\":1685274939715,\"y\":20.5},{\"x\":1685275239718,\"y\":20.5},{\"x\":1685275539821,\"y\":20.6},{\"x\":1685275839883,\"y\":20.5},{\"x\":1685276139936,\"y\":20.3},{\"x\":1685276439971,\"y\":20.3},{\"x\":1685276740019,\"y\":20.3},{\"x\":1685277040061,\"y\":20.2},{\"x\":1685277340154,\"y\":20},{\"x\":1685277640177,\"y\":19.9},{\"x\":1685277940231,\"y\":20},{\"x\":1685278240249,\"y\":20},{\"x\":1685278540299,\"y\":19.9},{\"x\":1685278840376,\"y\":19.9},{\"x\":1685279140399,\"y\":19.5},{\"x\":1685279440422,\"y\":19.7},{\"x\":1685279740489,\"y\":19.8},{\"x\":1685280040542,\"y\":19.8},{\"x\":1685280340547,\"y\":19.5},{\"x\":1685280640612,\"y\":19.5},{\"x\":1685280940692,\"y\":19.5},{\"x\":1685280995978,\"y\":19.5},{\"x\":1685281186232,\"y\":19.5},{\"x\":1685281372604,\"y\":19.5},{\"x\":1685281687601,\"y\":19.5},{\"x\":1685281710226,\"y\":19.5},{\"x\":1685281749591,\"y\":19.5},{\"x\":1685281762017,\"y\":19.5},{\"x\":1685281799605,\"y\":19.5},{\"x\":1685282023556,\"y\":19.5},{\"x\":1685282044430,\"y\":19.5},{\"x\":1685282166915,\"y\":19.5},{\"x\":1685282208131,\"y\":19.5},{\"x\":1685282217923,\"y\":19.5},{\"x\":1685282260379,\"y\":19.5},{\"x\":1685282339652,\"y\":19.5},{\"x\":1685282364558,\"y\":19.5},{\"x\":1685282412077,\"y\":19.5},{\"x\":1685282588188,\"y\":19.5},{\"x\":1685282614967,\"y\":19.5},{\"x\":1685282852605,\"y\":19.5},{\"x\":1685282960718,\"y\":19.5},{\"x\":1685282980565,\"y\":19.5},{\"x\":1685283037810,\"y\":19.5},{\"x\":1685283067001,\"y\":19.5},{\"x\":1685283122144,\"y\":19.5},{\"x\":1685283272482,\"y\":19.5},{\"x\":1685283343031,\"y\":19.5},{\"x\":1685283445211,\"y\":19.5},{\"x\":1685283473050,\"y\":19.5},{\"x\":1685283503945,\"y\":19.4},{\"x\":1685283559122,\"y\":19.5},{\"x\":1685283661335,\"y\":19.5},{\"x\":1685283679196,\"y\":19.5},{\"x\":1685283753141,\"y\":19.5},{\"x\":1685283789923,\"y\":19.4},{\"x\":1685283796674,\"y\":19.4},{\"x\":1685284111596,\"y\":19.5},{\"x\":1685284411624,\"y\":19.5},{\"x\":1685284726634,\"y\":20},{\"x\":1685285041633,\"y\":19.9},{\"x\":1685285341650,\"y\":19.6},{\"x\":1685285641691,\"y\":19.8},{\"x\":1685285941711,\"y\":20},{\"x\":1685286241759,\"y\":20},{\"x\":1685286541841,\"y\":19.7},{\"x\":1685286856821,\"y\":20},{\"x\":1685287156833,\"y\":20.3},{\"x\":1685287456865,\"y\":20.4},{\"x\":1685287756902,\"y\":20.3},{\"x\":1685288056933,\"y\":20.3},{\"x\":1685288357007,\"y\":20.3},{\"x\":1685288671988,\"y\":20.1},{\"x\":1685288972004,\"y\":20.2},{\"x\":1685289272052,\"y\":20},{\"x\":1685289572077,\"y\":20},{\"x\":1685289872089,\"y\":20},{\"x\":1685290172161,\"y\":19.9},{\"x\":1685290487147,\"y\":20},{\"x\":1685290787163,\"y\":20},{\"x\":1685291087218,\"y\":19.9},{\"x\":1685291387247,\"y\":19.9},{\"x\":1685291687274,\"y\":20},{\"x\":1685291987283,\"y\":20.2},{\"x\":1685292287334,\"y\":20},{\"x\":1685292587380,\"y\":19.9},{\"x\":1685292887389,\"y\":19.9},{\"x\":1685293187427,\"y\":19.8},{\"x\":1685293502456,\"y\":19.7},{\"x\":1685293817480,\"y\":19.5},{\"x\":1685294117492,\"y\":19.6},{\"x\":1685294417507,\"y\":19.9},{\"x\":1685294717548,\"y\":20},{\"x\":1685295017585,\"y\":19.9},{\"x\":1685295317622,\"y\":19.6},{\"x\":1685295617633,\"y\":20},{\"x\":1685295917642,\"y\":19.7},{\"x\":1685296217701,\"y\":19.9},{\"x\":1685296532704,\"y\":19.5},{\"x\":1685296832750,\"y\":19.5},{\"x\":1685297132754,\"y\":19.5},{\"x\":1685297432771,\"y\":19.5},{\"x\":1685297732796,\"y\":19.5},{\"x\":1685298032828,\"y\":19.5},{\"x\":1685298332882,\"y\":19.5},{\"x\":1685298647889,\"y\":19.5},{\"x\":1685298947921,\"y\":19.5},{\"x\":1685299247969,\"y\":19.5},{\"x\":1685299547997,\"y\":19.5},{\"x\":1685299848026,\"y\":19.5},{\"x\":1685300163050,\"y\":19.5},{\"x\":1685300463065,\"y\":19.5},{\"x\":1685300763075,\"y\":19.5},{\"x\":1685301063109,\"y\":19.5},{\"x\":1685301363164,\"y\":19.5},{\"x\":1685301678208,\"y\":19.5},{\"x\":1685301993216,\"y\":19.5},{\"x\":1685302293269,\"y\":19.5},{\"x\":1685302593314,\"y\":19.5},{\"x\":1685302908310,\"y\":19.5},{\"x\":1685303208329,\"y\":19.5},{\"x\":1685303508359,\"y\":19.5},{\"x\":1685303808369,\"y\":19.5},{\"x\":1685304108395,\"y\":19.5},{\"x\":1685304408424,\"y\":19.3},{\"x\":1685304708455,\"y\":19.4},{\"x\":1685305008461,\"y\":19.4},{\"x\":1685305308490,\"y\":19.4},{\"x\":1685305608530,\"y\":19.5},{\"x\":1685305908539,\"y\":19.5},{\"x\":1685306208562,\"y\":19.4},{\"x\":1685306508616,\"y\":19.5},{\"x\":1685306823616,\"y\":19.5},{\"x\":1685307123649,\"y\":19.5},{\"x\":1685307423661,\"y\":19.5},{\"x\":1685307723699,\"y\":19.5},{\"x\":1685308023733,\"y\":19.5},{\"x\":1685308323779,\"y\":19.5},{\"x\":1685308638772,\"y\":19.5},{\"x\":1685308938793,\"y\":19.5},{\"x\":1685309238818,\"y\":19.5},{\"x\":1685309538833,\"y\":19.5},{\"x\":1685309838872,\"y\":19.5},{\"x\":1685310138910,\"y\":19.5},{\"x\":1685310453907,\"y\":19.5},{\"x\":1685310768906,\"y\":19.5},{\"x\":1685311068915,\"y\":19.5},{\"x\":1685311368965,\"y\":19.5},{\"x\":1685311668966,\"y\":19.5},{\"x\":1685311968998,\"y\":19.5},{\"x\":1685312269016,\"y\":19.5},{\"x\":1685312569034,\"y\":19.5},{\"x\":1685312869061,\"y\":19.5},{\"x\":1685313169072,\"y\":19.5},{\"x\":1685313484093,\"y\":19.5},{\"x\":1685313784097,\"y\":19.6},{\"x\":1685314084113,\"y\":19.5},{\"x\":1685314384134,\"y\":19.7},{\"x\":1685314684165,\"y\":19.9},{\"x\":1685314984191,\"y\":19.9},{\"x\":1685315299157,\"y\":19.9},{\"x\":1685315599168,\"y\":20},{\"x\":1685315899192,\"y\":19.9},{\"x\":1685316199221,\"y\":20.1},{\"x\":1685316514243,\"y\":20},{\"x\":1685316814264,\"y\":20.2},{\"x\":1685317129218,\"y\":20.2},{\"x\":1685317444217,\"y\":20.2},{\"x\":1685317744298,\"y\":20.3},{\"x\":1685318059259,\"y\":20.3},{\"x\":1685318359275,\"y\":20.3},{\"x\":1685318659355,\"y\":20.3},{\"x\":1685318959404,\"y\":20.3},{\"x\":1685319259419,\"y\":20.2},{\"x\":1685319559443,\"y\":20.3},{\"x\":1685319859535,\"y\":20.3},{\"x\":1685320159597,\"y\":20.3},{\"x\":1685320459678,\"y\":20.3},{\"x\":1685320759851,\"y\":20.3},{\"x\":1685321074857,\"y\":20.2},{\"x\":1685321374890,\"y\":20.3},{\"x\":1685321674930,\"y\":20.3},{\"x\":1685321974980,\"y\":20.3},{\"x\":1685322274993,\"y\":20.3},{\"x\":1685322575024,\"y\":20.3},{\"x\":1685322875122,\"y\":20.3},{\"x\":1685323175196,\"y\":20.3},{\"x\":1685323475244,\"y\":20.3},{\"x\":1685323775309,\"y\":20.4},{\"x\":1685324075375,\"y\":20.3},{\"x\":1685324375402,\"y\":20.4},{\"x\":1685324675425,\"y\":20.5},{\"x\":1685324975485,\"y\":20.5},{\"x\":1685325275523,\"y\":20.5},{\"x\":1685325575582,\"y\":20.5},{\"x\":1685325875647,\"y\":20.5},{\"x\":1685326175713,\"y\":20.5},{\"x\":1685326475768,\"y\":20.4},{\"x\":1685326775825,\"y\":20.4},{\"x\":1685327075908,\"y\":20.4},{\"x\":1685327376002,\"y\":20.4},{\"x\":1685327676015,\"y\":20.4},{\"x\":1685327976059,\"y\":20.4},{\"x\":1685328276184,\"y\":20.4},{\"x\":1685328591156,\"y\":20.4},{\"x\":1685328891332,\"y\":20.4},{\"x\":1685329206306,\"y\":20.4},{\"x\":1685329506397,\"y\":20.4},{\"x\":1685329806440,\"y\":20.3},{\"x\":1685330106549,\"y\":20.3},{\"x\":1685330406587,\"y\":20.3},{\"x\":1685330706687,\"y\":20.2},{\"x\":1685331006741,\"y\":20.3},{\"x\":1685331306759,\"y\":20.3},{\"x\":1685331606822,\"y\":20.2},{\"x\":1685331906872,\"y\":20.2},{\"x\":1685332206974,\"y\":20.2},{\"x\":1685332507043,\"y\":20.3},{\"x\":1685332807216,\"y\":20.2},{\"x\":1685333122210,\"y\":20.2},{\"x\":1685333422298,\"y\":20.2},{\"x\":1685333722396,\"y\":20.2},{\"x\":1685334022464,\"y\":20.2},{\"x\":1685334322536,\"y\":20.2},{\"x\":1685334622591,\"y\":20.2},{\"x\":1685334922644,\"y\":20.2},{\"x\":1685335222714,\"y\":20.1},{\"x\":1685335522841,\"y\":20},{\"x\":1685335822919,\"y\":20},{\"x\":1685336122954,\"y\":20},{\"x\":1685336423087,\"y\":19.9},{\"x\":1685336723138,\"y\":20},{\"x\":1685337023185,\"y\":19.9},{\"x\":1685337323274,\"y\":19.9},{\"x\":1685337623330,\"y\":19.9},{\"x\":1685337923414,\"y\":20},{\"x\":1685338223520,\"y\":19.9},{\"x\":1685338523616,\"y\":20},{\"x\":1685338823724,\"y\":19.9},{\"x\":1685339123797,\"y\":20},{\"x\":1685339423870,\"y\":19.9},{\"x\":1685339723950,\"y\":19.9},{\"x\":1685340024030,\"y\":19.9},{\"x\":1685340324090,\"y\":20},{\"x\":1685340624115,\"y\":20},{\"x\":1685340924164,\"y\":20},{\"x\":1685341224265,\"y\":20},{\"x\":1685341524353,\"y\":20},{\"x\":1685341824453,\"y\":20},{\"x\":1685342124531,\"y\":20.2},{\"x\":1685342424622,\"y\":19.9},{\"x\":1685342724753,\"y\":20},{\"x\":1685343024799,\"y\":20.2},{\"x\":1685343324830,\"y\":20},{\"x\":1685343624890,\"y\":19.9},{\"x\":1685343924971,\"y\":20.2},{\"x\":1685344225070,\"y\":20.2},{\"x\":1685344525149,\"y\":20.3},{\"x\":1685344825216,\"y\":20.2},{\"x\":1685345125344,\"y\":20.2},{\"x\":1685345425362,\"y\":20.3},{\"x\":1685345725441,\"y\":20.3},{\"x\":1685346025536,\"y\":20.3},{\"x\":1685346325591,\"y\":20},{\"x\":1685346625679,\"y\":20.2},{\"x\":1685346925731,\"y\":20.2},{\"x\":1685347225748,\"y\":20.3},{\"x\":1685347525839,\"y\":20.3},{\"x\":1685347825931,\"y\":20.3},{\"x\":1685348126031,\"y\":20.3},{\"x\":1685348426089,\"y\":20.3},{\"x\":1685348726163,\"y\":20.3},{\"x\":1685349026225,\"y\":20.3},{\"x\":1685349326308,\"y\":20.3},{\"x\":1685349626392,\"y\":20},{\"x\":1685349926466,\"y\":20},{\"x\":1685350226553,\"y\":20.2},{\"x\":1685350526651,\"y\":19.9},{\"x\":1685350826811,\"y\":20},{\"x\":1685351141763,\"y\":19.9},{\"x\":1685351441827,\"y\":20.2},{\"x\":1685351741927,\"y\":20.2},{\"x\":1685352042064,\"y\":20.1},{\"x\":1685352342100,\"y\":20.3},{\"x\":1685352642170,\"y\":20},{\"x\":1685352942245,\"y\":19.9},{\"x\":1685353242314,\"y\":19.9},{\"x\":1685353542387,\"y\":20},{\"x\":1685353842461,\"y\":20},{\"x\":1685354142491,\"y\":20},{\"x\":1685354442557,\"y\":19.9},{\"x\":1685354742628,\"y\":20},{\"x\":1685355042729,\"y\":20.3},{\"x\":1685355342838,\"y\":20.2},{\"x\":1685355642921,\"y\":20.3},{\"x\":1685355942977,\"y\":20},{\"x\":1685356243149,\"y\":19.9},{\"x\":1685356558148,\"y\":19.5},{\"x\":1685356858211,\"y\":19.9},{\"x\":1685357158249,\"y\":20},{\"x\":1685357458282,\"y\":19.6},{\"x\":1685357758424,\"y\":20},{\"x\":1685358058471,\"y\":19.5},{\"x\":1685358358569,\"y\":19.5},{\"x\":1685358658635,\"y\":20},{\"x\":1685358958716,\"y\":20.1},{\"x\":1685359258767,\"y\":20},{\"x\":1685359558873,\"y\":19.9},{\"x\":1685359858954,\"y\":20.2},{\"x\":1685360159014,\"y\":20.2},{\"x\":1685360459077,\"y\":20},{\"x\":1685360759117,\"y\":19.9},{\"x\":1685361059194,\"y\":19.8},{\"x\":1685361359285,\"y\":20},{\"x\":1685361659377,\"y\":20},{\"x\":1685361959454,\"y\":20.1},{\"x\":1685362259508,\"y\":20.2},{\"x\":1685362559586,\"y\":19.9},{\"x\":1685362859674,\"y\":20},{\"x\":1685363159756,\"y\":20},{\"x\":1685363459810,\"y\":19.5},{\"x\":1685363759869,\"y\":19.6},{\"x\":1685364059953,\"y\":19.5},{\"x\":1685364360040,\"y\":19.9},{\"x\":1685364660157,\"y\":19.9},{\"x\":1685364960261,\"y\":19.9},{\"x\":1685365260272,\"y\":19.9},{\"x\":1685365560367,\"y\":20},{\"x\":1685365860483,\"y\":19.9},{\"x\":1685366160569,\"y\":19.9},{\"x\":1685366460633,\"y\":19.5},{\"x\":1685366760670,\"y\":19.5},{\"x\":1685367060781,\"y\":19.5},{\"x\":1685367360928,\"y\":19.5},{\"x\":1685367660996,\"y\":19.5},{\"x\":1685367961125,\"y\":19.5},{\"x\":1685368261267,\"y\":19.5},{\"x\":1685368561326,\"y\":19.5},{\"x\":1685368861443,\"y\":19.5},{\"x\":1685369161528,\"y\":19.5},{\"x\":1685369461571,\"y\":19.5},{\"x\":1685369761618,\"y\":19.5},{\"x\":1685370061811,\"y\":19.5},{\"x\":1685370361876,\"y\":19.5},{\"x\":1685370661975,\"y\":19.5},{\"x\":1685370962096,\"y\":19.5},{\"x\":1685371262161,\"y\":19.5},{\"x\":1685371562287,\"y\":19.5},{\"x\":1685371862386,\"y\":19.5},{\"x\":1685372162471,\"y\":19.5},{\"x\":1685372462563,\"y\":19.4},{\"x\":1685372762583,\"y\":19.2},{\"x\":1685373062692,\"y\":19.2},{\"x\":1685373362813,\"y\":19.1},{\"x\":1685373662925,\"y\":19.3},{\"x\":1685373963012,\"y\":19.2},{\"x\":1685374263073,\"y\":19.2},{\"x\":1685374563193,\"y\":19},{\"x\":1685374863306,\"y\":19.2},{\"x\":1685375163412,\"y\":19.3},{\"x\":1685375463446,\"y\":19.4},{\"x\":1685375763533,\"y\":19.4},{\"x\":1685376063611,\"y\":19.2},{\"x\":1685376363690,\"y\":19.1},{\"x\":1685376663795,\"y\":19},{\"x\":1685376963909,\"y\":19.2},{\"x\":1685377263998,\"y\":19.3},{\"x\":1685377564112,\"y\":19.1},{\"x\":1685377864184,\"y\":19.2},{\"x\":1685378164260,\"y\":19.1},{\"x\":1685378464309,\"y\":19},{\"x\":1685378764426,\"y\":19},{\"x\":1685379064528,\"y\":19},{\"x\":1685379364568,\"y\":19.2},{\"x\":1685379664627,\"y\":19.1},{\"x\":1685379964711,\"y\":19},{\"x\":1685380264778,\"y\":19.1},{\"x\":1685380564838,\"y\":19.2},{\"x\":1685380864899,\"y\":19},{\"x\":1685381164922,\"y\":19},{\"x\":1685381464995,\"y\":18.9},{\"x\":1685381765085,\"y\":18.9},{\"x\":1685382065145,\"y\":18.9},{\"x\":1685382365238,\"y\":18.9},{\"x\":1685382665304,\"y\":18.9},{\"x\":1685382965394,\"y\":19},{\"x\":1685383265458,\"y\":19},{\"x\":1685383565523,\"y\":18.9},{\"x\":1685383865573,\"y\":18.9},{\"x\":1685384165635,\"y\":18.7},{\"x\":1685384465670,\"y\":18.7},{\"x\":1685384765740,\"y\":18.7},{\"x\":1685385065812,\"y\":18.9},{\"x\":1685385365909,\"y\":18.8},{\"x\":1685385665940,\"y\":18.7},{\"x\":1685385966015,\"y\":18.9},{\"x\":1685386266095,\"y\":18.9},{\"x\":1685386566159,\"y\":18.8},{\"x\":1685386866204,\"y\":18.5},{\"x\":1685387166270,\"y\":18.5},{\"x\":1685387466325,\"y\":18.7},{\"x\":1685387766371,\"y\":18.5},{\"x\":1685388066417,\"y\":18.7},{\"x\":1685388366441,\"y\":18.7},{\"x\":1685388666495,\"y\":18.7},{\"x\":1685388966561,\"y\":18.4},{\"x\":1685389266600,\"y\":18.4},{\"x\":1685389566607,\"y\":18.4},{\"x\":1685389866660,\"y\":18.4},{\"x\":1685390166677,\"y\":18.5},{\"x\":1685390466746,\"y\":18.5},{\"x\":1685390781720,\"y\":18.6},{\"x\":1685391081770,\"y\":18.6},{\"x\":1685391381808,\"y\":18.4},{\"x\":1685391681836,\"y\":18.4},{\"x\":1685391981922,\"y\":18.4},{\"x\":1685392281964,\"y\":18.4},{\"x\":1685392582032,\"y\":18.4},{\"x\":1685392897029,\"y\":18.4},{\"x\":1685393197037,\"y\":18.4},{\"x\":1685393497068,\"y\":18.4},{\"x\":1685393797107,\"y\":18.4},{\"x\":1685394097146,\"y\":18.4},{\"x\":1685394397195,\"y\":18.4},{\"x\":1685394697240,\"y\":18.4},{\"x\":1685394997269,\"y\":18.4},{\"x\":1685395297315,\"y\":18.4},{\"x\":1685395597344,\"y\":18.4},{\"x\":1685395897378,\"y\":18.4},{\"x\":1685396197391,\"y\":18.4},{\"x\":1685396497411,\"y\":18.4},{\"x\":1685396797418,\"y\":18.3},{\"x\":1685397097514,\"y\":18.4},{\"x\":1685397397526,\"y\":18.2},{\"x\":1685397697553,\"y\":18.1},{\"x\":1685397997603,\"y\":18.1},{\"x\":1685398297622,\"y\":18.1},{\"x\":1685398597700,\"y\":18.1},{\"x\":1685398897737,\"y\":18.2},{\"x\":1685399212765,\"y\":18.2},{\"x\":1685399527768,\"y\":18},{\"x\":1685399827776,\"y\":18.1},{\"x\":1685400127841,\"y\":17.9},{\"x\":1685400442841,\"y\":18},{\"x\":1685400742935,\"y\":17.9},{\"x\":1685401057950,\"y\":18},{\"x\":1685401357960,\"y\":18},{\"x\":1685401657984,\"y\":18.1},{\"x\":1685401957995,\"y\":18},{\"x\":1685402258067,\"y\":18.1},{\"x\":1685402573081,\"y\":18},{\"x\":1685402873096,\"y\":17.9},{\"x\":1685403173117,\"y\":17.9},{\"x\":1685403473129,\"y\":17.9},{\"x\":1685403773148,\"y\":17.9},{\"x\":1685404073175,\"y\":18},{\"x\":1685404373229,\"y\":17.9},{\"x\":1685404688249,\"y\":17.9},{\"x\":1685404988317,\"y\":17.9},{\"x\":1685405288409,\"y\":17.9},{\"x\":1685405588488,\"y\":17.9},{\"x\":1685405888522,\"y\":17.9},{\"x\":1685406188569,\"y\":17.9},{\"x\":1685406488623,\"y\":17.9},{\"x\":1685406788688,\"y\":17.9},{\"x\":1685407088721,\"y\":17.9},{\"x\":1685407388765,\"y\":17.9},{\"x\":1685407688838,\"y\":17.9},{\"x\":1685407988885,\"y\":17.9},{\"x\":1685408288915,\"y\":17.9},{\"x\":1685408588993,\"y\":17.9},{\"x\":1685408889074,\"y\":17.9},{\"x\":1685409189147,\"y\":17.9},{\"x\":1685409489206,\"y\":17.9},{\"x\":1685409789249,\"y\":17.9},{\"x\":1685410089310,\"y\":17.9},{\"x\":1685410389345,\"y\":17.9},{\"x\":1685410704354,\"y\":17.9},{\"x\":1685411004452,\"y\":17.9},{\"x\":1685411304516,\"y\":17.9},{\"x\":1685411604552,\"y\":17.9},{\"x\":1685411904625,\"y\":17.8},{\"x\":1685412204887,\"y\":17.8},{\"x\":1685412519762,\"y\":17.7},{\"x\":1685412819867,\"y\":17.7},{\"x\":1685413119886,\"y\":17.8},{\"x\":1685413419976,\"y\":17.7},{\"x\":1685413719986,\"y\":17.7},{\"x\":1685414020028,\"y\":17.7},{\"x\":1685414320085,\"y\":17.7},{\"x\":1685414620140,\"y\":17.7},{\"x\":1685414920229,\"y\":17.7},{\"x\":1685415220270,\"y\":17.7},{\"x\":1685415520407,\"y\":17.7},{\"x\":1685415820425,\"y\":17.7},{\"x\":1685416120509,\"y\":17.7},{\"x\":1685416420519,\"y\":17.7},{\"x\":1685416720605,\"y\":17.7},{\"x\":1685417020626,\"y\":17.7},{\"x\":1685417320672,\"y\":17.7},{\"x\":1685417620774,\"y\":17.7},{\"x\":1685417920843,\"y\":17.7},{\"x\":1685418220900,\"y\":17.8},{\"x\":1685418520971,\"y\":17.7},{\"x\":1685418821022,\"y\":17.7},{\"x\":1685419121073,\"y\":17.8},{\"x\":1685419421171,\"y\":17.9},{\"x\":1685419721181,\"y\":17.7},{\"x\":1685420021225,\"y\":17.7},{\"x\":1685420321304,\"y\":17.6},{\"x\":1685420621355,\"y\":17.7},{\"x\":1685420921447,\"y\":17.7},{\"x\":1685421221522,\"y\":17.7},{\"x\":1685421521582,\"y\":17.7},{\"x\":1685421821663,\"y\":17.7},{\"x\":1685422121736,\"y\":17.6},{\"x\":1685422421818,\"y\":17.7},{\"x\":1685422721865,\"y\":17.7},{\"x\":1685423021869,\"y\":17.6},{\"x\":1685423321956,\"y\":17.4},{\"x\":1685423622015,\"y\":17.5},{\"x\":1685423922080,\"y\":17.4},{\"x\":1685424222162,\"y\":17.5},{\"x\":1685424522203,\"y\":17.5},{\"x\":1685424822288,\"y\":17.5},{\"x\":1685425122362,\"y\":17.4},{\"x\":1685425422438,\"y\":17.4},{\"x\":1685425722513,\"y\":17.4},{\"x\":1685426022547,\"y\":17.4},{\"x\":1685426322620,\"y\":17.5},{\"x\":1685426622723,\"y\":17.5},{\"x\":1685426922744,\"y\":17.4},{\"x\":1685427222854,\"y\":17.4},{\"x\":1685427522913,\"y\":17.4},{\"x\":1685427823002,\"y\":17.4},{\"x\":1685428123104,\"y\":17.5},{\"x\":1685428423173,\"y\":17.5},{\"x\":1685428723329,\"y\":17.4},{\"x\":1685429038338,\"y\":17.4},{\"x\":1685429338390,\"y\":17.4},{\"x\":1685429638534,\"y\":17.4},{\"x\":1685429938550,\"y\":17.4},{\"x\":1685430238655,\"y\":17.4},{\"x\":1685430538750,\"y\":17.4},{\"x\":1685430838822,\"y\":17.3},{\"x\":1685431139008,\"y\":17.5},{\"x\":1685431439050,\"y\":17.5},{\"x\":1685431739109,\"y\":17.4},{\"x\":1685432039156,\"y\":17.5},{\"x\":1685432339204,\"y\":17.7},{\"x\":1685432639299,\"y\":17.3},{\"x\":1685432939394,\"y\":17.2},{\"x\":1685433239499,\"y\":17.2},{\"x\":1685433539575,\"y\":17.2},{\"x\":1685433839700,\"y\":17.2},{\"x\":1685434139771,\"y\":16.9},{\"x\":1685434439873,\"y\":16.7},{\"x\":1685434739965,\"y\":16.5},{\"x\":1685435040038,\"y\":16.5},{\"x\":1685435340054,\"y\":16.5},{\"x\":1685435640133,\"y\":16.5},{\"x\":1685435940205,\"y\":16.5},{\"x\":1685436240311,\"y\":16.8},{\"x\":1685436540423,\"y\":16.9},{\"x\":1685436840548,\"y\":17.1},{\"x\":1685437140665,\"y\":17},{\"x\":1685437440701,\"y\":16.8},{\"x\":1685437740799,\"y\":16.5},{\"x\":1685438040887,\"y\":16.5},{\"x\":1685438340964,\"y\":16.5},{\"x\":1685438641030,\"y\":17.2},{\"x\":1685438941063,\"y\":17.2},{\"x\":1685439241150,\"y\":17.2},{\"x\":1685439541265,\"y\":17},{\"x\":1685439841366,\"y\":17.2},{\"x\":1685440141451,\"y\":16.5},{\"x\":1685440441506,\"y\":16.5},{\"x\":1685440741607,\"y\":16.5},{\"x\":1685441041684,\"y\":16.5},{\"x\":1685441341786,\"y\":16.5},{\"x\":1685441641830,\"y\":16.5},{\"x\":1685441941863,\"y\":16.5},{\"x\":1685442241939,\"y\":17},{\"x\":1685442542010,\"y\":17.3},{\"x\":1685442842108,\"y\":17.2},{\"x\":1685443142199,\"y\":16.6},{\"x\":1685443442319,\"y\":17.2},{\"x\":1685443742376,\"y\":16.5},{\"x\":1685444042480,\"y\":16.8},{\"x\":1685444342574,\"y\":16.8},{\"x\":1685444642649,\"y\":16.5},{\"x\":1685444942748,\"y\":17.2},{\"x\":1685445242792,\"y\":17.1},{\"x\":1685445542799,\"y\":17.2},{\"x\":1685445842907,\"y\":17.3},{\"x\":1685446143003,\"y\":17.4},{\"x\":1685446443122,\"y\":17.4},{\"x\":1685446743194,\"y\":17.3},{\"x\":1685447043298,\"y\":17.2},{\"x\":1685447343341,\"y\":17.4},{\"x\":1685447643442,\"y\":17.2},{\"x\":1685447943557,\"y\":17.2},{\"x\":1685448243632,\"y\":17.3},{\"x\":1685448543708,\"y\":17.2},{\"x\":1685448843747,\"y\":17.1},{\"x\":1685449143768,\"y\":16.6},{\"x\":1685449443878,\"y\":16.5},{\"x\":1685449743965,\"y\":16.5},{\"x\":1685450044053,\"y\":16.5},{\"x\":1685450344178,\"y\":17.2},{\"x\":1685450644263,\"y\":17.3},{\"x\":1685450944279,\"y\":17.4},{\"x\":1685451244382,\"y\":17.2},{\"x\":1685451544448,\"y\":17.3},{\"x\":1685451844600,\"y\":17.3},{\"x\":1685452144626,\"y\":17.4},{\"x\":1685452444701,\"y\":17.4},{\"x\":1685452744749,\"y\":17.2},{\"x\":1685453044818,\"y\":17.4},{\"x\":1685453344909,\"y\":17.7},{\"x\":1685453645071,\"y\":17.6},{\"x\":1685453945113,\"y\":17.5},{\"x\":1685454245205,\"y\":17.6},{\"x\":1685454545276,\"y\":17.6},{\"x\":1685454845390,\"y\":17.7},{\"x\":1685455145455,\"y\":17.8},{\"x\":1685455445552,\"y\":17.7},{\"x\":1685455745631,\"y\":17.7},{\"x\":1685456045706,\"y\":17.7},{\"x\":1685456345813,\"y\":17.6},{\"x\":1685456645826,\"y\":17.7},{\"x\":1685456945928,\"y\":17.7},{\"x\":1685457246034,\"y\":17.4},{\"x\":1685457546104,\"y\":17.4},{\"x\":1685457846188,\"y\":17.6},{\"x\":1685458146263,\"y\":17.9},{\"x\":1685458446341,\"y\":17.9},{\"x\":1685458746470,\"y\":17.9},{\"x\":1685459046554,\"y\":17.8},{\"x\":1685459346643,\"y\":17.7},{\"x\":1685459646708,\"y\":17.9},{\"x\":1685459946734,\"y\":18},{\"x\":1685460246833,\"y\":17.9},{\"x\":1685460546913,\"y\":17.9},{\"x\":1685460847002,\"y\":17.9},{\"x\":1685461147079,\"y\":17.9},{\"x\":1685461447115,\"y\":17.9},{\"x\":1685461747181,\"y\":17.9},{\"x\":1685462047303,\"y\":17.9},{\"x\":1685462347360,\"y\":17.9},{\"x\":1685462647457,\"y\":17.9},{\"x\":1685462947533,\"y\":17.9},{\"x\":1685463247622,\"y\":17.9},{\"x\":1685463437946,\"y\":17.9},{\"x\":1685463752894,\"y\":17.9},{\"x\":1685464067891,\"y\":17.9},{\"x\":1685464367932,\"y\":17.9},{\"x\":1685464668016,\"y\":18.2},{\"x\":1685464968034,\"y\":18.2},{\"x\":1685465268109,\"y\":17.9},{\"x\":1685465568127,\"y\":17.9},{\"x\":1685465868179,\"y\":18},{\"x\":1685466168200,\"y\":18},{\"x\":1685466468292,\"y\":17.9},{\"x\":1685466783247,\"y\":17.9},{\"x\":1685467083281,\"y\":18},{\"x\":1685467383324,\"y\":18},{\"x\":1685467683356,\"y\":17.9},{\"x\":1685467983393,\"y\":17.9},{\"x\":1685468283508,\"y\":18},{\"x\":1685468598507,\"y\":17.9},{\"x\":1685468898532,\"y\":17.9},{\"x\":1685469198568,\"y\":17.9},{\"x\":1685469498602,\"y\":17.9},{\"x\":1685469798635,\"y\":17.9},{\"x\":1685470098653,\"y\":17.8},{\"x\":1685470398701,\"y\":17.8},{\"x\":1685470698741,\"y\":17.8},{\"x\":1685470998770,\"y\":17.7},{\"x\":1685471298800,\"y\":17.8},{\"x\":1685471598821,\"y\":17.9},{\"x\":1685471898877,\"y\":17.7},{\"x\":1685472198886,\"y\":17.7},{\"x\":1685472498957,\"y\":17.7},{\"x\":1685472798992,\"y\":17.7},{\"x\":1685473099049,\"y\":17.9},{\"x\":1685473414059,\"y\":17.9},{\"x\":1685473714086,\"y\":17.7},{\"x\":1685474014164,\"y\":17.6},{\"x\":1685474314238,\"y\":17.4},{\"x\":1685474629191,\"y\":17.5},{\"x\":1685474929212,\"y\":17.6},{\"x\":1685475229261,\"y\":17.7},{\"x\":1685475529275,\"y\":17.4},{\"x\":1685475829340,\"y\":17.4},{\"x\":1685476129417,\"y\":17.4},{\"x\":1685476429433,\"y\":17.4},{\"x\":1685476729449,\"y\":17.3},{\"x\":1685477029470,\"y\":17.2},{\"x\":1685477329512,\"y\":17.2},{\"x\":1685477629544,\"y\":17.3},{\"x\":1685477929562,\"y\":17.4},{\"x\":1685478229615,\"y\":17.3},{\"x\":1685478529641,\"y\":17},{\"x\":1685478829667,\"y\":16.5},{\"x\":1685479129749,\"y\":16.5},{\"x\":1685479429791,\"y\":16.5},{\"x\":1685479729807,\"y\":16.5},{\"x\":1685480029843,\"y\":16.5},{\"x\":1685480329850,\"y\":16.5},{\"x\":1685480629899,\"y\":16.7},{\"x\":1685480929954,\"y\":16.5},{\"x\":1685481244998,\"y\":16.5},{\"x\":1685481545012,\"y\":16.5},{\"x\":1685481845043,\"y\":16.5},{\"x\":1685482145093,\"y\":16.5},{\"x\":1685482445120,\"y\":16.5},{\"x\":1685482745153,\"y\":16.5},{\"x\":1685483045222,\"y\":16.5},{\"x\":1685483345235,\"y\":16.5},{\"x\":1685483645258,\"y\":16.5},{\"x\":1685483945299,\"y\":16.5},{\"x\":1685484245340,\"y\":16.5},{\"x\":1685484545382,\"y\":16.5},{\"x\":1685484845385,\"y\":16.5},{\"x\":1685485145425,\"y\":16.5},{\"x\":1685485445459,\"y\":16.5},{\"x\":1685485745479,\"y\":16.5},{\"x\":1685486045546,\"y\":16.5},{\"x\":1685486345575,\"y\":16.5},{\"x\":1685486645633,\"y\":16.5},{\"x\":1685486945725,\"y\":16.5},{\"x\":1685487260693,\"y\":16.5},{\"x\":1685487560707,\"y\":16.5},{\"x\":1685487860814,\"y\":16.5},{\"x\":1685488175808,\"y\":16.5},{\"x\":1685488475825,\"y\":16.5},{\"x\":1685488775853,\"y\":16.5},{\"x\":1685489075914,\"y\":16.5},{\"x\":1685489375930,\"y\":16.5},{\"x\":1685489675982,\"y\":16.5},{\"x\":1685489976039,\"y\":16.5},{\"x\":1685490276048,\"y\":16.5},{\"x\":1685490576126,\"y\":16.5},{\"x\":1685490876150,\"y\":16.5},{\"x\":1685491176154,\"y\":16.5},{\"x\":1685491476262,\"y\":16.5},{\"x\":1685491791218,\"y\":16.5},{\"x\":1685492091237,\"y\":16.5},{\"x\":1685492391276,\"y\":16.5},{\"x\":1685492691341,\"y\":16.5},{\"x\":1685492991352,\"y\":16.5},{\"x\":1685493291416,\"y\":16.5},{\"x\":1685493591464,\"y\":16.5},{\"x\":1685493891476,\"y\":16.2},{\"x\":1685494191553,\"y\":16.5},{\"x\":1685494491555,\"y\":16.5},{\"x\":1685494806655,\"y\":16.5},{\"x\":1685495121636,\"y\":16.5},{\"x\":1685495436647,\"y\":16.5},{\"x\":1685495736703,\"y\":16.5},{\"x\":1685496036726,\"y\":16.4},{\"x\":1685496336779,\"y\":16.5},{\"x\":1685496636854,\"y\":16.4},{\"x\":1685496951873,\"y\":16.4},{\"x\":1685497251911,\"y\":16.5},{\"x\":1685497566911,\"y\":16.5},{\"x\":1685497866915,\"y\":16.5},{\"x\":1685498166972,\"y\":16.2},{\"x\":1685498466989,\"y\":16.2},{\"x\":1685498767043,\"y\":16.4},{\"x\":1685499067095,\"y\":16.2},{\"x\":1685499367129,\"y\":16.5},{\"x\":1685499667180,\"y\":16.4},{\"x\":1685499967184,\"y\":16.5},{\"x\":1685500282215,\"y\":16.5},{\"x\":1685500582236,\"y\":16.5},{\"x\":1685500882309,\"y\":16.5},{\"x\":1685501197336,\"y\":16.4},{\"x\":1685501497371,\"y\":16.2},{\"x\":1685501797405,\"y\":16.3},{\"x\":1685502097446,\"y\":16.1},{\"x\":1685502397471,\"y\":16},{\"x\":1685502697518,\"y\":15.7},{\"x\":1685502997526,\"y\":16},{\"x\":1685503297549,\"y\":16},{\"x\":1685503597589,\"y\":16.2},{\"x\":1685503897624,\"y\":16.2},{\"x\":1685504197687,\"y\":16},{\"x\":1685504497728,\"y\":15.9},{\"x\":1685504797753,\"y\":16},{\"x\":1685505097809,\"y\":16},{\"x\":1685505397837,\"y\":16.2},{\"x\":1685505697885,\"y\":16.4},{\"x\":1685505997899,\"y\":16.3},{\"x\":1685506297916,\"y\":16.1},{\"x\":1685506597958,\"y\":16},{\"x\":1685506897987,\"y\":16},{\"x\":1685507198004,\"y\":15.8},{\"x\":1685507498078,\"y\":15.9},{\"x\":1685507798110,\"y\":16},{\"x\":1685508098131,\"y\":15.8},{\"x\":1685508398152,\"y\":16},{\"x\":1685508698194,\"y\":15.9},{\"x\":1685508998213,\"y\":15.8},{\"x\":1685509298220,\"y\":15.8},{\"x\":1685509598290,\"y\":15.9},{\"x\":1685509898323,\"y\":15.7},{\"x\":1685510198331,\"y\":15.7},{\"x\":1685510498370,\"y\":15.7},{\"x\":1685510798393,\"y\":15.5},{\"x\":1685511098454,\"y\":15.8},{\"x\":1685511398491,\"y\":15.7},{\"x\":1685511698520,\"y\":15.9},{\"x\":1685512013528,\"y\":15.9},{\"x\":1685512313605,\"y\":15.8},{\"x\":1685512628564,\"y\":15.7},{\"x\":1685512928630,\"y\":15.5},{\"x\":1685513228650,\"y\":15.5},{\"x\":1685513528663,\"y\":15.5},{\"x\":1685513828703,\"y\":15.6},{\"x\":1685514143711,\"y\":15.7},{\"x\":1685514443729,\"y\":15.7},{\"x\":1685514743749,\"y\":15.8},{\"x\":1685515043937,\"y\":15.7},{\"x\":1685515358896,\"y\":15.5},{\"x\":1685515658956,\"y\":15.6},{\"x\":1685515959007,\"y\":15.7},{\"x\":1685516259087,\"y\":15.6},{\"x\":1685516559112,\"y\":15.9},{\"x\":1685516859194,\"y\":16},{\"x\":1685517174175,\"y\":15.9},{\"x\":1685517474229,\"y\":15.8},{\"x\":1685517774323,\"y\":15.7},{\"x\":1685518074366,\"y\":15.7},{\"x\":1685518374438,\"y\":15.7},{\"x\":1685518674561,\"y\":15.9},{\"x\":1685518974586,\"y\":15.7},{\"x\":1685519274602,\"y\":16},{\"x\":1685519574700,\"y\":15.7},{\"x\":1685519889719,\"y\":15.8},{\"x\":1685520189753,\"y\":15.9},{\"x\":1685520489831,\"y\":15.8},{\"x\":1685520789861,\"y\":15.9},{\"x\":1685521089913,\"y\":16},{\"x\":1685521390016,\"y\":15.7},{\"x\":1685521690069,\"y\":15.5},{\"x\":1685521990135,\"y\":15.5},{\"x\":1685522290216,\"y\":15.5},{\"x\":1685522590301,\"y\":15.5},{\"x\":1685522905260,\"y\":15.7},{\"x\":1685523205311,\"y\":15.7},{\"x\":1685523505402,\"y\":15.7},{\"x\":1685523805456,\"y\":15.6},{\"x\":1685524105543,\"y\":15.9},{\"x\":1685524405592,\"y\":15.7},{\"x\":1685524705754,\"y\":15.5},{\"x\":1685525005757,\"y\":15.5},{\"x\":1685525305830,\"y\":15.7},{\"x\":1685525605894,\"y\":15.5},{\"x\":1685525905934,\"y\":15.7},{\"x\":1685526205944,\"y\":15.7},{\"x\":1685526505986,\"y\":15.5},{\"x\":1685526806078,\"y\":15.6},{\"x\":1685527106180,\"y\":15.8},{\"x\":1685527406287,\"y\":15.5},{\"x\":1685527706314,\"y\":15.6},{\"x\":1685528006417,\"y\":15.7},{\"x\":1685528306469,\"y\":15.8},{\"x\":1685528606541,\"y\":15.9},{\"x\":1685528906576,\"y\":15.7},{\"x\":1685529206598,\"y\":15.7},{\"x\":1685529506705,\"y\":15.7},{\"x\":1685529806799,\"y\":15.5},{\"x\":1685530106900,\"y\":15.7},{\"x\":1685530406997,\"y\":15.9},{\"x\":1685530707031,\"y\":15.9},{\"x\":1685531007135,\"y\":15.7},{\"x\":1685531307217,\"y\":15.9},{\"x\":1685531607277,\"y\":15.7},{\"x\":1685531907312,\"y\":15.9},{\"x\":1685532207333,\"y\":16},{\"x\":1685532507449,\"y\":15.9},{\"x\":1685532807538,\"y\":16},{\"x\":1685533107607,\"y\":15.9},{\"x\":1685533407716,\"y\":16.1},{\"x\":1685533707801,\"y\":16.4},{\"x\":1685534007891,\"y\":16.5},{\"x\":1685534307936,\"y\":17.9},{\"x\":1685534607976,\"y\":18.5},{\"x\":1685534908043,\"y\":19},{\"x\":1685535208090,\"y\":19.4},{\"x\":1685535508186,\"y\":19.5},{\"x\":1685535808331,\"y\":19.5},{\"x\":1685536108352,\"y\":19.5},{\"x\":1685536408438,\"y\":19.9},{\"x\":1685536708630,\"y\":20.2},{\"x\":1685537023666,\"y\":20.3},{\"x\":1685537323705,\"y\":20.5},{\"x\":1685537623753,\"y\":20.4},{\"x\":1685537923799,\"y\":20.4},{\"x\":1685538223965,\"y\":20.5},{\"x\":1685538538965,\"y\":20.4},{\"x\":1685538839060,\"y\":20.5},{\"x\":1685539139180,\"y\":20.5},{\"x\":1685539439233,\"y\":20.5},{\"x\":1685539739375,\"y\":20.4},{\"x\":1685540039424,\"y\":20.6},{\"x\":1685540339520,\"y\":20.4},{\"x\":1685540639601,\"y\":20.6},{\"x\":1685540939668,\"y\":20.5},{\"x\":1685541239749,\"y\":20.5},{\"x\":1685541539840,\"y\":20.8},{\"x\":1685541839913,\"y\":20.5},{\"x\":1685542139995,\"y\":20.4},{\"x\":1685542440177,\"y\":20.8},{\"x\":1685542740192,\"y\":20.4},{\"x\":1685543040283,\"y\":20.8},{\"x\":1685543340389,\"y\":20.5},{\"x\":1685543640471,\"y\":20.8},{\"x\":1685543940473,\"y\":20.5},{\"x\":1685544240621,\"y\":20.8},{\"x\":1685544540685,\"y\":20.5},{\"x\":1685544840799,\"y\":20.7},{\"x\":1685545140901,\"y\":20.5},{\"x\":1685545441001,\"y\":20.8},{\"x\":1685545741065,\"y\":20.6},{\"x\":1685546041186,\"y\":20.5},{\"x\":1685546341243,\"y\":20.7},{\"x\":1685546641292,\"y\":20.4},{\"x\":1685546941376,\"y\":20.8},{\"x\":1685547241438,\"y\":20.5},{\"x\":1685547541565,\"y\":20.8},{\"x\":1685547841634,\"y\":20.5},{\"x\":1685548141711,\"y\":20.8},{\"x\":1685548441854,\"y\":20.6},{\"x\":1685548741902,\"y\":20.5},{\"x\":1685549042002,\"y\":20.8},{\"x\":1685549342099,\"y\":20.5},{\"x\":1685549642156,\"y\":20.8},{\"x\":1685549942238,\"y\":20.7},{\"x\":1685550242287,\"y\":20.5},{\"x\":1685550542321,\"y\":20.8},{\"x\":1685550842435,\"y\":20.7},{\"x\":1685551142532,\"y\":20.5},{\"x\":1685551442679,\"y\":20.8},{\"x\":1685551742742,\"y\":20.8},{\"x\":1685552042824,\"y\":20.7},{\"x\":1685552342904,\"y\":20.6},{\"x\":1685552643024,\"y\":20.7},{\"x\":1685552943102,\"y\":20.7},{\"x\":1685553243197,\"y\":20.7},{\"x\":1685553543262,\"y\":20.7},{\"x\":1685553843353,\"y\":20.8},{\"x\":1685554143366,\"y\":20.8},{\"x\":1685554443531,\"y\":20.8},{\"x\":1685554743589,\"y\":20.8},{\"x\":1685555043690,\"y\":20.8},{\"x\":1685555343799,\"y\":20.8},{\"x\":1685555643872,\"y\":20.8},{\"x\":1685555943930,\"y\":20.8},{\"x\":1685556244056,\"y\":20.8},{\"x\":1685556544148,\"y\":20.8},{\"x\":1685556844209,\"y\":20.8},{\"x\":1685557144344,\"y\":20.7},{\"x\":1685557444363,\"y\":20.8},{\"x\":1685557744405,\"y\":20.7},{\"x\":1685558044539,\"y\":20.7},{\"x\":1685558344605,\"y\":20.7},{\"x\":1685558644713,\"y\":20.7},{\"x\":1685558944785,\"y\":20.7},{\"x\":1685559244901,\"y\":20.6},{\"x\":1685559544945,\"y\":20.6},{\"x\":1685559845042,\"y\":20.5},{\"x\":1685560145143,\"y\":20.5},{\"x\":1685560445241,\"y\":20.6},{\"x\":1685560745257,\"y\":20.5},{\"x\":1685561045328,\"y\":20.5},{\"x\":1685561345445,\"y\":20.5},{\"x\":1685561645525,\"y\":20.6},{\"x\":1685561945646,\"y\":20.8},{\"x\":1685562245696,\"y\":20.7},{\"x\":1685562545795,\"y\":20.6},{\"x\":1685562845871,\"y\":20.7},{\"x\":1685563145971,\"y\":20.8},{\"x\":1685563446094,\"y\":20.7},{\"x\":1685563746173,\"y\":20.5},{\"x\":1685564046283,\"y\":20.8},{\"x\":1685564346314,\"y\":20.8},{\"x\":1685564646386,\"y\":20.7},{\"x\":1685564946460,\"y\":20.6},{\"x\":1685565246561,\"y\":20.5},{\"x\":1685565546656,\"y\":20.7},{\"x\":1685565846745,\"y\":20.8},{\"x\":1685566146812,\"y\":20.6},{\"x\":1685566446933,\"y\":20.7},{\"x\":1685566746982,\"y\":20.7},{\"x\":1685567047084,\"y\":20.5},{\"x\":1685567347176,\"y\":20.8},{\"x\":1685567647243,\"y\":20.5},{\"x\":1685567947275,\"y\":20.8},{\"x\":1685568247414,\"y\":20.8},{\"x\":1685568547487,\"y\":20.8},{\"x\":1685568847582,\"y\":20.6},{\"x\":1685569147698,\"y\":20.6},{\"x\":1685569447750,\"y\":20.5},{\"x\":1685569747835,\"y\":20.8},{\"x\":1685570047948,\"y\":20.7},{\"x\":1685570348041,\"y\":20.5},{\"x\":1685570648135,\"y\":20.7},{\"x\":1685570948186,\"y\":20.7},{\"x\":1685571248285,\"y\":20.5},{\"x\":1685571548397,\"y\":20.7},{\"x\":1685571848461,\"y\":20.6},{\"x\":1685572148552,\"y\":20.7},{\"x\":1685572448646,\"y\":20.8},{\"x\":1685572748724,\"y\":20.7},{\"x\":1685573048812,\"y\":20.4},{\"x\":1685573348924,\"y\":20.8},{\"x\":1685573648998,\"y\":20.7},{\"x\":1685573949035,\"y\":20.5},{\"x\":1685574249162,\"y\":20.7},{\"x\":1685574564170,\"y\":20.5},{\"x\":1685574864211,\"y\":20.3},{\"x\":1685575164295,\"y\":20.3},{\"x\":1685575464392,\"y\":20.3},{\"x\":1685575764473,\"y\":20.2},{\"x\":1685576064520,\"y\":20},{\"x\":1685576364561,\"y\":19.9},{\"x\":1685576664649,\"y\":19.6},{\"x\":1685576964764,\"y\":19.5},{\"x\":1685577264783,\"y\":19.5},{\"x\":1685577564825,\"y\":19.5},{\"x\":1685577864898,\"y\":19.5},{\"x\":1685578165022,\"y\":19.5},{\"x\":1685578465041,\"y\":19.5},{\"x\":1685578765123,\"y\":19.5},{\"x\":1685579065190,\"y\":19.5},{\"x\":1685579365242,\"y\":19.5},{\"x\":1685579665270,\"y\":19.5},{\"x\":1685579965342,\"y\":19.5},{\"x\":1685580265419,\"y\":19.5},{\"x\":1685580565474,\"y\":19.5},{\"x\":1685580865528,\"y\":19.5},{\"x\":1685581165617,\"y\":19.5},{\"x\":1685581465707,\"y\":19.5},{\"x\":1685581765780,\"y\":19.5},{\"x\":1685582065871,\"y\":19.5},{\"x\":1685582365914,\"y\":19.5},{\"x\":1685582665994,\"y\":19.5},{\"x\":1685582966029,\"y\":19.5},{\"x\":1685583266054,\"y\":19.5},{\"x\":1685583566137,\"y\":19.5},{\"x\":1685583866167,\"y\":19.5},{\"x\":1685584166249,\"y\":19.5},{\"x\":1685584466332,\"y\":19.5},{\"x\":1685584766387,\"y\":19.5},{\"x\":1685585066444,\"y\":19.5},{\"x\":1685585366558,\"y\":19.5},{\"x\":1685585666591,\"y\":19.5},{\"x\":1685585966705,\"y\":19.5},{\"x\":1685586281700,\"y\":19.5},{\"x\":1685586581763,\"y\":19.5},{\"x\":1685586881831,\"y\":19.5},{\"x\":1685587181935,\"y\":19.5},{\"x\":1685587481999,\"y\":19.4},{\"x\":1685587782043,\"y\":19.4},{\"x\":1685588082116,\"y\":19.4},{\"x\":1685588382188,\"y\":19.4},{\"x\":1685588682255,\"y\":19.4},{\"x\":1685588982296,\"y\":19.4},{\"x\":1685589282341,\"y\":19.3},{\"x\":1685589582405,\"y\":19.4},{\"x\":1685589882472,\"y\":19.4},{\"x\":1685590182540,\"y\":19.3},{\"x\":1685590482618,\"y\":19.3},{\"x\":1685590782722,\"y\":19.3},{\"x\":1685591082771,\"y\":19.3},{\"x\":1685591382819,\"y\":19.2},{\"x\":1685591682931,\"y\":19.2},{\"x\":1685591982967,\"y\":19.2},{\"x\":1685592282986,\"y\":19.2},{\"x\":1685592583082,\"y\":19.2},{\"x\":1685592883165,\"y\":19.2},{\"x\":1685593183195,\"y\":19.2},{\"x\":1685593483277,\"y\":19.1},{\"x\":1685593783380,\"y\":19.2},{\"x\":1685594083450,\"y\":19.2},{\"x\":1685594383491,\"y\":19.2},{\"x\":1685594683592,\"y\":19.1},{\"x\":1685594983618,\"y\":19.1},{\"x\":1685595283711,\"y\":19.1},{\"x\":1685595583730,\"y\":19.1},{\"x\":1685595883817,\"y\":19},{\"x\":1685596183896,\"y\":19},{\"x\":1685596483953,\"y\":19},{\"x\":1685596784061,\"y\":19},{\"x\":1685597084124,\"y\":19},{\"x\":1685597384139,\"y\":19.1},{\"x\":1685597684213,\"y\":19},{\"x\":1685597984240,\"y\":19},{\"x\":1685598284312,\"y\":19},{\"x\":1685598584338,\"y\":19},{\"x\":1685598884381,\"y\":19},{\"x\":1685599184436,\"y\":19},{\"x\":1685599499407,\"y\":19},{\"x\":1685599799490,\"y\":18.9},{\"x\":1685600099528,\"y\":19},{\"x\":1685600399539,\"y\":19},{\"x\":1685600699637,\"y\":19},{\"x\":1685600999644,\"y\":19},{\"x\":1685601299689,\"y\":19},{\"x\":1685601599758,\"y\":19},{\"x\":1685601899826,\"y\":19},{\"x\":1685602199848,\"y\":18.9},{\"x\":1685602499869,\"y\":18.9},{\"x\":1685602799939,\"y\":19},{\"x\":1685603099979,\"y\":18.9},{\"x\":1685603414978,\"y\":18.9},{\"x\":1685603715053,\"y\":19},{\"x\":1685604030039,\"y\":19},{\"x\":1685604330117,\"y\":19},{\"x\":1685604630167,\"y\":19},{\"x\":1685604930199,\"y\":19},{\"x\":1685605230238,\"y\":18.9},{\"x\":1685605530260,\"y\":19},{\"x\":1685605830318,\"y\":19},{\"x\":1685606130319,\"y\":19},{\"x\":1685606430335,\"y\":19},{\"x\":1685606730393,\"y\":19},{\"x\":1685607030458,\"y\":19},{\"x\":1685607330485,\"y\":19.5},{\"x\":1685607630516,\"y\":20.3},{\"x\":1685607930568,\"y\":20.6},{\"x\":1685608230576,\"y\":20.4},{\"x\":1685608530643,\"y\":20.5},{\"x\":1685608830684,\"y\":20.5},{\"x\":1685609130723,\"y\":20.5},{\"x\":1685609430778,\"y\":20.5},{\"x\":1685609745753,\"y\":20.7},{\"x\":1685610045798,\"y\":20.4},{\"x\":1685610345834,\"y\":20.7},{\"x\":1685610645876,\"y\":20.4},{\"x\":1685610945921,\"y\":20.8},{\"x\":1685611245935,\"y\":20.5},{\"x\":1685611545963,\"y\":20.8},{\"x\":1685611845989,\"y\":20.6},{\"x\":1685612146117,\"y\":20.5},{\"x\":1685612446189,\"y\":20.8},{\"x\":1685612746312,\"y\":20.6},{\"x\":1685613046346,\"y\":20.5},{\"x\":1685613346425,\"y\":20.8},{\"x\":1685613646580,\"y\":20.6},{\"x\":1685613961556,\"y\":20.6},{\"x\":1685614261648,\"y\":20.7},{\"x\":1685614576669,\"y\":20.7},{\"x\":1685614876695,\"y\":20.5},{\"x\":1685615176733,\"y\":20.4},{\"x\":1685615476808,\"y\":20.7},{\"x\":1685615776863,\"y\":20.7},{\"x\":1685616076917,\"y\":20.5},{\"x\":1685616376987,\"y\":20.4},{\"x\":1685616677033,\"y\":20.3},{\"x\":1685616977113,\"y\":20.3},{\"x\":1685617277203,\"y\":20.3},{\"x\":1685617577236,\"y\":20.3},{\"x\":1685617877275,\"y\":20.2},{\"x\":1685618177324,\"y\":20.3},{\"x\":1685618477408,\"y\":20.2},{\"x\":1685618777447,\"y\":20.3},{\"x\":1685619077601,\"y\":20.2},{\"x\":1685619377646,\"y\":20.2},{\"x\":1685619677730,\"y\":20.1},{\"x\":1685619977761,\"y\":20.2},{\"x\":1685620017473,\"y\":20.1},{\"x\":1685620080667,\"y\":20.1}],[{\"x\":1685015251039,\"y\":19.18},{\"x\":1685015551015,\"y\":19.18},{\"x\":1685015851010,\"y\":19.18},{\"x\":1685016151028,\"y\":19.09},{\"x\":1685016451042,\"y\":18.75},{\"x\":1685016751019,\"y\":18.66},{\"x\":1685017051028,\"y\":18.75},{\"x\":1685017351047,\"y\":18.89},{\"x\":1685017651031,\"y\":18.8},{\"x\":1685017951098,\"y\":18.83},{\"x\":1685018251018,\"y\":18.3},{\"x\":1685018551020,\"y\":18.3},{\"x\":1685018851032,\"y\":18.36},{\"x\":1685019151038,\"y\":18.36},{\"x\":1685019451035,\"y\":19.14},{\"x\":1685019751031,\"y\":19.04},{\"x\":1685020051038,\"y\":19.64},{\"x\":1685020351040,\"y\":19.42},{\"x\":1685020651063,\"y\":19.88},{\"x\":1685020951079,\"y\":19.73},{\"x\":1685021251036,\"y\":19.73},{\"x\":1685021551137,\"y\":19.54},{\"x\":1685021851047,\"y\":19.21},{\"x\":1685022151057,\"y\":19.13},{\"x\":1685022451042,\"y\":19.21},{\"x\":1685022751080,\"y\":19.1},{\"x\":1685023051043,\"y\":18.46},{\"x\":1685023351058,\"y\":18.46},{\"x\":1685023651118,\"y\":18.47},{\"x\":1685023951188,\"y\":18.48},{\"x\":1685024251055,\"y\":18.48},{\"x\":1685024551051,\"y\":18.44},{\"x\":1685024851052,\"y\":18.44},{\"x\":1685025151135,\"y\":18.73},{\"x\":1685025451076,\"y\":18.73},{\"x\":1685025751061,\"y\":18.73},{\"x\":1685026051071,\"y\":19.02},{\"x\":1685026351158,\"y\":19.05},{\"x\":1685026651115,\"y\":19.03},{\"x\":1685026951071,\"y\":19.03},{\"x\":1685027251066,\"y\":19.03},{\"x\":1685027551148,\"y\":18.62},{\"x\":1685027851058,\"y\":18.62},{\"x\":1685028151059,\"y\":18.62},{\"x\":1685028451112,\"y\":19},{\"x\":1685028751146,\"y\":18.91},{\"x\":1685029051091,\"y\":18.1},{\"x\":1685029351104,\"y\":18.12},{\"x\":1685029651134,\"y\":18.51},{\"x\":1685029951350,\"y\":18.12},{\"x\":1685030251085,\"y\":18.51},{\"x\":1685030551087,\"y\":18.42},{\"x\":1685030851113,\"y\":18.46},{\"x\":1685031151160,\"y\":18.37},{\"x\":1685031451109,\"y\":18.33},{\"x\":1685031751080,\"y\":18.21},{\"x\":1685032051082,\"y\":18.3},{\"x\":1685032351518,\"y\":18.3},{\"x\":1685032651206,\"y\":17.89},{\"x\":1685032951081,\"y\":17.8},{\"x\":1685033251086,\"y\":17.8},{\"x\":1685033551096,\"y\":17.8},{\"x\":1685033851075,\"y\":17.8},{\"x\":1685034151086,\"y\":17.78},{\"x\":1685034451139,\"y\":17.63},{\"x\":1685034751066,\"y\":17.63},{\"x\":1685035051075,\"y\":17.63},{\"x\":1685035351084,\"y\":17.54},{\"x\":1685035651091,\"y\":17.54},{\"x\":1685035951102,\"y\":17.55},{\"x\":1685036251109,\"y\":17.28},{\"x\":1685036551080,\"y\":17.54},{\"x\":1685036851085,\"y\":17.25},{\"x\":1685037151113,\"y\":17.2},{\"x\":1685037451085,\"y\":16.99},{\"x\":1685037751124,\"y\":16.99},{\"x\":1685038051100,\"y\":16.99},{\"x\":1685038351547,\"y\":17.1},{\"x\":1685038651116,\"y\":17.02},{\"x\":1685038951187,\"y\":16.94},{\"x\":1685039251190,\"y\":16.88},{\"x\":1685039551190,\"y\":16.85},{\"x\":1685039851181,\"y\":16.85},{\"x\":1685040151138,\"y\":16.82},{\"x\":1685040451132,\"y\":16.79},{\"x\":1685040751183,\"y\":16.79},{\"x\":1685041051160,\"y\":16.79},{\"x\":1685041351171,\"y\":16.7},{\"x\":1685041651173,\"y\":16.44},{\"x\":1685041951215,\"y\":16.44},{\"x\":1685042251220,\"y\":16.48},{\"x\":1685042551262,\"y\":16.52},{\"x\":1685042851204,\"y\":16.48},{\"x\":1685043151252,\"y\":16.52},{\"x\":1685043451209,\"y\":16.4},{\"x\":1685043751246,\"y\":16.26},{\"x\":1685044051210,\"y\":16.26},{\"x\":1685044351522,\"y\":16.26},{\"x\":1685044651215,\"y\":16.17},{\"x\":1685044951218,\"y\":16.17},{\"x\":1685045251281,\"y\":15.98},{\"x\":1685045551345,\"y\":15.98},{\"x\":1685045851232,\"y\":16.01},{\"x\":1685046151240,\"y\":15.98},{\"x\":1685046451276,\"y\":15.75},{\"x\":1685046751262,\"y\":15.75},{\"x\":1685047051266,\"y\":15.75},{\"x\":1685047351285,\"y\":15.68},{\"x\":1685047651267,\"y\":15.68},{\"x\":1685047951728,\"y\":15.49},{\"x\":1685048251321,\"y\":15.5},{\"x\":1685048551265,\"y\":15.49},{\"x\":1685048851352,\"y\":15.35},{\"x\":1685049151302,\"y\":15.35},{\"x\":1685049451264,\"y\":14.98},{\"x\":1685049751268,\"y\":14.98},{\"x\":1685050051322,\"y\":14.97},{\"x\":1685050351309,\"y\":14.97},{\"x\":1685050651266,\"y\":14.75},{\"x\":1685050951264,\"y\":14.75},{\"x\":1685051251276,\"y\":14.82},{\"x\":1685051551291,\"y\":14.73},{\"x\":1685051851384,\"y\":14.57},{\"x\":1685052151274,\"y\":14.41},{\"x\":1685052451281,\"y\":14.41},{\"x\":1685052751280,\"y\":14.35},{\"x\":1685053051279,\"y\":14.49},{\"x\":1685053351326,\"y\":14.29},{\"x\":1685053651310,\"y\":14.3},{\"x\":1685053951323,\"y\":14.29},{\"x\":1685054251377,\"y\":13.95},{\"x\":1685054551303,\"y\":13.95},{\"x\":1685054851307,\"y\":13.95},{\"x\":1685055151655,\"y\":13.71},{\"x\":1685055451302,\"y\":13.71},{\"x\":1685055751335,\"y\":13.58},{\"x\":1685056051330,\"y\":13.55},{\"x\":1685056351435,\"y\":13.58},{\"x\":1685056651370,\"y\":13.33},{\"x\":1685056951348,\"y\":13.58},{\"x\":1685057251335,\"y\":13.23},{\"x\":1685057551642,\"y\":13.23},{\"x\":1685057851342,\"y\":13.23},{\"x\":1685058151360,\"y\":12.98},{\"x\":1685058451395,\"y\":13},{\"x\":1685058751511,\"y\":13.01},{\"x\":1685059051391,\"y\":13.01},{\"x\":1685059351339,\"y\":12.9},{\"x\":1685059651359,\"y\":12.9},{\"x\":1685059951438,\"y\":12.48},{\"x\":1685060251356,\"y\":12.48},{\"x\":1685060551372,\"y\":12.48},{\"x\":1685060851371,\"y\":12.32},{\"x\":1685061151374,\"y\":12.32},{\"x\":1685061451412,\"y\":11.72},{\"x\":1685061751394,\"y\":11.63},{\"x\":1685062051381,\"y\":11.72},{\"x\":1685062352047,\"y\":11.55},{\"x\":1685062651444,\"y\":11.36},{\"x\":1685062951373,\"y\":11.46},{\"x\":1685063251410,\"y\":11.36},{\"x\":1685063551479,\"y\":11.37},{\"x\":1685063851380,\"y\":11.36},{\"x\":1685064151391,\"y\":11.44},{\"x\":1685064451471,\"y\":11.34},{\"x\":1685064751589,\"y\":11.32},{\"x\":1685065051396,\"y\":11.26},{\"x\":1685065351399,\"y\":11.22},{\"x\":1685065651409,\"y\":11.39},{\"x\":1685065952272,\"y\":11.33},{\"x\":1685066251396,\"y\":11.21},{\"x\":1685066551403,\"y\":11.21},{\"x\":1685066851417,\"y\":11.34},{\"x\":1685067151442,\"y\":11.28},{\"x\":1685067451399,\"y\":11.27},{\"x\":1685067751460,\"y\":11.06},{\"x\":1685068051420,\"y\":11.27},{\"x\":1685068351485,\"y\":11.02},{\"x\":1685068651412,\"y\":11.02},{\"x\":1685068951402,\"y\":10.91},{\"x\":1685069251450,\"y\":11},{\"x\":1685069551482,\"y\":11},{\"x\":1685069851414,\"y\":10.88},{\"x\":1685070151414,\"y\":10.66},{\"x\":1685070451408,\"y\":10.66},{\"x\":1685070752331,\"y\":10.76},{\"x\":1685071051424,\"y\":10.76},{\"x\":1685071351428,\"y\":10.76},{\"x\":1685071651498,\"y\":10.55},{\"x\":1685071951451,\"y\":10.55},{\"x\":1685072251483,\"y\":10.55},{\"x\":1685072551428,\"y\":10.55},{\"x\":1685072851477,\"y\":10.34},{\"x\":1685073151490,\"y\":10.34},{\"x\":1685073451401,\"y\":10.34},{\"x\":1685073751433,\"y\":10.08},{\"x\":1685074051433,\"y\":10.08},{\"x\":1685074351659,\"y\":9.98},{\"x\":1685074651481,\"y\":9.98},{\"x\":1685074951442,\"y\":9.98},{\"x\":1685075251486,\"y\":9.76},{\"x\":1685075553145,\"y\":9.76},{\"x\":1685075851454,\"y\":9.76},{\"x\":1685076151559,\"y\":9.76},{\"x\":1685076451455,\"y\":9.76},{\"x\":1685076751637,\"y\":9.76},{\"x\":1685077051562,\"y\":10.23},{\"x\":1685077351466,\"y\":10.23},{\"x\":1685077651495,\"y\":10.23},{\"x\":1685077951596,\"y\":10.15},{\"x\":1685078251465,\"y\":10.36},{\"x\":1685078551490,\"y\":10.36},{\"x\":1685078851486,\"y\":10.82},{\"x\":1685079152413,\"y\":10.82},{\"x\":1685079451481,\"y\":11.06},{\"x\":1685079751484,\"y\":11.06},{\"x\":1685080051515,\"y\":11.26},{\"x\":1685080353153,\"y\":11.08},{\"x\":1685080651466,\"y\":11.37},{\"x\":1685080951559,\"y\":11.85},{\"x\":1685081251496,\"y\":12.07},{\"x\":1685081552662,\"y\":11.54},{\"x\":1685081851505,\"y\":11.54},{\"x\":1685082151498,\"y\":12.9},{\"x\":1685082451574,\"y\":11.98},{\"x\":1685082752768,\"y\":12.05},{\"x\":1685083051516,\"y\":12.05},{\"x\":1685083351518,\"y\":12.54},{\"x\":1685083651522,\"y\":12.54},{\"x\":1685083951825,\"y\":13.01},{\"x\":1685084251526,\"y\":13.01},{\"x\":1685084551531,\"y\":13.84},{\"x\":1685084851537,\"y\":14.15},{\"x\":1685085154315,\"y\":14.2},{\"x\":1685085451540,\"y\":14.2},{\"x\":1685085751599,\"y\":14.74},{\"x\":1685086051532,\"y\":14.65},{\"x\":1685086352440,\"y\":14.65},{\"x\":1685086651538,\"y\":15.31},{\"x\":1685086951544,\"y\":15.31},{\"x\":1685087251583,\"y\":15.43},{\"x\":1685087552469,\"y\":15.61},{\"x\":1685087851550,\"y\":15.43},{\"x\":1685088151549,\"y\":15.75},{\"x\":1685088451547,\"y\":15.75},{\"x\":1685088752994,\"y\":16.44},{\"x\":1685089051545,\"y\":16.44},{\"x\":1685089351589,\"y\":16.84},{\"x\":1685089651598,\"y\":16.44},{\"x\":1685089952825,\"y\":16.84},{\"x\":1685090251561,\"y\":17.35},{\"x\":1685090551636,\"y\":17.66},{\"x\":1685090851564,\"y\":17.56},{\"x\":1685091152016,\"y\":17.66},{\"x\":1685091451594,\"y\":17.93},{\"x\":1685091751567,\"y\":18.04},{\"x\":1685092051581,\"y\":17.93},{\"x\":1685092352469,\"y\":18.08},{\"x\":1685092651613,\"y\":18.17},{\"x\":1685092951598,\"y\":18.25},{\"x\":1685093251572,\"y\":18.23},{\"x\":1685093551684,\"y\":18.43},{\"x\":1685093851596,\"y\":18.5},{\"x\":1685094151578,\"y\":18.5},{\"x\":1685094451581,\"y\":18.85},{\"x\":1685094753849,\"y\":18.85},{\"x\":1685095051634,\"y\":19.17},{\"x\":1685095351592,\"y\":19.09},{\"x\":1685095651582,\"y\":19.37},{\"x\":1685095952262,\"y\":19.37},{\"x\":1685096251665,\"y\":19.46},{\"x\":1685096551653,\"y\":19.46},{\"x\":1685096851597,\"y\":19.46},{\"x\":1685097151894,\"y\":19.32},{\"x\":1685097451605,\"y\":19.59},{\"x\":1685097751603,\"y\":19.85},{\"x\":1685098051603,\"y\":19.75},{\"x\":1685098351825,\"y\":19.65},{\"x\":1685098651611,\"y\":19.82},{\"x\":1685098951612,\"y\":19.65},{\"x\":1685099251620,\"y\":19.57},{\"x\":1685099554557,\"y\":19.84},{\"x\":1685099851611,\"y\":19.98},{\"x\":1685100151610,\"y\":19.98},{\"x\":1685100451674,\"y\":19.9},{\"x\":1685100751631,\"y\":19.9},{\"x\":1685101051671,\"y\":20.45},{\"x\":1685101351650,\"y\":20.45},{\"x\":1685101651625,\"y\":20.45},{\"x\":1685101952592,\"y\":19.74},{\"x\":1685102251628,\"y\":19.74},{\"x\":1685102551620,\"y\":19.74},{\"x\":1685102851630,\"y\":19.84},{\"x\":1685103152663,\"y\":20.53},{\"x\":1685103451625,\"y\":20.53},{\"x\":1685103751638,\"y\":20.37},{\"x\":1685104051653,\"y\":20.37},{\"x\":1685104351690,\"y\":20.42},{\"x\":1685104651625,\"y\":20.92},{\"x\":1685104951669,\"y\":21.05},{\"x\":1685105251635,\"y\":20.92},{\"x\":1685106270209,\"y\":21.51},{\"x\":1685106570210,\"y\":21.28},{\"x\":1685106870262,\"y\":21.31},{\"x\":1685107170259,\"y\":20.87},{\"x\":1685107470202,\"y\":20.87},{\"x\":1685107770205,\"y\":20.87},{\"x\":1685108070201,\"y\":20.24},{\"x\":1685108370268,\"y\":20.24},{\"x\":1685108670211,\"y\":20.81},{\"x\":1685108970215,\"y\":20.61},{\"x\":1685109270264,\"y\":21.02},{\"x\":1685109570225,\"y\":21.02},{\"x\":1685109870210,\"y\":21.35},{\"x\":1685110170276,\"y\":21.42},{\"x\":1685110470215,\"y\":21.08},{\"x\":1685110770218,\"y\":21.08},{\"x\":1685111070267,\"y\":21.3},{\"x\":1685111370237,\"y\":21.32},{\"x\":1685111670242,\"y\":21.21},{\"x\":1685111970278,\"y\":21.56},{\"x\":1685112270243,\"y\":21.43},{\"x\":1685112570286,\"y\":20.62},{\"x\":1685112870312,\"y\":20.61},{\"x\":1685113170279,\"y\":20.61},{\"x\":1685113470259,\"y\":20.52},{\"x\":1685113770274,\"y\":21.03},{\"x\":1685114070330,\"y\":20.96},{\"x\":1685114370346,\"y\":20.62},{\"x\":1685114670290,\"y\":20.62},{\"x\":1685114970303,\"y\":20.62},{\"x\":1685115270293,\"y\":20.57},{\"x\":1685115570345,\"y\":20.81},{\"x\":1685115870301,\"y\":20.81},{\"x\":1685116170341,\"y\":20.85},{\"x\":1685116470425,\"y\":20.35},{\"x\":1685116770319,\"y\":20.73},{\"x\":1685117070306,\"y\":20.35},{\"x\":1685117370344,\"y\":20.75},{\"x\":1685117670330,\"y\":20.75},{\"x\":1685117970336,\"y\":20.75},{\"x\":1685118270330,\"y\":20.45},{\"x\":1685118570325,\"y\":20.45},{\"x\":1685118870362,\"y\":19.95},{\"x\":1685119170359,\"y\":19.95},{\"x\":1685119470369,\"y\":19.95},{\"x\":1685119770365,\"y\":19.92},{\"x\":1685120070363,\"y\":20.06},{\"x\":1685120370385,\"y\":20.17},{\"x\":1685120670359,\"y\":20.17},{\"x\":1685120970383,\"y\":20.08},{\"x\":1685121270373,\"y\":19.95},{\"x\":1685121570376,\"y\":19.85},{\"x\":1685121870394,\"y\":19.88},{\"x\":1685122170385,\"y\":19.88},{\"x\":1685122470467,\"y\":19},{\"x\":1685122770415,\"y\":19},{\"x\":1685123070412,\"y\":19},{\"x\":1685123370409,\"y\":18.86},{\"x\":1685123670402,\"y\":18.86},{\"x\":1685123970418,\"y\":18.86},{\"x\":1685124270399,\"y\":18.86},{\"x\":1685124570415,\"y\":18.79},{\"x\":1685124870446,\"y\":18.79},{\"x\":1685125170457,\"y\":18.85},{\"x\":1685125470494,\"y\":18.85},{\"x\":1685125770424,\"y\":18.85},{\"x\":1685126070436,\"y\":18.71},{\"x\":1685126370464,\"y\":18.71},{\"x\":1685126670446,\"y\":18.67},{\"x\":1685126970458,\"y\":18.67},{\"x\":1685127270730,\"y\":17.76},{\"x\":1685127570540,\"y\":17.84},{\"x\":1685127870479,\"y\":17.42},{\"x\":1685128170488,\"y\":17.42},{\"x\":1685128470446,\"y\":17.32},{\"x\":1685128770711,\"y\":17.38},{\"x\":1685129070493,\"y\":17.55},{\"x\":1685129370460,\"y\":17.46},{\"x\":1685129670456,\"y\":17.51},{\"x\":1685129970444,\"y\":16.98},{\"x\":1685130270452,\"y\":16.94},{\"x\":1685130570463,\"y\":16.94},{\"x\":1685130870454,\"y\":16.63},{\"x\":1685131170558,\"y\":16.63},{\"x\":1685131470459,\"y\":16.63},{\"x\":1685131770480,\"y\":15.83},{\"x\":1685132070539,\"y\":15.61},{\"x\":1685132370654,\"y\":15.61},{\"x\":1685132670510,\"y\":15.17},{\"x\":1685132970470,\"y\":15.17},{\"x\":1685133270483,\"y\":15.17},{\"x\":1685133570534,\"y\":15.33},{\"x\":1685133870537,\"y\":15.17},{\"x\":1685134170481,\"y\":15.33},{\"x\":1685134470522,\"y\":15.17},{\"x\":1685134770619,\"y\":15.17},{\"x\":1685135070468,\"y\":15.17},{\"x\":1685135370539,\"y\":14.12},{\"x\":1685135670470,\"y\":14.12},{\"x\":1685135970588,\"y\":14.12},{\"x\":1685136270506,\"y\":13.94},{\"x\":1685136570482,\"y\":13.94},{\"x\":1685136870483,\"y\":13.88},{\"x\":1685137170591,\"y\":13.53},{\"x\":1685137470482,\"y\":13.29},{\"x\":1685137770513,\"y\":13.29},{\"x\":1685138070565,\"y\":13.24},{\"x\":1685138370612,\"y\":13.3},{\"x\":1685138670513,\"y\":12.65},{\"x\":1685138970488,\"y\":13.03},{\"x\":1685139270567,\"y\":12.44},{\"x\":1685139570520,\"y\":12.44},{\"x\":1685139870495,\"y\":12.47},{\"x\":1685140170514,\"y\":12.41},{\"x\":1685140470469,\"y\":12.41},{\"x\":1685140770566,\"y\":12.32},{\"x\":1685141070532,\"y\":11.91},{\"x\":1685141370505,\"y\":11.91},{\"x\":1685141670535,\"y\":11.91},{\"x\":1685141970572,\"y\":11.87},{\"x\":1685142270528,\"y\":11.87},{\"x\":1685142570539,\"y\":11.49},{\"x\":1685142870540,\"y\":11.49},{\"x\":1685143170721,\"y\":11.69},{\"x\":1685143470532,\"y\":11.69},{\"x\":1685143770537,\"y\":11.69},{\"x\":1685144070587,\"y\":11.38},{\"x\":1685144370585,\"y\":11.29},{\"x\":1685144670544,\"y\":11.38},{\"x\":1685144970592,\"y\":11.66},{\"x\":1685145270578,\"y\":11.66},{\"x\":1685145570616,\"y\":11.66},{\"x\":1685145870578,\"y\":11.54},{\"x\":1685146170575,\"y\":11.3},{\"x\":1685146470586,\"y\":11.26},{\"x\":1685146770618,\"y\":10.97},{\"x\":1685147070575,\"y\":10.97},{\"x\":1685147370627,\"y\":11.06},{\"x\":1685147670593,\"y\":10.78},{\"x\":1685147970600,\"y\":11.06},{\"x\":1685148270605,\"y\":10.65},{\"x\":1685148570644,\"y\":10.63},{\"x\":1685148870584,\"y\":10.63},{\"x\":1685149170590,\"y\":10.63},{\"x\":1685149470587,\"y\":10.44},{\"x\":1685149770583,\"y\":10.44},{\"x\":1685150070580,\"y\":10.1},{\"x\":1685150370584,\"y\":10.1},{\"x\":1685150670582,\"y\":10.03},{\"x\":1685150970594,\"y\":10.03},{\"x\":1685151270632,\"y\":10.08},{\"x\":1685151570591,\"y\":10.08},{\"x\":1685151870605,\"y\":9.61},{\"x\":1685152170611,\"y\":9.61},{\"x\":1685152470611,\"y\":9.42},{\"x\":1685152770613,\"y\":9.42},{\"x\":1685153070628,\"y\":9.48},{\"x\":1685153370683,\"y\":9.39},{\"x\":1685153670664,\"y\":9.33},{\"x\":1685153970636,\"y\":9.33},{\"x\":1685154270611,\"y\":9.33},{\"x\":1685154570650,\"y\":9.14},{\"x\":1685154870623,\"y\":9.14},{\"x\":1685155170939,\"y\":9.05},{\"x\":1685155470674,\"y\":8.95},{\"x\":1685155770628,\"y\":8.95},{\"x\":1685156070642,\"y\":8.86},{\"x\":1685156370678,\"y\":8.95},{\"x\":1685156670691,\"y\":8.95},{\"x\":1685156970647,\"y\":8.95},{\"x\":1685157270649,\"y\":8.48},{\"x\":1685157570728,\"y\":8.51},{\"x\":1685157870653,\"y\":8.67},{\"x\":1685158170653,\"y\":8.67},{\"x\":1685158470652,\"y\":8.47},{\"x\":1685158770755,\"y\":8.29},{\"x\":1685159070671,\"y\":8.29},{\"x\":1685159370691,\"y\":8.19},{\"x\":1685159670661,\"y\":8.19},{\"x\":1685159971379,\"y\":8.08},{\"x\":1685160270711,\"y\":8.04},{\"x\":1685160570739,\"y\":8.22},{\"x\":1685160870655,\"y\":8.22},{\"x\":1685161170787,\"y\":8.04},{\"x\":1685161470703,\"y\":8.24},{\"x\":1685161770668,\"y\":8.04},{\"x\":1685162070717,\"y\":8.02},{\"x\":1685162371170,\"y\":7.93},{\"x\":1685162670708,\"y\":8.02},{\"x\":1685162970719,\"y\":8.55},{\"x\":1685163270676,\"y\":8.55},{\"x\":1685163571126,\"y\":8.55},{\"x\":1685163870678,\"y\":8.77},{\"x\":1685164170681,\"y\":8.69},{\"x\":1685164470773,\"y\":9.46},{\"x\":1685164771057,\"y\":9.68},{\"x\":1685165070675,\"y\":9.97},{\"x\":1685165370677,\"y\":9.83},{\"x\":1685165670713,\"y\":10.29},{\"x\":1685165970916,\"y\":10.29},{\"x\":1685166270681,\"y\":10.47},{\"x\":1685166570684,\"y\":10.47},{\"x\":1685166870680,\"y\":11},{\"x\":1685167171095,\"y\":10.85},{\"x\":1685167470678,\"y\":11.53},{\"x\":1685167770689,\"y\":12.14},{\"x\":1685168070683,\"y\":12.14},{\"x\":1685168370787,\"y\":11.68},{\"x\":1685168670739,\"y\":11.68},{\"x\":1685168970743,\"y\":11.98},{\"x\":1685169270696,\"y\":11.98},{\"x\":1685169570699,\"y\":11.98},{\"x\":1685169870784,\"y\":13.66},{\"x\":1685170170701,\"y\":13.66},{\"x\":1685170470695,\"y\":13.66},{\"x\":1685170770757,\"y\":13.66},{\"x\":1685171070684,\"y\":13.98},{\"x\":1685171370697,\"y\":13.98},{\"x\":1685171670698,\"y\":14.38},{\"x\":1685171971138,\"y\":14.38},{\"x\":1685172270759,\"y\":13.85},{\"x\":1685172570699,\"y\":13.85},{\"x\":1685172870711,\"y\":13.85},{\"x\":1685173170778,\"y\":15.4},{\"x\":1685173470740,\"y\":15.5},{\"x\":1685173770702,\"y\":15.18},{\"x\":1685174070719,\"y\":15.49},{\"x\":1685174371094,\"y\":15.8},{\"x\":1685174670695,\"y\":15.49},{\"x\":1685174970800,\"y\":16.03},{\"x\":1685175270722,\"y\":15.86},{\"x\":1685175570763,\"y\":15.86},{\"x\":1685175870697,\"y\":16.35},{\"x\":1685176170707,\"y\":16.48},{\"x\":1685176470754,\"y\":16.94},{\"x\":1685176770748,\"y\":16.94},{\"x\":1685177070739,\"y\":17.05},{\"x\":1685177370721,\"y\":17.05},{\"x\":1685177670735,\"y\":17.05},{\"x\":1685177971115,\"y\":17.66},{\"x\":1685178270740,\"y\":17.66},{\"x\":1685178570747,\"y\":17.64},{\"x\":1685178870774,\"y\":18.01},{\"x\":1685179171072,\"y\":17.92},{\"x\":1685179470822,\"y\":18.19},{\"x\":1685179770758,\"y\":18.1},{\"x\":1685180070762,\"y\":18.19},{\"x\":1685180370805,\"y\":18.1},{\"x\":1685180670780,\"y\":18.51},{\"x\":1685180970809,\"y\":18.65},{\"x\":1685181270793,\"y\":18.72},{\"x\":1685181570900,\"y\":19.19},{\"x\":1685181870801,\"y\":19.1},{\"x\":1685182170811,\"y\":19.19},{\"x\":1685182470860,\"y\":19.44},{\"x\":1685182771048,\"y\":19.67},{\"x\":1685183070826,\"y\":19.44},{\"x\":1685183370877,\"y\":19.67},{\"x\":1685183670882,\"y\":19.85},{\"x\":1685183970939,\"y\":19.85},{\"x\":1685184270841,\"y\":19.85},{\"x\":1685184570853,\"y\":19.96},{\"x\":1685184870900,\"y\":20.18},{\"x\":1685185170967,\"y\":20.47},{\"x\":1685185470866,\"y\":20.18},{\"x\":1685185770871,\"y\":20.65},{\"x\":1685186070870,\"y\":20.65},{\"x\":1685186370892,\"y\":20.6},{\"x\":1685186670893,\"y\":20.57},{\"x\":1685186970904,\"y\":20.71},{\"x\":1685187270868,\"y\":20.71},{\"x\":1685187572989,\"y\":20.99},{\"x\":1685187870872,\"y\":20.99},{\"x\":1685188170877,\"y\":20.99},{\"x\":1685188470913,\"y\":21.13},{\"x\":1685188771470,\"y\":21.2},{\"x\":1685189070899,\"y\":21.12},{\"x\":1685189370894,\"y\":21.2},{\"x\":1685189670921,\"y\":21.41},{\"x\":1685189971610,\"y\":21.41},{\"x\":1685190270898,\"y\":21.41},{\"x\":1685190570940,\"y\":21.32},{\"x\":1685190870918,\"y\":21.32},{\"x\":1685191171751,\"y\":21.78},{\"x\":1685191470923,\"y\":21.68},{\"x\":1685191770922,\"y\":21.68},{\"x\":1685192070981,\"y\":22.17},{\"x\":1685192371026,\"y\":22.17},{\"x\":1685192670934,\"y\":22.17},{\"x\":1685192970954,\"y\":22.46},{\"x\":1685193270953,\"y\":22.46},{\"x\":1685193571076,\"y\":21.99},{\"x\":1685193870942,\"y\":21.91},{\"x\":1685194171071,\"y\":21.99},{\"x\":1685194470972,\"y\":21.91},{\"x\":1685194770981,\"y\":21.91},{\"x\":1685195070960,\"y\":23.06},{\"x\":1685195370975,\"y\":22.73},{\"x\":1685195670969,\"y\":23.06},{\"x\":1685195971032,\"y\":22.82},{\"x\":1685196270973,\"y\":22.82},{\"x\":1685196570982,\"y\":22.82},{\"x\":1685196870986,\"y\":21.82},{\"x\":1685197171084,\"y\":21.93},{\"x\":1685197470984,\"y\":22.31},{\"x\":1685197770988,\"y\":22.31},{\"x\":1685198070990,\"y\":22.31},{\"x\":1685198371020,\"y\":22.31},{\"x\":1685198671053,\"y\":22.37},{\"x\":1685198970993,\"y\":22.23},{\"x\":1685199271011,\"y\":22.37},{\"x\":1685199571046,\"y\":22.48},{\"x\":1685199871115,\"y\":21.98},{\"x\":1685200171006,\"y\":21.98},{\"x\":1685200471008,\"y\":21.98},{\"x\":1685200771192,\"y\":22.9},{\"x\":1685201071014,\"y\":22.9},{\"x\":1685201371067,\"y\":22.11},{\"x\":1685201671018,\"y\":22.11},{\"x\":1685201971372,\"y\":22.11},{\"x\":1685202271010,\"y\":21.91},{\"x\":1685202571020,\"y\":21.91},{\"x\":1685202871094,\"y\":22.37},{\"x\":1685203171957,\"y\":22.04},{\"x\":1685203471024,\"y\":21.92},{\"x\":1685203771087,\"y\":22.72},{\"x\":1685204071079,\"y\":22.72},{\"x\":1685204372043,\"y\":22.63},{\"x\":1685204671023,\"y\":22.63},{\"x\":1685204971067,\"y\":22.65},{\"x\":1685205271028,\"y\":22.65},{\"x\":1685205571490,\"y\":22.29},{\"x\":1685205871024,\"y\":21.93},{\"x\":1685206171037,\"y\":21.93},{\"x\":1685206471023,\"y\":21.53},{\"x\":1685206771057,\"y\":21.53},{\"x\":1685207071049,\"y\":20.84},{\"x\":1685207371039,\"y\":20.84},{\"x\":1685207671107,\"y\":20.92},{\"x\":1685207971068,\"y\":20.84},{\"x\":1685208271098,\"y\":22.62},{\"x\":1685208571110,\"y\":22.62},{\"x\":1685208871086,\"y\":22.62},{\"x\":1685209171774,\"y\":20.91},{\"x\":1685209471092,\"y\":20.82},{\"x\":1685209771092,\"y\":19.71},{\"x\":1685210071129,\"y\":19.73},{\"x\":1685210371211,\"y\":19.73},{\"x\":1685210671121,\"y\":19.24},{\"x\":1685210971142,\"y\":21.59},{\"x\":1685211271109,\"y\":21.59},{\"x\":1685211573673,\"y\":21.59},{\"x\":1685211871103,\"y\":21.59},{\"x\":1685212171150,\"y\":21.56},{\"x\":1685212471136,\"y\":21.47},{\"x\":1685212771652,\"y\":20.46},{\"x\":1685213071195,\"y\":20.46},{\"x\":1685213371188,\"y\":19.23},{\"x\":1685213671169,\"y\":19.15},{\"x\":1685213971280,\"y\":19.23},{\"x\":1685214271228,\"y\":19.41},{\"x\":1685214571150,\"y\":19.41},{\"x\":1685214871151,\"y\":19.24},{\"x\":1685215171157,\"y\":19.21},{\"x\":1685215471219,\"y\":19.21},{\"x\":1685215771223,\"y\":18.87},{\"x\":1685216071239,\"y\":18.72},{\"x\":1685216371187,\"y\":18.87},{\"x\":1685216671220,\"y\":16.48},{\"x\":1685216971167,\"y\":16.48},{\"x\":1685217271190,\"y\":16.48},{\"x\":1685217571385,\"y\":16.48},{\"x\":1685217871202,\"y\":16.48},{\"x\":1685218171176,\"y\":16.48},{\"x\":1685218471193,\"y\":17.13},{\"x\":1685218772083,\"y\":17.04},{\"x\":1685219071242,\"y\":16.94},{\"x\":1685219371182,\"y\":16.94},{\"x\":1685219671182,\"y\":16.94},{\"x\":1685219971327,\"y\":17.29},{\"x\":1685220271195,\"y\":17.28},{\"x\":1685220571204,\"y\":17.28},{\"x\":1685220871265,\"y\":16.43},{\"x\":1685221171213,\"y\":16.43},{\"x\":1685221471206,\"y\":16.43},{\"x\":1685221771244,\"y\":16.32},{\"x\":1685222071214,\"y\":16.32},{\"x\":1685222371240,\"y\":16.22},{\"x\":1685222671231,\"y\":15.63},{\"x\":1685222971227,\"y\":15.63},{\"x\":1685223271215,\"y\":15.63},{\"x\":1685223571642,\"y\":15.63},{\"x\":1685223871216,\"y\":14.69},{\"x\":1685224171238,\"y\":14.69},{\"x\":1685224471255,\"y\":15.05},{\"x\":1685224771718,\"y\":15.05},{\"x\":1685225071254,\"y\":15},{\"x\":1685225371225,\"y\":14.91},{\"x\":1685225671230,\"y\":14.91},{\"x\":1685225971278,\"y\":15.03},{\"x\":1685226271229,\"y\":14.76},{\"x\":1685226571268,\"y\":14.62},{\"x\":1685226871228,\"y\":14.62},{\"x\":1685227171310,\"y\":14.58},{\"x\":1685227471236,\"y\":14.47},{\"x\":1685227771233,\"y\":14.47},{\"x\":1685228071264,\"y\":14.56},{\"x\":1685228371438,\"y\":14.56},{\"x\":1685228671307,\"y\":14.37},{\"x\":1685228971287,\"y\":14.26},{\"x\":1685229271247,\"y\":14.17},{\"x\":1685229571283,\"y\":14.26},{\"x\":1685229871252,\"y\":14.08},{\"x\":1685230171240,\"y\":14.08},{\"x\":1685230471249,\"y\":13.81},{\"x\":1685230771547,\"y\":13.9},{\"x\":1685231071282,\"y\":13.88},{\"x\":1685231371247,\"y\":13.88},{\"x\":1685231671245,\"y\":13.57},{\"x\":1685231971299,\"y\":13.8},{\"x\":1685232271267,\"y\":13.8},{\"x\":1685232571258,\"y\":13.67},{\"x\":1685232871256,\"y\":13.67},{\"x\":1685233172128,\"y\":13.34},{\"x\":1685233471266,\"y\":13.26},{\"x\":1685233771304,\"y\":13.55},{\"x\":1685234071280,\"y\":13.5},{\"x\":1685234371267,\"y\":13.55},{\"x\":1685234671308,\"y\":13.47},{\"x\":1685234971294,\"y\":13.47},{\"x\":1685235271259,\"y\":13.47},{\"x\":1685235573201,\"y\":13.47},{\"x\":1685235871295,\"y\":13.51},{\"x\":1685236171262,\"y\":13.65},{\"x\":1685236471308,\"y\":13.36},{\"x\":1685236772640,\"y\":13.36},{\"x\":1685237071263,\"y\":13.55},{\"x\":1685237371273,\"y\":13.46},{\"x\":1685237671265,\"y\":13.46},{\"x\":1685237972838,\"y\":13.08},{\"x\":1685238271265,\"y\":13.08},{\"x\":1685238571268,\"y\":13.08},{\"x\":1685238871275,\"y\":13.28},{\"x\":1685239172611,\"y\":13.41},{\"x\":1685239471288,\"y\":13.33},{\"x\":1685239771274,\"y\":13.31},{\"x\":1685240071325,\"y\":13.15},{\"x\":1685240372227,\"y\":13.07},{\"x\":1685240671318,\"y\":13.07},{\"x\":1685240971329,\"y\":13.07},{\"x\":1685241271288,\"y\":13.07},{\"x\":1685241571466,\"y\":13.07},{\"x\":1685241871279,\"y\":12.98},{\"x\":1685242171369,\"y\":13.28},{\"x\":1685242471346,\"y\":13.28},{\"x\":1685242771307,\"y\":13.28},{\"x\":1685243071278,\"y\":13.28},{\"x\":1685243371329,\"y\":13.28},{\"x\":1685243671340,\"y\":13.34},{\"x\":1685243971443,\"y\":13.34},{\"x\":1685244271334,\"y\":13.34},{\"x\":1685244571292,\"y\":13.34},{\"x\":1685244871333,\"y\":13.47},{\"x\":1685245171537,\"y\":13.69},{\"x\":1685245471361,\"y\":13.69},{\"x\":1685245771298,\"y\":13.69},{\"x\":1685246071304,\"y\":13.6},{\"x\":1685246371537,\"y\":13.65},{\"x\":1685246671321,\"y\":13.56},{\"x\":1685246971335,\"y\":13.65},{\"x\":1685247271382,\"y\":13.48},{\"x\":1685247571470,\"y\":13.48},{\"x\":1685247871384,\"y\":13.28},{\"x\":1685248171411,\"y\":13.28},{\"x\":1685248471353,\"y\":13.24},{\"x\":1685248771403,\"y\":13.24},{\"x\":1685249071402,\"y\":13.23},{\"x\":1685249371376,\"y\":13.23},{\"x\":1685249671393,\"y\":13.23},{\"x\":1685249971493,\"y\":13.17},{\"x\":1685250271426,\"y\":13.08},{\"x\":1685250571467,\"y\":13.11},{\"x\":1685250871415,\"y\":13.14},{\"x\":1685251171439,\"y\":13.14},{\"x\":1685251471413,\"y\":13.14},{\"x\":1685251771409,\"y\":13.14},{\"x\":1685252071420,\"y\":13.19},{\"x\":1685252371615,\"y\":13.25},{\"x\":1685252671425,\"y\":13.17},{\"x\":1685252971434,\"y\":13.18},{\"x\":1685253271482,\"y\":13.38},{\"x\":1685253571596,\"y\":13.3},{\"x\":1685253871453,\"y\":13.38},{\"x\":1685254171462,\"y\":13.45},{\"x\":1685254471470,\"y\":13.51},{\"x\":1685254771721,\"y\":13.58},{\"x\":1685255071473,\"y\":13.58},{\"x\":1685255371478,\"y\":13.58},{\"x\":1685255671578,\"y\":13.78},{\"x\":1685255971776,\"y\":13.54},{\"x\":1685256271512,\"y\":13.78},{\"x\":1685256571498,\"y\":13.76},{\"x\":1685256871502,\"y\":13.87},{\"x\":1685257171620,\"y\":13.87},{\"x\":1685257471509,\"y\":14.11},{\"x\":1685257771511,\"y\":14.36},{\"x\":1685258071508,\"y\":14.36},{\"x\":1685258371764,\"y\":14.39},{\"x\":1685258671517,\"y\":14.56},{\"x\":1685258971516,\"y\":14.56},{\"x\":1685259271515,\"y\":14.92},{\"x\":1685259571742,\"y\":14.92},{\"x\":1685259871562,\"y\":15.01},{\"x\":1685260171531,\"y\":15.01},{\"x\":1685260471534,\"y\":15.01},{\"x\":1685260771696,\"y\":14.85},{\"x\":1685261071539,\"y\":15.04},{\"x\":1685261371589,\"y\":15.04},{\"x\":1685261671538,\"y\":15.4},{\"x\":1685261971867,\"y\":15.59},{\"x\":1685262271550,\"y\":15.59},{\"x\":1685262571548,\"y\":15.59},{\"x\":1685262871567,\"y\":15.46},{\"x\":1685263171794,\"y\":15.73},{\"x\":1685263471562,\"y\":15.69},{\"x\":1685263771602,\"y\":15.85},{\"x\":1685264071565,\"y\":15.71},{\"x\":1685264371846,\"y\":15.71},{\"x\":1685264671596,\"y\":15.72},{\"x\":1685264971615,\"y\":15.73},{\"x\":1685265271570,\"y\":15.73},{\"x\":1685265571596,\"y\":15.65},{\"x\":1685265871585,\"y\":15.47},{\"x\":1685266171591,\"y\":15.47},{\"x\":1685266471584,\"y\":15.48},{\"x\":1685266771720,\"y\":15.72},{\"x\":1685267071581,\"y\":15.72},{\"x\":1685267371587,\"y\":15.9},{\"x\":1685267671638,\"y\":16.17},{\"x\":1685267971896,\"y\":16.17},{\"x\":1685268271589,\"y\":15.98},{\"x\":1685268571603,\"y\":16.37},{\"x\":1685268871604,\"y\":16.37},{\"x\":1685269171897,\"y\":16.65},{\"x\":1685269471607,\"y\":16.58},{\"x\":1685269771613,\"y\":16.58},{\"x\":1685270071662,\"y\":16.41},{\"x\":1685270371882,\"y\":16.41},{\"x\":1685270671617,\"y\":16.41},{\"x\":1685270971621,\"y\":16.28},{\"x\":1685271271686,\"y\":16.19},{\"x\":1685271571713,\"y\":16.22},{\"x\":1685271871621,\"y\":16.15},{\"x\":1685272171630,\"y\":16.22},{\"x\":1685272471630,\"y\":15.92},{\"x\":1685272771817,\"y\":15.96},{\"x\":1685273071635,\"y\":15.96},{\"x\":1685273371650,\"y\":16.12},{\"x\":1685273671673,\"y\":15.95},{\"x\":1685273971701,\"y\":16.31},{\"x\":1685274271656,\"y\":16.31},{\"x\":1685274571692,\"y\":16.32},{\"x\":1685274871686,\"y\":16.32},{\"x\":1685275171921,\"y\":16.73},{\"x\":1685275471665,\"y\":16.65},{\"x\":1685275771698,\"y\":16.73},{\"x\":1685276071659,\"y\":16.22},{\"x\":1685276371756,\"y\":16.22},{\"x\":1685276671662,\"y\":16.48},{\"x\":1685276971675,\"y\":15.89},{\"x\":1685277271661,\"y\":15.89},{\"x\":1685277571970,\"y\":15.63},{\"x\":1685277871714,\"y\":15.68},{\"x\":1685278171675,\"y\":15.63},{\"x\":1685278471667,\"y\":15.56},{\"x\":1685278771920,\"y\":15.65},{\"x\":1685279071689,\"y\":15.87},{\"x\":1685279371671,\"y\":15.87},{\"x\":1685279671675,\"y\":15.87},{\"x\":1685279972052,\"y\":15.71},{\"x\":1685280271668,\"y\":15.71},{\"x\":1685280571670,\"y\":16.04},{\"x\":1685280871676,\"y\":16.04},{\"x\":1685281671888,\"y\":15.97},{\"x\":1685284096032,\"y\":15.5},{\"x\":1685284395921,\"y\":15.5},{\"x\":1685284695933,\"y\":15.5},{\"x\":1685284995930,\"y\":15.47},{\"x\":1685285295935,\"y\":15.47},{\"x\":1685285595944,\"y\":15.8},{\"x\":1685285895939,\"y\":15.8},{\"x\":1685286195949,\"y\":15.51},{\"x\":1685286495951,\"y\":15.51},{\"x\":1685286796009,\"y\":15.36},{\"x\":1685287095965,\"y\":15.27},{\"x\":1685287395953,\"y\":15.27},{\"x\":1685287695970,\"y\":15.36},{\"x\":1685287995955,\"y\":15.36},{\"x\":1685288295961,\"y\":15.34},{\"x\":1685288595996,\"y\":14.97},{\"x\":1685288895968,\"y\":14.97},{\"x\":1685289196133,\"y\":14.79},{\"x\":1685289495999,\"y\":14.79},{\"x\":1685289795972,\"y\":14.69},{\"x\":1685290095973,\"y\":14.69},{\"x\":1685290395973,\"y\":14.69},{\"x\":1685290695981,\"y\":14.79},{\"x\":1685290996003,\"y\":14.79},{\"x\":1685291295989,\"y\":14.79},{\"x\":1685291595985,\"y\":14.77},{\"x\":1685291896008,\"y\":14.5},{\"x\":1685292196008,\"y\":14.5},{\"x\":1685292496041,\"y\":14.55},{\"x\":1685292796005,\"y\":14.47},{\"x\":1685293096013,\"y\":14.55},{\"x\":1685293396082,\"y\":14.49},{\"x\":1685293696011,\"y\":14.45},{\"x\":1685293996026,\"y\":14.65},{\"x\":1685294296016,\"y\":14.65},{\"x\":1685294596031,\"y\":14.43},{\"x\":1685294896026,\"y\":14.43},{\"x\":1685295196031,\"y\":14.42},{\"x\":1685295496032,\"y\":14.4},{\"x\":1685295796073,\"y\":14.53},{\"x\":1685296096031,\"y\":14.53},{\"x\":1685296396105,\"y\":14.32},{\"x\":1685296696030,\"y\":14.24},{\"x\":1685296996047,\"y\":14.24},{\"x\":1685297296080,\"y\":14.48},{\"x\":1685297596038,\"y\":14.4},{\"x\":1685297896041,\"y\":14.48},{\"x\":1685298196059,\"y\":14.08},{\"x\":1685298496041,\"y\":14.08},{\"x\":1685298796049,\"y\":14.33},{\"x\":1685299096058,\"y\":14},{\"x\":1685299396061,\"y\":13.59},{\"x\":1685299696048,\"y\":13.56},{\"x\":1685299996049,\"y\":13.56},{\"x\":1685300296111,\"y\":13.8},{\"x\":1685300596061,\"y\":13.71},{\"x\":1685300896068,\"y\":13.71},{\"x\":1685301196056,\"y\":13.49},{\"x\":1685301496064,\"y\":13.49},{\"x\":1685301796076,\"y\":13.49},{\"x\":1685302096103,\"y\":13.4},{\"x\":1685302396063,\"y\":13.46},{\"x\":1685302696077,\"y\":13.34},{\"x\":1685302996145,\"y\":13.04},{\"x\":1685303296067,\"y\":12.95},{\"x\":1685303596073,\"y\":13.04},{\"x\":1685303896072,\"y\":12.69},{\"x\":1685304196079,\"y\":12.67},{\"x\":1685304496103,\"y\":12.49},{\"x\":1685304796082,\"y\":12.49},{\"x\":1685305096071,\"y\":12.49},{\"x\":1685305396094,\"y\":12.49},{\"x\":1685305696124,\"y\":12.2},{\"x\":1685305996075,\"y\":12.14},{\"x\":1685306296121,\"y\":11.8},{\"x\":1685306596072,\"y\":11.8},{\"x\":1685306896081,\"y\":11.8},{\"x\":1685307196124,\"y\":11.34},{\"x\":1685307496091,\"y\":11.34},{\"x\":1685307797175,\"y\":11.28},{\"x\":1685308096131,\"y\":11.3},{\"x\":1685308396095,\"y\":11.28},{\"x\":1685308696095,\"y\":11.3},{\"x\":1685308996098,\"y\":11.22},{\"x\":1685309296119,\"y\":11},{\"x\":1685309596104,\"y\":11},{\"x\":1685309896135,\"y\":10.5},{\"x\":1685310196123,\"y\":10.5},{\"x\":1685310496134,\"y\":10.5},{\"x\":1685310796104,\"y\":10.45},{\"x\":1685311096115,\"y\":10.45},{\"x\":1685311396137,\"y\":10.24},{\"x\":1685311696121,\"y\":10.24},{\"x\":1685311996202,\"y\":10.21},{\"x\":1685312296125,\"y\":10.21},{\"x\":1685312596146,\"y\":10.21},{\"x\":1685312896148,\"y\":9.93},{\"x\":1685313196132,\"y\":10.07},{\"x\":1685313496203,\"y\":9.89},{\"x\":1685313796150,\"y\":9.83},{\"x\":1685314096147,\"y\":9.75},{\"x\":1685314396195,\"y\":9.81},{\"x\":1685314696202,\"y\":9.81},{\"x\":1685314996169,\"y\":9.68},{\"x\":1685315296183,\"y\":9.65},{\"x\":1685315596155,\"y\":9.37},{\"x\":1685315896207,\"y\":9.43},{\"x\":1685316196167,\"y\":9.43},{\"x\":1685316496181,\"y\":9.32},{\"x\":1685316796216,\"y\":9.22},{\"x\":1685317096164,\"y\":9.22},{\"x\":1685317396213,\"y\":8.84},{\"x\":1685317696170,\"y\":8.76},{\"x\":1685317996185,\"y\":8.81},{\"x\":1685318296172,\"y\":8.72},{\"x\":1685318596191,\"y\":8.81},{\"x\":1685318896205,\"y\":8.99},{\"x\":1685319196165,\"y\":8.99},{\"x\":1685319496187,\"y\":8.9},{\"x\":1685319796169,\"y\":8.9},{\"x\":1685320096204,\"y\":8.99},{\"x\":1685320396170,\"y\":8.7},{\"x\":1685320696174,\"y\":8.65},{\"x\":1685320996175,\"y\":8.65},{\"x\":1685321296205,\"y\":8.41},{\"x\":1685321596177,\"y\":8.41},{\"x\":1685321896203,\"y\":8.41},{\"x\":1685322196246,\"y\":8.09},{\"x\":1685322496225,\"y\":7.88},{\"x\":1685322796181,\"y\":7.88},{\"x\":1685323096176,\"y\":7.73},{\"x\":1685323396175,\"y\":7.73},{\"x\":1685323696184,\"y\":7.67},{\"x\":1685323996186,\"y\":7.67},{\"x\":1685324296221,\"y\":7.83},{\"x\":1685324596190,\"y\":7.74},{\"x\":1685324896222,\"y\":7.83},{\"x\":1685325196203,\"y\":7.74},{\"x\":1685325496188,\"y\":7.32},{\"x\":1685325796536,\"y\":7.32},{\"x\":1685326096185,\"y\":7.32},{\"x\":1685326396231,\"y\":7.41},{\"x\":1685326696191,\"y\":7.41},{\"x\":1685326996194,\"y\":7.41},{\"x\":1685327296195,\"y\":7.29},{\"x\":1685327596190,\"y\":7.3},{\"x\":1685327896227,\"y\":7.33},{\"x\":1685328196279,\"y\":7.33},{\"x\":1685328496276,\"y\":7.33},{\"x\":1685328796240,\"y\":7.2},{\"x\":1685329096191,\"y\":7.2},{\"x\":1685329396192,\"y\":7.11},{\"x\":1685329696248,\"y\":7.2},{\"x\":1685329996247,\"y\":7.2},{\"x\":1685330296206,\"y\":7.2},{\"x\":1685330596222,\"y\":7.11},{\"x\":1685330896241,\"y\":7.37},{\"x\":1685331196223,\"y\":7.37},{\"x\":1685331496227,\"y\":7.37},{\"x\":1685331796287,\"y\":7.54},{\"x\":1685332096241,\"y\":7.54},{\"x\":1685332396262,\"y\":7.25},{\"x\":1685332696288,\"y\":7.34},{\"x\":1685332996282,\"y\":7.25},{\"x\":1685333296250,\"y\":7.34},{\"x\":1685333596314,\"y\":7.3},{\"x\":1685333896248,\"y\":7.3},{\"x\":1685334196250,\"y\":7.22},{\"x\":1685334496287,\"y\":7.3},{\"x\":1685334796262,\"y\":7.3},{\"x\":1685335096310,\"y\":7.34},{\"x\":1685335396322,\"y\":7.34},{\"x\":1685335696328,\"y\":7.35},{\"x\":1685335996277,\"y\":7.35},{\"x\":1685336296341,\"y\":7.46},{\"x\":1685336596305,\"y\":7.46},{\"x\":1685336896288,\"y\":7.46},{\"x\":1685337196337,\"y\":7.77},{\"x\":1685337496307,\"y\":7.68},{\"x\":1685337796344,\"y\":7.77},{\"x\":1685338096310,\"y\":7.7},{\"x\":1685338396309,\"y\":7.7},{\"x\":1685338696313,\"y\":7.87},{\"x\":1685338996338,\"y\":7.91},{\"x\":1685339296305,\"y\":8.24},{\"x\":1685339596306,\"y\":8.24},{\"x\":1685339896363,\"y\":8.87},{\"x\":1685340196325,\"y\":8.81},{\"x\":1685340496328,\"y\":8.87},{\"x\":1685340796324,\"y\":8.93},{\"x\":1685341096323,\"y\":8.93},{\"x\":1685341396403,\"y\":9.54},{\"x\":1685341696331,\"y\":9.46},{\"x\":1685341996329,\"y\":9.48},{\"x\":1685342296334,\"y\":9.53},{\"x\":1685342596385,\"y\":9.94},{\"x\":1685342896330,\"y\":9.94},{\"x\":1685343196338,\"y\":10.15},{\"x\":1685343496342,\"y\":10.74},{\"x\":1685343796354,\"y\":10.74},{\"x\":1685344096339,\"y\":11.17},{\"x\":1685344396346,\"y\":11.17},{\"x\":1685344697407,\"y\":11.29},{\"x\":1685344996353,\"y\":11.26},{\"x\":1685345296424,\"y\":11.74},{\"x\":1685345596406,\"y\":11.65},{\"x\":1685345896351,\"y\":11.65},{\"x\":1685346196416,\"y\":12.07},{\"x\":1685346496410,\"y\":12.16},{\"x\":1685346796378,\"y\":12.07},{\"x\":1685347096406,\"y\":12.03},{\"x\":1685347396359,\"y\":12.03},{\"x\":1685347696378,\"y\":12.03},{\"x\":1685347996394,\"y\":12.1},{\"x\":1685348296366,\"y\":12.1},{\"x\":1685348596360,\"y\":12.02},{\"x\":1685348896369,\"y\":12.44},{\"x\":1685349196480,\"y\":12.49},{\"x\":1685349496365,\"y\":12.49},{\"x\":1685349796376,\"y\":12.49},{\"x\":1685350096394,\"y\":12.97},{\"x\":1685350396369,\"y\":12.97},{\"x\":1685350696451,\"y\":13.05},{\"x\":1685350996421,\"y\":13.19},{\"x\":1685351296370,\"y\":13.05},{\"x\":1685351596436,\"y\":13.25},{\"x\":1685351896375,\"y\":13.25},{\"x\":1685352196381,\"y\":13.25},{\"x\":1685352496379,\"y\":13.28},{\"x\":1685352796390,\"y\":13.28},{\"x\":1685353096503,\"y\":13.97},{\"x\":1685353396412,\"y\":13.97},{\"x\":1685353696392,\"y\":13.97},{\"x\":1685353996429,\"y\":14.15},{\"x\":1685354296437,\"y\":14.15},{\"x\":1685354596450,\"y\":14.15},{\"x\":1685354896393,\"y\":14.3},{\"x\":1685355196401,\"y\":14.3},{\"x\":1685355496440,\"y\":14.36},{\"x\":1685355796402,\"y\":14.36},{\"x\":1685356096449,\"y\":14.32},{\"x\":1685356396391,\"y\":14.24},{\"x\":1685356696401,\"y\":14.32},{\"x\":1685356996401,\"y\":14.61},{\"x\":1685357296408,\"y\":14.61},{\"x\":1685357596403,\"y\":15.01},{\"x\":1685357896429,\"y\":15.59},{\"x\":1685358196393,\"y\":15.59},{\"x\":1685358496468,\"y\":15.59},{\"x\":1685358796424,\"y\":16},{\"x\":1685359096400,\"y\":16},{\"x\":1685359396448,\"y\":16.11},{\"x\":1685359696410,\"y\":16.08},{\"x\":1685359996404,\"y\":16.08},{\"x\":1685360296411,\"y\":16.35},{\"x\":1685360596442,\"y\":16.35},{\"x\":1685360896460,\"y\":16.44},{\"x\":1685361196442,\"y\":16.44},{\"x\":1685361496409,\"y\":16.44},{\"x\":1685361796427,\"y\":16.52},{\"x\":1685362096416,\"y\":16.62},{\"x\":1685362396413,\"y\":16.67},{\"x\":1685362696411,\"y\":16.68},{\"x\":1685362996461,\"y\":16.79},{\"x\":1685363296411,\"y\":16.85},{\"x\":1685363596420,\"y\":16.79},{\"x\":1685363896467,\"y\":16.76},{\"x\":1685364196435,\"y\":16.76},{\"x\":1685364496434,\"y\":16.76},{\"x\":1685364796430,\"y\":16.68},{\"x\":1685365096423,\"y\":17.1},{\"x\":1685365396432,\"y\":17.1},{\"x\":1685365696497,\"y\":17.46},{\"x\":1685365996459,\"y\":17.44},{\"x\":1685366296423,\"y\":17.46},{\"x\":1685366596445,\"y\":17.44},{\"x\":1685366896437,\"y\":17.38},{\"x\":1685367196433,\"y\":17.38},{\"x\":1685367496432,\"y\":17.38},{\"x\":1685367796435,\"y\":17.27},{\"x\":1685368096426,\"y\":17.27},{\"x\":1685368396429,\"y\":17.26},{\"x\":1685368696436,\"y\":17.26},{\"x\":1685368996438,\"y\":17.44},{\"x\":1685369296428,\"y\":17.32},{\"x\":1685369596501,\"y\":17.5},{\"x\":1685369896441,\"y\":17.42},{\"x\":1685370196509,\"y\":17.5},{\"x\":1685370496485,\"y\":17.7},{\"x\":1685370796502,\"y\":17.7},{\"x\":1685371096455,\"y\":17.7},{\"x\":1685371396510,\"y\":17.39},{\"x\":1685371696485,\"y\":17.39},{\"x\":1685371996502,\"y\":17.64},{\"x\":1685372296476,\"y\":17.31},{\"x\":1685372596474,\"y\":17.78},{\"x\":1685372896482,\"y\":17.78},{\"x\":1685373196484,\"y\":17.78},{\"x\":1685373496572,\"y\":17.86},{\"x\":1685373796514,\"y\":17.78},{\"x\":1685374096510,\"y\":17.81},{\"x\":1685374396544,\"y\":17.86},{\"x\":1685374696519,\"y\":17.78},{\"x\":1685374996566,\"y\":17.78},{\"x\":1685375296542,\"y\":17.89},{\"x\":1685375596519,\"y\":17.89},{\"x\":1685375896531,\"y\":17.89},{\"x\":1685376196570,\"y\":17.89},{\"x\":1685376496581,\"y\":18.04},{\"x\":1685376796589,\"y\":18.04},{\"x\":1685377096547,\"y\":17.74},{\"x\":1685377396613,\"y\":17.74},{\"x\":1685377696596,\"y\":17.6},{\"x\":1685377996542,\"y\":17.51},{\"x\":1685378296565,\"y\":17.51},{\"x\":1685378596624,\"y\":17.51},{\"x\":1685378896627,\"y\":17.42},{\"x\":1685379196643,\"y\":17.2},{\"x\":1685379496586,\"y\":17.42},{\"x\":1685379796637,\"y\":17.09},{\"x\":1685380096596,\"y\":17.09},{\"x\":1685380396635,\"y\":17.11},{\"x\":1685380696607,\"y\":17.04},{\"x\":1685380996713,\"y\":17.08},{\"x\":1685381296598,\"y\":16.99},{\"x\":1685381596615,\"y\":17.08},{\"x\":1685381896608,\"y\":17.03},{\"x\":1685382196647,\"y\":17.03},{\"x\":1685382496621,\"y\":16.09},{\"x\":1685382796622,\"y\":16.25},{\"x\":1685383096636,\"y\":16.25},{\"x\":1685383396656,\"y\":16.25},{\"x\":1685383696677,\"y\":16.1},{\"x\":1685383996640,\"y\":16.09},{\"x\":1685384296634,\"y\":16.09},{\"x\":1685384596702,\"y\":16.09},{\"x\":1685384896755,\"y\":15.72},{\"x\":1685385196657,\"y\":15.7},{\"x\":1685385496648,\"y\":15.72},{\"x\":1685385796721,\"y\":14.94},{\"x\":1685386096661,\"y\":14.89},{\"x\":1685386396764,\"y\":14.48},{\"x\":1685386696644,\"y\":14.48},{\"x\":1685386996711,\"y\":14.39},{\"x\":1685387296665,\"y\":14.47},{\"x\":1685387596687,\"y\":14.47},{\"x\":1685387896719,\"y\":14.45},{\"x\":1685388196746,\"y\":14.37},{\"x\":1685388496677,\"y\":14.36},{\"x\":1685388796728,\"y\":14.16},{\"x\":1685389096728,\"y\":14.95},{\"x\":1685389396772,\"y\":15.89},{\"x\":1685389696700,\"y\":15.8},{\"x\":1685389996694,\"y\":15.8},{\"x\":1685390296741,\"y\":13.52},{\"x\":1685390596769,\"y\":13.52},{\"x\":1685390896706,\"y\":13.52},{\"x\":1685391196708,\"y\":12.38},{\"x\":1685391496778,\"y\":12.52},{\"x\":1685391796848,\"y\":12.52},{\"x\":1685392096805,\"y\":12.37},{\"x\":1685392396723,\"y\":12.01},{\"x\":1685392696723,\"y\":12.01},{\"x\":1685392996799,\"y\":11.33},{\"x\":1685393296731,\"y\":11.58},{\"x\":1685393596725,\"y\":11.33},{\"x\":1685393896759,\"y\":11.64},{\"x\":1685394196778,\"y\":11.64},{\"x\":1685394496727,\"y\":11.63},{\"x\":1685394796838,\"y\":11},{\"x\":1685395096733,\"y\":10.92},{\"x\":1685395396756,\"y\":10.84},{\"x\":1685395696744,\"y\":10.81},{\"x\":1685395996738,\"y\":10.81},{\"x\":1685396296745,\"y\":10.81},{\"x\":1685396596863,\"y\":9.92},{\"x\":1685396896748,\"y\":9.92},{\"x\":1685397196744,\"y\":9.92},{\"x\":1685397496752,\"y\":9.84},{\"x\":1685397797031,\"y\":9.29},{\"x\":1685398096745,\"y\":9.59},{\"x\":1685398396778,\"y\":9.29},{\"x\":1685398696753,\"y\":9.67},{\"x\":1685398996882,\"y\":9.8},{\"x\":1685399296749,\"y\":9.67},{\"x\":1685399596872,\"y\":9.64},{\"x\":1685399896856,\"y\":9.29},{\"x\":1685400196853,\"y\":9.29},{\"x\":1685400496758,\"y\":9.29},{\"x\":1685400796806,\"y\":8.88},{\"x\":1685401096749,\"y\":8.88},{\"x\":1685401396853,\"y\":8.88},{\"x\":1685401696823,\"y\":8.87},{\"x\":1685401996749,\"y\":8.93},{\"x\":1685402296834,\"y\":8.83},{\"x\":1685402596862,\"y\":8.83},{\"x\":1685402896766,\"y\":8.83},{\"x\":1685403196764,\"y\":8.69},{\"x\":1685403496778,\"y\":8.79},{\"x\":1685403796902,\"y\":8.76},{\"x\":1685404096775,\"y\":8.76},{\"x\":1685404396829,\"y\":8.45},{\"x\":1685404696790,\"y\":8.45},{\"x\":1685404996816,\"y\":8.36},{\"x\":1685405296883,\"y\":8.71},{\"x\":1685405596870,\"y\":8.7},{\"x\":1685405896793,\"y\":8.63},{\"x\":1685406196983,\"y\":8.7},{\"x\":1685406496794,\"y\":8.47},{\"x\":1685406796799,\"y\":8.47},{\"x\":1685407096806,\"y\":8.41},{\"x\":1685407396889,\"y\":8.27},{\"x\":1685407696814,\"y\":8.19},{\"x\":1685407996818,\"y\":8.27},{\"x\":1685408296823,\"y\":8.19},{\"x\":1685408596913,\"y\":8.19},{\"x\":1685408896867,\"y\":7.82},{\"x\":1685409196827,\"y\":7.82},{\"x\":1685409496885,\"y\":7.78},{\"x\":1685409796923,\"y\":7.69},{\"x\":1685410096833,\"y\":7.69},{\"x\":1685410396863,\"y\":7.68},{\"x\":1685410696853,\"y\":7.69},{\"x\":1685410996931,\"y\":7.59},{\"x\":1685411296850,\"y\":7.59},{\"x\":1685411596860,\"y\":7.59},{\"x\":1685411896863,\"y\":7.34},{\"x\":1685412197065,\"y\":7.41},{\"x\":1685412496865,\"y\":7.34},{\"x\":1685412796871,\"y\":7.34},{\"x\":1685413096914,\"y\":7.41},{\"x\":1685413396986,\"y\":7.41},{\"x\":1685413696881,\"y\":7.41},{\"x\":1685413996886,\"y\":7.35},{\"x\":1685414296923,\"y\":7.82},{\"x\":1685414597013,\"y\":7.95},{\"x\":1685414896976,\"y\":7.95},{\"x\":1685415196895,\"y\":7.95},{\"x\":1685415496889,\"y\":7.95},{\"x\":1685415796967,\"y\":8.17},{\"x\":1685416096899,\"y\":8.17},{\"x\":1685416396952,\"y\":8.17},{\"x\":1685416696900,\"y\":8.09},{\"x\":1685416997056,\"y\":8.23},{\"x\":1685417296914,\"y\":8.21},{\"x\":1685417596918,\"y\":8.23},{\"x\":1685417896941,\"y\":8.11},{\"x\":1685418197072,\"y\":8.11},{\"x\":1685418496972,\"y\":7.78},{\"x\":1685418796976,\"y\":7.78},{\"x\":1685419096917,\"y\":7.78},{\"x\":1685419397122,\"y\":7.76},{\"x\":1685419696925,\"y\":7.7},{\"x\":1685419996981,\"y\":7.76},{\"x\":1685420296927,\"y\":7.98},{\"x\":1685420597159,\"y\":7.68},{\"x\":1685420896981,\"y\":8.25},{\"x\":1685421196938,\"y\":8.25},{\"x\":1685421496968,\"y\":9.25},{\"x\":1685421797058,\"y\":8.95},{\"x\":1685422096935,\"y\":8.95},{\"x\":1685422397004,\"y\":9.27},{\"x\":1685422696956,\"y\":9.27},{\"x\":1685422997188,\"y\":9.29},{\"x\":1685423296955,\"y\":9.29},{\"x\":1685423597001,\"y\":9.11},{\"x\":1685423896956,\"y\":9.02},{\"x\":1685424197012,\"y\":9.02},{\"x\":1685424497000,\"y\":9.11},{\"x\":1685424796971,\"y\":9.02},{\"x\":1685425096964,\"y\":10.04},{\"x\":1685425397109,\"y\":10.04},{\"x\":1685425696964,\"y\":10.02},{\"x\":1685425996974,\"y\":9.99},{\"x\":1685426296965,\"y\":10.2},{\"x\":1685426597100,\"y\":10.28},{\"x\":1685426896989,\"y\":10.33},{\"x\":1685427196988,\"y\":10.33},{\"x\":1685427497031,\"y\":10.45},{\"x\":1685427797156,\"y\":10.38},{\"x\":1685428097083,\"y\":10.94},{\"x\":1685428396991,\"y\":10.94},{\"x\":1685428696996,\"y\":10.82},{\"x\":1685428997105,\"y\":11.01},{\"x\":1685429296992,\"y\":11.01},{\"x\":1685429597030,\"y\":11.01},{\"x\":1685429896994,\"y\":11.04},{\"x\":1685430197076,\"y\":11.04},{\"x\":1685430497010,\"y\":11.39},{\"x\":1685430796999,\"y\":11.6},{\"x\":1685431097007,\"y\":11.55},{\"x\":1685431397249,\"y\":11.81},{\"x\":1685431697002,\"y\":11.81},{\"x\":1685431997013,\"y\":11.81},{\"x\":1685432297009,\"y\":11.82},{\"x\":1685432597030,\"y\":11.82},{\"x\":1685432897132,\"y\":12.15},{\"x\":1685433197016,\"y\":12.07},{\"x\":1685433497009,\"y\":12.15},{\"x\":1685433797139,\"y\":12.16},{\"x\":1685434097016,\"y\":12.19},{\"x\":1685434397064,\"y\":12.22},{\"x\":1685434697027,\"y\":12.14},{\"x\":1685434997238,\"y\":12.14},{\"x\":1685435297077,\"y\":12.32},{\"x\":1685435597014,\"y\":12.33},{\"x\":1685435897071,\"y\":12.41},{\"x\":1685436197195,\"y\":12.35},{\"x\":1685436497013,\"y\":12.35},{\"x\":1685436797015,\"y\":12.32},{\"x\":1685437097050,\"y\":12.32},{\"x\":1685437397237,\"y\":12.33},{\"x\":1685437697030,\"y\":12.33},{\"x\":1685437997069,\"y\":12.27},{\"x\":1685438297034,\"y\":12.19},{\"x\":1685438597203,\"y\":12.17},{\"x\":1685438897033,\"y\":12.34},{\"x\":1685439197064,\"y\":12.31},{\"x\":1685439497033,\"y\":12.32},{\"x\":1685439797107,\"y\":12.31},{\"x\":1685440097051,\"y\":13.11},{\"x\":1685440397038,\"y\":13.21},{\"x\":1685440697073,\"y\":13.37},{\"x\":1685440997179,\"y\":13.19},{\"x\":1685441297048,\"y\":13.28},{\"x\":1685441597041,\"y\":13.19},{\"x\":1685441897039,\"y\":13.29},{\"x\":1685442197094,\"y\":13.29},{\"x\":1685442497030,\"y\":13.33},{\"x\":1685442797045,\"y\":13.33},{\"x\":1685443097030,\"y\":13.2},{\"x\":1685443397349,\"y\":13.31},{\"x\":1685443697027,\"y\":13.31},{\"x\":1685443997092,\"y\":13.23},{\"x\":1685444297033,\"y\":13.77},{\"x\":1685444597073,\"y\":13.68},{\"x\":1685444897078,\"y\":16.19},{\"x\":1685445197034,\"y\":16.19},{\"x\":1685445497068,\"y\":16.19},{\"x\":1685445797209,\"y\":16.19},{\"x\":1685446097058,\"y\":16.19},{\"x\":1685446397051,\"y\":17.22},{\"x\":1685446697059,\"y\":17.22},{\"x\":1685446997166,\"y\":18.41},{\"x\":1685447297115,\"y\":18.41},{\"x\":1685447597112,\"y\":18.41},{\"x\":1685447897089,\"y\":18.41},{\"x\":1685448197159,\"y\":12.74},{\"x\":1685448497098,\"y\":12.72},{\"x\":1685448797127,\"y\":12.89},{\"x\":1685449097105,\"y\":12.97},{\"x\":1685449397373,\"y\":13.15},{\"x\":1685449697109,\"y\":13.03},{\"x\":1685449997136,\"y\":13.06},{\"x\":1685450297128,\"y\":13.06},{\"x\":1685450597387,\"y\":13.06},{\"x\":1685450897183,\"y\":13.21},{\"x\":1685451197144,\"y\":13.21},{\"x\":1685451497142,\"y\":13.33},{\"x\":1685451797185,\"y\":13.33},{\"x\":1685452097148,\"y\":13.57},{\"x\":1685452397249,\"y\":13.64},{\"x\":1685452697161,\"y\":13.64},{\"x\":1685452997474,\"y\":13.64},{\"x\":1685453297206,\"y\":13.97},{\"x\":1685453597173,\"y\":13.69},{\"x\":1685453897183,\"y\":13.94},{\"x\":1685454197215,\"y\":13.94},{\"x\":1685454497192,\"y\":14.16},{\"x\":1685454797260,\"y\":14.48},{\"x\":1685455097202,\"y\":14.67},{\"x\":1685455397476,\"y\":14.67},{\"x\":1685455697209,\"y\":14.86},{\"x\":1685455997240,\"y\":15.03},{\"x\":1685456297262,\"y\":15.18},{\"x\":1685456597249,\"y\":15.18},{\"x\":1685456897228,\"y\":15.09},{\"x\":1685457197269,\"y\":15.55},{\"x\":1685457497236,\"y\":15.55},{\"x\":1685457797465,\"y\":15.55},{\"x\":1685458097286,\"y\":16.03},{\"x\":1685458397242,\"y\":16.03},{\"x\":1685458697267,\"y\":16.03},{\"x\":1685458997286,\"y\":15.84},{\"x\":1685459297248,\"y\":15.84},{\"x\":1685459597268,\"y\":16.22},{\"x\":1685459897263,\"y\":16.22},{\"x\":1685460197357,\"y\":16.94},{\"x\":1685460497301,\"y\":16.94},{\"x\":1685460797266,\"y\":16.94},{\"x\":1685461097305,\"y\":16.95},{\"x\":1685461397544,\"y\":17.05},{\"x\":1685461697280,\"y\":16.95},{\"x\":1685461997291,\"y\":16.97},{\"x\":1685462297287,\"y\":16.97},{\"x\":1685462597465,\"y\":17.35},{\"x\":1685462897303,\"y\":17.35},{\"x\":1685463197366,\"y\":17.2},{\"x\":1685463737229,\"y\":17.2},{\"x\":1685464037277,\"y\":17.14},{\"x\":1685464337245,\"y\":17.14},{\"x\":1685464637256,\"y\":17.03},{\"x\":1685464937262,\"y\":17.14},{\"x\":1685465237316,\"y\":17.08},{\"x\":1685465537294,\"y\":17.08},{\"x\":1685465837334,\"y\":17.31},{\"x\":1685466137337,\"y\":17.31},{\"x\":1685466437310,\"y\":17.03},{\"x\":1685466737354,\"y\":17.04},{\"x\":1685467037407,\"y\":16.96},{\"x\":1685467337326,\"y\":17.16},{\"x\":1685467637328,\"y\":17.13},{\"x\":1685467937333,\"y\":16.81},{\"x\":1685468237339,\"y\":16.48},{\"x\":1685468537360,\"y\":16.48},{\"x\":1685468837368,\"y\":16.47},{\"x\":1685469137413,\"y\":15.9},{\"x\":1685469437370,\"y\":16.04},{\"x\":1685469737372,\"y\":15.9},{\"x\":1685470037427,\"y\":15.82},{\"x\":1685470337392,\"y\":15.82},{\"x\":1685470637406,\"y\":15.82},{\"x\":1685470937407,\"y\":15.69},{\"x\":1685471237416,\"y\":15.83},{\"x\":1685471537421,\"y\":15.83},{\"x\":1685471837423,\"y\":15.95},{\"x\":1685472137555,\"y\":15.16},{\"x\":1685472437434,\"y\":15.08},{\"x\":1685472737439,\"y\":14.87},{\"x\":1685473037727,\"y\":14.79},{\"x\":1685473337523,\"y\":15.1},{\"x\":1685473637452,\"y\":14.79},{\"x\":1685473937500,\"y\":14.51},{\"x\":1685474237504,\"y\":14.29},{\"x\":1685474537449,\"y\":14.29},{\"x\":1685474837471,\"y\":14.21},{\"x\":1685475137479,\"y\":14.06},{\"x\":1685475437511,\"y\":13.27},{\"x\":1685475737497,\"y\":13.27},{\"x\":1685476037496,\"y\":13.19},{\"x\":1685476337572,\"y\":13.61},{\"x\":1685476637511,\"y\":13.49},{\"x\":1685476937513,\"y\":13.47},{\"x\":1685477237528,\"y\":13.42},{\"x\":1685477537526,\"y\":13.44},{\"x\":1685477837530,\"y\":13.44},{\"x\":1685478137582,\"y\":13.03},{\"x\":1685478437532,\"y\":13.14},{\"x\":1685478737565,\"y\":12.83},{\"x\":1685479037545,\"y\":12.91},{\"x\":1685479337555,\"y\":12.59},{\"x\":1685479637566,\"y\":12.56},{\"x\":1685479937595,\"y\":12.5},{\"x\":1685480237565,\"y\":12.61},{\"x\":1685480537635,\"y\":12.43},{\"x\":1685480837564,\"y\":12.43},{\"x\":1685481137578,\"y\":12.27},{\"x\":1685481437654,\"y\":12.32},{\"x\":1685481737583,\"y\":12.24},{\"x\":1685482037634,\"y\":12.13},{\"x\":1685482337596,\"y\":12.13},{\"x\":1685482637588,\"y\":12.04},{\"x\":1685482937605,\"y\":11.88},{\"x\":1685483237606,\"y\":11.88},{\"x\":1685483537617,\"y\":11.87},{\"x\":1685483837694,\"y\":11.87},{\"x\":1685484137652,\"y\":11.83},{\"x\":1685484437620,\"y\":11.55},{\"x\":1685484737629,\"y\":11.83},{\"x\":1685485037682,\"y\":11.43},{\"x\":1685485337673,\"y\":11.43},{\"x\":1685485637637,\"y\":11.43},{\"x\":1685485937698,\"y\":11.4},{\"x\":1685486237666,\"y\":11.4},{\"x\":1685486537695,\"y\":11.4},{\"x\":1685486837701,\"y\":11.34},{\"x\":1685487137670,\"y\":11.34},{\"x\":1685487437690,\"y\":11.34},{\"x\":1685487737711,\"y\":11.08},{\"x\":1685488037671,\"y\":11.08},{\"x\":1685488337728,\"y\":11.08},{\"x\":1685488637752,\"y\":11.06},{\"x\":1685488937679,\"y\":11.06},{\"x\":1685489237735,\"y\":11.04},{\"x\":1685489537691,\"y\":10.96},{\"x\":1685489837848,\"y\":11.05},{\"x\":1685490137701,\"y\":11.05},{\"x\":1685490437705,\"y\":10.95},{\"x\":1685490737730,\"y\":10.86},{\"x\":1685491037756,\"y\":10.8},{\"x\":1685491337708,\"y\":10.8},{\"x\":1685491637705,\"y\":10.8},{\"x\":1685491937711,\"y\":10.71},{\"x\":1685492237764,\"y\":10.8},{\"x\":1685492537769,\"y\":10.8},{\"x\":1685492837718,\"y\":10.8},{\"x\":1685493137753,\"y\":10.8},{\"x\":1685493437930,\"y\":10.87},{\"x\":1685493737724,\"y\":10.87},{\"x\":1685494037777,\"y\":10.61},{\"x\":1685494337747,\"y\":10.52},{\"x\":1685494637852,\"y\":10.61},{\"x\":1685494937737,\"y\":10.61},{\"x\":1685495237777,\"y\":10.63},{\"x\":1685495537775,\"y\":10.62},{\"x\":1685495837812,\"y\":10.51},{\"x\":1685496137755,\"y\":10.43},{\"x\":1685496437796,\"y\":10.49},{\"x\":1685496737809,\"y\":10.49},{\"x\":1685497037761,\"y\":10.49},{\"x\":1685497337761,\"y\":10.23},{\"x\":1685497637765,\"y\":10.23},{\"x\":1685497937814,\"y\":10.31},{\"x\":1685498237807,\"y\":10.31},{\"x\":1685498537788,\"y\":10.31},{\"x\":1685498837775,\"y\":10.23},{\"x\":1685499137789,\"y\":10.23},{\"x\":1685499437805,\"y\":10.23},{\"x\":1685499737817,\"y\":10.31},{\"x\":1685500037780,\"y\":10.31},{\"x\":1685500337844,\"y\":10.14},{\"x\":1685500637891,\"y\":10.14},{\"x\":1685500937793,\"y\":10.14},{\"x\":1685501237793,\"y\":10.14},{\"x\":1685501537807,\"y\":10.05},{\"x\":1685501837925,\"y\":10.05},{\"x\":1685502137801,\"y\":10.05},{\"x\":1685502437811,\"y\":9.97},{\"x\":1685502737895,\"y\":10.14},{\"x\":1685503037900,\"y\":10.16},{\"x\":1685503337808,\"y\":10.16},{\"x\":1685503637807,\"y\":10.08},{\"x\":1685503937812,\"y\":9.94},{\"x\":1685504237850,\"y\":9.94},{\"x\":1685504537822,\"y\":9.99},{\"x\":1685504837872,\"y\":9.96},{\"x\":1685505137866,\"y\":9.98},{\"x\":1685505438032,\"y\":9.98},{\"x\":1685505737834,\"y\":9.98},{\"x\":1685506037879,\"y\":9.81},{\"x\":1685506337861,\"y\":9.81},{\"x\":1685506637914,\"y\":9.81},{\"x\":1685506937872,\"y\":9.81},{\"x\":1685507237889,\"y\":9.81},{\"x\":1685507537838,\"y\":9.81},{\"x\":1685507837888,\"y\":9.81},{\"x\":1685508137887,\"y\":9.82},{\"x\":1685508437832,\"y\":9.73},{\"x\":1685508737867,\"y\":9.82},{\"x\":1685509037974,\"y\":9.62},{\"x\":1685509337857,\"y\":9.82},{\"x\":1685509637848,\"y\":9.62},{\"x\":1685509937889,\"y\":9.62},{\"x\":1685510237947,\"y\":9.62},{\"x\":1685510537889,\"y\":9.65},{\"x\":1685510837852,\"y\":9.65},{\"x\":1685511137855,\"y\":9.65},{\"x\":1685511437965,\"y\":9.57},{\"x\":1685511737859,\"y\":9.57},{\"x\":1685512037848,\"y\":9.54},{\"x\":1685512337852,\"y\":9.55},{\"x\":1685512638025,\"y\":9.58},{\"x\":1685512937857,\"y\":9.57},{\"x\":1685513237850,\"y\":9.58},{\"x\":1685513537848,\"y\":9.57},{\"x\":1685513837893,\"y\":9.57},{\"x\":1685514137857,\"y\":9.75},{\"x\":1685514437855,\"y\":9.75},{\"x\":1685514737977,\"y\":9.84},{\"x\":1685515037889,\"y\":9.84},{\"x\":1685515337874,\"y\":9.84},{\"x\":1685515637865,\"y\":9.84},{\"x\":1685515937961,\"y\":9.84},{\"x\":1685516238059,\"y\":9.84},{\"x\":1685516537872,\"y\":9.75},{\"x\":1685516837969,\"y\":10.01},{\"x\":1685517137902,\"y\":10.01},{\"x\":1685517437997,\"y\":10.01},{\"x\":1685517737887,\"y\":10.03},{\"x\":1685518037974,\"y\":10.03},{\"x\":1685518337895,\"y\":9.92},{\"x\":1685518637932,\"y\":9.92},{\"x\":1685518937904,\"y\":9.96},{\"x\":1685519238002,\"y\":10.1},{\"x\":1685519537959,\"y\":10.1},{\"x\":1685519837988,\"y\":10.1},{\"x\":1685520137912,\"y\":10.1},{\"x\":1685520437906,\"y\":10.37},{\"x\":1685520737913,\"y\":10.33},{\"x\":1685521038006,\"y\":10.33},{\"x\":1685521337908,\"y\":10.33},{\"x\":1685521637915,\"y\":10.33},{\"x\":1685521937963,\"y\":10.25},{\"x\":1685522238080,\"y\":10.54},{\"x\":1685522537924,\"y\":10.54},{\"x\":1685522837919,\"y\":10.54},{\"x\":1685523137944,\"y\":10.5},{\"x\":1685523438045,\"y\":10.6},{\"x\":1685523737930,\"y\":10.58},{\"x\":1685524037929,\"y\":10.52},{\"x\":1685524337974,\"y\":10.82},{\"x\":1685524638007,\"y\":10.82},{\"x\":1685524937934,\"y\":10.82},{\"x\":1685525237935,\"y\":10.95},{\"x\":1685525537943,\"y\":10.99},{\"x\":1685525838078,\"y\":11.08},{\"x\":1685526137951,\"y\":11.08},{\"x\":1685526437950,\"y\":10.99},{\"x\":1685526737944,\"y\":11.07},{\"x\":1685527038721,\"y\":11.07},{\"x\":1685527338012,\"y\":11.11},{\"x\":1685527637961,\"y\":11.11},{\"x\":1685527937952,\"y\":11.07},{\"x\":1685528238080,\"y\":11.16},{\"x\":1685528537978,\"y\":11.03},{\"x\":1685528837960,\"y\":11.12},{\"x\":1685529137967,\"y\":11.08},{\"x\":1685529438131,\"y\":11.61},{\"x\":1685529738016,\"y\":11.61},{\"x\":1685530037967,\"y\":11.61},{\"x\":1685530337963,\"y\":11.61},{\"x\":1685530638067,\"y\":11.61},{\"x\":1685530937995,\"y\":11.61},{\"x\":1685531237967,\"y\":11.61},{\"x\":1685531537979,\"y\":12.07},{\"x\":1685531838029,\"y\":11.73},{\"x\":1685532137972,\"y\":11.72},{\"x\":1685532437974,\"y\":11.73},{\"x\":1685532738070,\"y\":11.43},{\"x\":1685533038022,\"y\":11.92},{\"x\":1685533338038,\"y\":16.07},{\"x\":1685533637982,\"y\":16.07},{\"x\":1685533938045,\"y\":16.07},{\"x\":1685534238057,\"y\":16.07},{\"x\":1685534537980,\"y\":16.07},{\"x\":1685534838036,\"y\":12.17},{\"x\":1685535137993,\"y\":12.17},{\"x\":1685535438136,\"y\":12.17},{\"x\":1685535737984,\"y\":12.17},{\"x\":1685536037986,\"y\":12.17},{\"x\":1685536337985,\"y\":12.17},{\"x\":1685536638024,\"y\":11.9},{\"x\":1685536938025,\"y\":15.91},{\"x\":1685537237999,\"y\":15.91},{\"x\":1685537538002,\"y\":15.91},{\"x\":1685537838106,\"y\":15.91},{\"x\":1685538138007,\"y\":15.82},{\"x\":1685538438058,\"y\":13.28},{\"x\":1685538738048,\"y\":13.28},{\"x\":1685539038104,\"y\":13.28},{\"x\":1685539338007,\"y\":13.2},{\"x\":1685539638019,\"y\":13.2},{\"x\":1685539938003,\"y\":13.33},{\"x\":1685540238052,\"y\":13.2},{\"x\":1685540538039,\"y\":16.75},{\"x\":1685540838017,\"y\":16.67},{\"x\":1685541138064,\"y\":16.75},{\"x\":1685541438054,\"y\":16.67},{\"x\":1685541738229,\"y\":17.3},{\"x\":1685542038012,\"y\":17.22},{\"x\":1685542338042,\"y\":17.3},{\"x\":1685542638126,\"y\":18.38},{\"x\":1685542938012,\"y\":18.38},{\"x\":1685543238056,\"y\":18.97},{\"x\":1685543538110,\"y\":17.86},{\"x\":1685543838052,\"y\":17.86},{\"x\":1685544138125,\"y\":17.78},{\"x\":1685544438027,\"y\":17.78},{\"x\":1685544738110,\"y\":14.96},{\"x\":1685545038075,\"y\":14.94},{\"x\":1685545338027,\"y\":14.94},{\"x\":1685545638075,\"y\":15.63},{\"x\":1685545938022,\"y\":15.63},{\"x\":1685546238174,\"y\":16},{\"x\":1685546538079,\"y\":15.83},{\"x\":1685546838020,\"y\":15.81},{\"x\":1685547138129,\"y\":14.9},{\"x\":1685547438095,\"y\":14.83},{\"x\":1685547738125,\"y\":14.9},{\"x\":1685548038046,\"y\":14.83},{\"x\":1685548338056,\"y\":14.9},{\"x\":1685548638087,\"y\":14.85},{\"x\":1685548938038,\"y\":14.85},{\"x\":1685549238040,\"y\":14.85},{\"x\":1685549538033,\"y\":14.97},{\"x\":1685549838168,\"y\":14.97},{\"x\":1685550138087,\"y\":15.03},{\"x\":1685550438030,\"y\":14.97},{\"x\":1685550738120,\"y\":14.3},{\"x\":1685551038139,\"y\":14.3},{\"x\":1685551338037,\"y\":13.6},{\"x\":1685551638033,\"y\":13.49},{\"x\":1685551938041,\"y\":13.47},{\"x\":1685552238174,\"y\":13.61},{\"x\":1685552538043,\"y\":13.61},{\"x\":1685552838043,\"y\":13.52},{\"x\":1685553138067,\"y\":13.52},{\"x\":1685553438546,\"y\":13.6},{\"x\":1685553738055,\"y\":13.52},{\"x\":1685554038140,\"y\":13.59},{\"x\":1685554338045,\"y\":13.51},{\"x\":1685554638134,\"y\":13.16},{\"x\":1685554938070,\"y\":13.16},{\"x\":1685555238057,\"y\":13.18},{\"x\":1685555538064,\"y\":13.07},{\"x\":1685555838093,\"y\":13.07},{\"x\":1685556138085,\"y\":13.14},{\"x\":1685556438188,\"y\":13.11},{\"x\":1685556738092,\"y\":13.12},{\"x\":1685557038192,\"y\":13.01},{\"x\":1685557338095,\"y\":13.01},{\"x\":1685557638182,\"y\":12.89},{\"x\":1685557938150,\"y\":12.8},{\"x\":1685558238172,\"y\":12.61},{\"x\":1685558538110,\"y\":12.8},{\"x\":1685558838201,\"y\":12.58},{\"x\":1685559138123,\"y\":12.58},{\"x\":1685559438206,\"y\":12.59},{\"x\":1685559738189,\"y\":12.57},{\"x\":1685560038129,\"y\":12.57},{\"x\":1685560338155,\"y\":12.57},{\"x\":1685560638404,\"y\":12.29},{\"x\":1685560938173,\"y\":12.29},{\"x\":1685561238169,\"y\":12.29},{\"x\":1685561538183,\"y\":12.17},{\"x\":1685561838237,\"y\":12.17},{\"x\":1685562138233,\"y\":12.21},{\"x\":1685562438249,\"y\":12.18},{\"x\":1685562738211,\"y\":12.18},{\"x\":1685563038228,\"y\":12.09},{\"x\":1685563338214,\"y\":12.07},{\"x\":1685563638217,\"y\":12.07},{\"x\":1685563938231,\"y\":11.8},{\"x\":1685564238362,\"y\":11.86},{\"x\":1685564538381,\"y\":11.83},{\"x\":1685564838277,\"y\":11.83},{\"x\":1685565138242,\"y\":11.79},{\"x\":1685565438280,\"y\":11.7},{\"x\":1685565738251,\"y\":11.53},{\"x\":1685566038259,\"y\":11.53},{\"x\":1685566338265,\"y\":11.53},{\"x\":1685566638303,\"y\":11.43},{\"x\":1685566938268,\"y\":11.43},{\"x\":1685567238323,\"y\":11.33},{\"x\":1685567538343,\"y\":11.39},{\"x\":1685567838304,\"y\":11.31},{\"x\":1685568138281,\"y\":11.39},{\"x\":1685568438336,\"y\":11.31},{\"x\":1685568738284,\"y\":11.31},{\"x\":1685569038329,\"y\":11.31},{\"x\":1685569338310,\"y\":11.25},{\"x\":1685569638302,\"y\":11.25},{\"x\":1685569938300,\"y\":11.25},{\"x\":1685570238298,\"y\":10.97},{\"x\":1685570538297,\"y\":10.97},{\"x\":1685570838294,\"y\":10.97},{\"x\":1685571138323,\"y\":10.78},{\"x\":1685571438384,\"y\":10.78},{\"x\":1685571738313,\"y\":10.78},{\"x\":1685572038419,\"y\":10.8},{\"x\":1685572338315,\"y\":10.8},{\"x\":1685572638324,\"y\":10.8},{\"x\":1685572938327,\"y\":10.44},{\"x\":1685573238329,\"y\":10.44},{\"x\":1685573538333,\"y\":10.44},{\"x\":1685573838369,\"y\":10.44},{\"x\":1685574138332,\"y\":10.44},{\"x\":1685574438328,\"y\":10.43},{\"x\":1685574738335,\"y\":10.43},{\"x\":1685575038372,\"y\":10.42},{\"x\":1685575338334,\"y\":10.43},{\"x\":1685575638376,\"y\":10.44},{\"x\":1685575938389,\"y\":10.48},{\"x\":1685576238419,\"y\":10.39},{\"x\":1685576538344,\"y\":10.11},{\"x\":1685576838359,\"y\":10.2},{\"x\":1685577138380,\"y\":10.29},{\"x\":1685577438375,\"y\":10.29},{\"x\":1685577738413,\"y\":10.3},{\"x\":1685578038361,\"y\":10.29},{\"x\":1685578338371,\"y\":10.3},{\"x\":1685578638503,\"y\":10.18},{\"x\":1685578938376,\"y\":10.18},{\"x\":1685579238383,\"y\":10.09},{\"x\":1685579538380,\"y\":10.17},{\"x\":1685579838438,\"y\":10.13},{\"x\":1685580138376,\"y\":9.88},{\"x\":1685580438398,\"y\":9.88},{\"x\":1685580738405,\"y\":9.94},{\"x\":1685581038616,\"y\":9.94},{\"x\":1685581338395,\"y\":9.94},{\"x\":1685581638435,\"y\":9.94},{\"x\":1685581938409,\"y\":9.88},{\"x\":1685582238480,\"y\":9.86},{\"x\":1685582538402,\"y\":9.86},{\"x\":1685582838405,\"y\":9.86},{\"x\":1685583138415,\"y\":9.86},{\"x\":1685583438613,\"y\":9.86},{\"x\":1685583738415,\"y\":9.88},{\"x\":1685584038410,\"y\":9.88},{\"x\":1685584338448,\"y\":9.79},{\"x\":1685584638454,\"y\":9.88},{\"x\":1685584938414,\"y\":9.88},{\"x\":1685585238420,\"y\":9.98},{\"x\":1685585538423,\"y\":9.89},{\"x\":1685585838440,\"y\":9.89},{\"x\":1685586138428,\"y\":9.84},{\"x\":1685586438423,\"y\":9.84},{\"x\":1685586738424,\"y\":9.79},{\"x\":1685587038648,\"y\":9.93},{\"x\":1685587338431,\"y\":9.79},{\"x\":1685587638450,\"y\":9.79},{\"x\":1685587938475,\"y\":9.88},{\"x\":1685588238559,\"y\":9.88},{\"x\":1685588538441,\"y\":9.88},{\"x\":1685588838584,\"y\":9.67},{\"x\":1685589138428,\"y\":9.58},{\"x\":1685589438536,\"y\":9.67},{\"x\":1685589738473,\"y\":9.67},{\"x\":1685590038433,\"y\":9.67},{\"x\":1685590338478,\"y\":9.67},{\"x\":1685590638761,\"y\":9.42},{\"x\":1685590938425,\"y\":9.42},{\"x\":1685591238442,\"y\":9.42},{\"x\":1685591538439,\"y\":9.31},{\"x\":1685591838504,\"y\":9.31},{\"x\":1685592138436,\"y\":9.34},{\"x\":1685592438435,\"y\":9.34},{\"x\":1685592738487,\"y\":9.38},{\"x\":1685593038723,\"y\":9.38},{\"x\":1685593338444,\"y\":9.38},{\"x\":1685593638424,\"y\":9.34},{\"x\":1685593938457,\"y\":9.34},{\"x\":1685594238655,\"y\":9.86},{\"x\":1685594538452,\"y\":9.86},{\"x\":1685594838449,\"y\":9.86},{\"x\":1685595138489,\"y\":9.84},{\"x\":1685595438547,\"y\":9.84},{\"x\":1685595738460,\"y\":9.78},{\"x\":1685596038492,\"y\":9.85},{\"x\":1685596338571,\"y\":9.85},{\"x\":1685596638545,\"y\":9.85},{\"x\":1685596938457,\"y\":9.76},{\"x\":1685597238477,\"y\":9.85},{\"x\":1685597538472,\"y\":9.8},{\"x\":1685597838494,\"y\":9.83},{\"x\":1685598138501,\"y\":9.86},{\"x\":1685598438509,\"y\":10.14},{\"x\":1685598738535,\"y\":10.14},{\"x\":1685599038819,\"y\":10.14},{\"x\":1685599338484,\"y\":10.07},{\"x\":1685599638529,\"y\":10.07},{\"x\":1685599938480,\"y\":10.14},{\"x\":1685600238698,\"y\":10.23},{\"x\":1685600538482,\"y\":10.1},{\"x\":1685600838527,\"y\":10.43},{\"x\":1685601138487,\"y\":10.43},{\"x\":1685601438740,\"y\":10.43},{\"x\":1685601738547,\"y\":10.45},{\"x\":1685602038498,\"y\":10.36},{\"x\":1685602338488,\"y\":10.43},{\"x\":1685602638682,\"y\":10.46},{\"x\":1685602938581,\"y\":10.46},{\"x\":1685603238508,\"y\":10.47},{\"x\":1685603538503,\"y\":10.47},{\"x\":1685603838572,\"y\":10.47},{\"x\":1685604138511,\"y\":10.47},{\"x\":1685604438579,\"y\":10.6},{\"x\":1685604738515,\"y\":10.51},{\"x\":1685605038560,\"y\":10.55},{\"x\":1685605338556,\"y\":11.07},{\"x\":1685605638563,\"y\":11.07},{\"x\":1685605938519,\"y\":11.07},{\"x\":1685606238594,\"y\":11.05},{\"x\":1685606538513,\"y\":11.12},{\"x\":1685606838518,\"y\":11.15},{\"x\":1685607138518,\"y\":11.15},{\"x\":1685607438879,\"y\":11.19},{\"x\":1685607738543,\"y\":11.19},{\"x\":1685608038530,\"y\":11.42},{\"x\":1685608338527,\"y\":11.33},{\"x\":1685608638628,\"y\":11.33},{\"x\":1685608938572,\"y\":11.54},{\"x\":1685609238526,\"y\":11.54},{\"x\":1685609538568,\"y\":11.54},{\"x\":1685609838674,\"y\":11.73},{\"x\":1685610138530,\"y\":11.54},{\"x\":1685610438525,\"y\":11.73},{\"x\":1685610738604,\"y\":11.81},{\"x\":1685611038666,\"y\":11.81},{\"x\":1685611338564,\"y\":11.72},{\"x\":1685611638584,\"y\":12.09},{\"x\":1685611938537,\"y\":12.09},{\"x\":1685612238596,\"y\":12.09},{\"x\":1685612538547,\"y\":12.11},{\"x\":1685612838540,\"y\":12.11},{\"x\":1685613138539,\"y\":12.07},{\"x\":1685613438767,\"y\":12.53},{\"x\":1685613738611,\"y\":12.64},{\"x\":1685614038551,\"y\":12.51},{\"x\":1685614338551,\"y\":12.64},{\"x\":1685614638741,\"y\":12.64},{\"x\":1685614938559,\"y\":12.64},{\"x\":1685615238587,\"y\":13.05},{\"x\":1685615538593,\"y\":13.15},{\"x\":1685615838836,\"y\":13.07},{\"x\":1685616138551,\"y\":13.07},{\"x\":1685616438549,\"y\":13.17},{\"x\":1685616738558,\"y\":13.26},{\"x\":1685617038760,\"y\":13.26},{\"x\":1685617338558,\"y\":13.36},{\"x\":1685617638534,\"y\":13.36},{\"x\":1685617938635,\"y\":13.73},{\"x\":1685618238566,\"y\":13.71},{\"x\":1685618538558,\"y\":13.71},{\"x\":1685618838593,\"y\":13.75},{\"x\":1685619138565,\"y\":13.75},{\"x\":1685619438673,\"y\":13.93},{\"x\":1685619738585,\"y\":13.93}]],\"labels\":[\"\"]}]","payloadType":"json","x":150,"y":180,"wires":[["3eb08d4843164efc"]]},{"id":"41e847ff22249c0e","type":"ui_group","name":"Temperature","tab":"1d985094b1a81b0c","order":5,"disp":true,"width":"24","collapse":false,"className":""},{"id":"1d985094b1a81b0c","type":"ui_tab","name":"Wide View","icon":"dashboard","disabled":false,"hidden":false}]
```
::

### 3. Using sliders and persisting the current value

Sliders are a really useful user-interface element. Where you need to control the speed of a piece of machinery, having the ability to use a slider rather than manually typing in a value is a much better fit for shop-floor HMIs.

When using sliders in your dashboards, it's important to consider how you will persist the state of the slider. If you don't persist the state, you will find that a redeploy of your dashboard will set the slider back to the default value. That would also change the speed of your machine.

:video{ariaLabel="An example of a slider in a HMI" autoPlay="true" height="164" loop="true" muted="true" playsInline="true" preload="none" width="540"}

To retain the current value of the slider we can use Node-RED's context. Each time the slider value is updated, we store the value in context. Each time we deploy the flow, we can now load the value back from context.

If you'd like to view this slider and the flow which makes it work on your own Node-RED, you can import the flow below.

::render-flow{:height='300'}
```json
[{"id":"05340e7a133098a6","type":"ui_slider","z":"0e6be5088cecccc1","name":"","label":"{{msg.payload}}","tooltip":"","group":"41e847ff22249c0e","order":1,"width":0,"height":0,"passthru":true,"outs":"all","topic":"topic","topicType":"msg","min":0,"max":"20","step":1,"className":"","x":230,"y":300,"wires":[["945db61c94fc0704","ad7819da2cfbcd4e"]]},{"id":"849d76d146ff8c12","type":"inject","z":"0e6be5088cecccc1","name":"Inject on deploy","props":[],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":160,"y":240,"wires":[["aeedb3c60965c1af"]]},{"id":"945db61c94fc0704","type":"change","z":"0e6be5088cecccc1","name":"Set global-slider-value = msg.payload","rules":[{"t":"set","p":"slider-value","pt":"global","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":450,"y":300,"wires":[[]]},{"id":"aeedb3c60965c1af","type":"change","z":"0e6be5088cecccc1","name":"Set msg.payload = global.slider-value","rules":[{"t":"set","p":"payload","pt":"msg","to":"slider-value","tot":"global"}],"action":"","property":"","from":"","to":"","reg":false,"x":410,"y":240,"wires":[["05340e7a133098a6"]]},{"id":"ad7819da2cfbcd4e","type":"ui_text","z":"0e6be5088cecccc1","group":"41e847ff22249c0e","order":2,"width":0,"height":0,"name":"","label":"","format":"The current value is {{msg.payload}} meters per minute","layout":"row-spread","className":"","style":false,"font":"","fontSize":16,"color":"#000000","x":350,"y":340,"wires":[]},{"id":"41e847ff22249c0e","type":"ui_group","name":"Meters per Minute","tab":"466e33abb95e4dd4","order":5,"disp":true,"width":"10","collapse":false,"className":""},{"id":"466e33abb95e4dd4","type":"ui_tab","name":"Sliders","icon":"dashboard","order":3,"disabled":false,"hidden":false}]
```
::

We hope you found these tips useful, if you'd like to suggest some of your own tips which you think we should share in our future blog posts please [get in touch](mailto\:contact@flowfuse.com). You can also read some of our previous Node-RED tips using the links below.

[Node-RED Tips - Subflows, Link Nodes, and the Range Node](https://flowfuse.com/blog/2023/04/3-quick-node-red-tips-6/):br[Node-RED Tips - Importing, Exporting, and Grouping Flows](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-5/):br[Node-RED Tips - Smooth, Catch, and Maths](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-4/):br[Node-RED Tips - Exec, Filter, and Debug](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-3/):br[Node-RED Tips - Deploying, Debugging, and Delaying](https://flowfuse.com/blog/2023/02/3-quick-node-red-tips-2/):br[Node-RED Tips - Wiring Shortcuts](https://flowfuse.com/blog/2023/02/3-quick-node-red-tips-1/)


# Community News June 2023

Welcome to the FlowFuse newsletter for June 2023, a monthly roundup of what’s been happening with both FlowFuse and the wider Node-RED community.

## New Release

This week we released FlowFuse 1.8, featuring high availability for Node-RED and DevOps software delivery pipelines. Both these features were in high demand from our community and will make it easier to reliably deliver Node-RED for business critical applications.

Read about the details of FlowFuse 1.8 in our [release announcement](https://flowfuse.com/blog/2023/06/flowforge-1-8-released/).

## Upcoming events

### Building Node-RED Applications for Scalability and High Availability

Our June webinar will focus on the new FlowFuse 1.8 feature of running high availability Node-RED applications. Marian Demme, FlowFuse Product Manager, will lead this session and share practical insights and best practices to show how FlowFuse can unlock the true potential of Node-RED in large-scale deployments.

[Sign-up today](https://flowfuse.com/webinars/2023/building-scalable-ha-node-red/) to join us on June 22.

### Build an Edge-to-Cloud Solution with the MING Stack

On June 27, FlowFuse is doing a webinar with our friends at InfluxDB. A great opportunity to see how easy it is to use Node-RED and InfluxDB to send data from the edge to the cloud.  [Sign-up today](https://www.influxdata.com/resources/build-an-edge-to-cloud-solution-with-the-ming-stack/?utm_source=partner&utm_medium=referral&utm_campaign=2023-06-27_Webinar_FlowFuse-NodeRED&utm_term=speaker){rel="&#x22;nofollow&#x22;"}.

## From our Blog

- [Bringing High Availability to Node-RED](https://flowfuse.com/blog/2023/05/bringing-high-availability-to-node-red/) - FlowFuse CTO discusses the strategy for delivering high availability in the FlowFuse platform.
- Two articles featuring how to connect Modbus data with Node-RED:
  - [Using Node-RED to Visualize Industrial Production Data via Modbus](https://flowfuse.com/node-red/protocol/modbus/)
  - \[Best Practices Integrating a Modbus Device With Node-RED]\(/blog/2023/05/integrating modbus with node-red/)
- [Node-RED Tips - Dashboard Edition](https://flowfuse.com/blog/2023/06/3-quick-node-red-tips-7/) - A new set of Node-RED quick tips that are focused on using Node-RED Dashboard.
- [Persisting chart data in Node-RED Dashboards](https://flowfuse.com/blog/2023/05/persisting-chart-data-in-node-red/) - How to store data from the Node-RED Dasbhaord chart node.
- [Node-RED Community Survey Results](https://flowfuse.com/blog/2023/05/node-red-community-survey-results/) - A quick summary of the Node-RED Community Survey results.
- [FlowFuse 1.7 Now Available with Remote Node-RED Editor Access](https://flowfuse.com/blog/2023/05/flowforge-1-7-released/)

## From the Community

Gerrit Riessen has published a list of [Pros and Cons for using Node-RED](https://gorenje.medium.com/fourteen-for-fourteen-against-why-i-love-hate-and-connect-with-node-23797f9466ec){rel="&#x22;nofollow&#x22;"}. It is a pretty comprehensive list so check it out. FlowFuse is working to address some of the cons in Gerrit's list, specifically software delivery pipelines and the ability to deploy out to many end points.

## Join Our Team

FlowFuse is expanding our team. Check out the current openings:

- [DevOps Engineer](https://boards.greenhouse.io/flowfuse/jobs/4796271004){rel="&#x22;nofollow&#x22;"}
- [Sales Representative](https://boards.greenhouse.io/flowfuse/jobs/4843566004){rel="&#x22;nofollow&#x22;"}


# The Next Step in Data Visualization - Announcing the Successor to the Node-RED Dashboard

For the past several years, the Node-RED Dashboard has been an indispensable tool for many Node-RED users. It has offered a seamless way to create live dashboards, enabling the quick and intuitive creation of user interfaces for Node-RED flows. However, as the saying goes, "all good things must come to an end."

We at FlowFuse have identified a significant need for a modern, interactive data visualization and dashboard solution. Having evaluated a wide range of options, we've decided to embark on an exciting journey: the creation of what we hope becomes the official successor to the Node-RED Dashboard.

## The Problem at Hand

The original Node-RED Dashboard is based on Angular v1, which is no longer maintained. Although small patches have been and will continue to be applied on a "best can do" basis, there will be no major feature upgrades. The lack of ongoing maintenance and updates has the potential to lead to underlying security breakages, a risk we are not comfortable taking. We have recognized the need to innovate and adapt, which is why we are creating a completely new project to replace the existing Node-RED Dashboard.

## The Solution

The successor to the Node-RED Dashboard will be a completely new project, published as a separate package. This new project will take the reins from the old dashboard and guide us into the future with the support and blessing of the existing dashboard maintainers. The Node-RED community can rest assured that the project will stay under the Apache 2.0 licence and keep intact the core principles of open-source and community-driven development.

## Community Involvement and Open Source Contribution

We believe in the power of the community, and we want your feedback. If there are features you'd like to see or improvements you think can be made, we invite you to open a [Github issue](https://github.com/FlowFuse/node-red-dashboard/issues/new/choose){rel="&#x22;nofollow&#x22;"}. Your insights and suggestions will be invaluable in shaping the future of this project. Contributions from the community are not just welcome, but highly encouraged. We believe that the strength of a project is proportional to the strength of its community.

In our commitment to transparency and collaboration, we will be documenting all major decision-making processes and sharing the details here in our blog as they become available. By working closely with additional Node-RED key figures like Dave Conway-Jones, and by making our development process as open and collaborative as possible, we aim to ensure that the successor to the Node-RED Dashboard lives up to the high standards set by the original, while also introducing innovative features and enhancements.

## Join the Team

Are you a developer looking for a new challenge? We are searching for a freelancer to help us with the development of the first version of the new dashboard. This is a 2-3 month project that provides an exciting opportunity to contribute to the future of data visualization and Node-RED. If you're interested, [we'd love to hear from you.](https://boards.greenhouse.io/flowfuse/jobs/4911532004){rel="&#x22;nofollow&#x22;"}

## Charting the Course

As we embark on this new journey, we are excited about the potential of the successor to the Node-RED Dashboard. The road ahead will be filled with challenges, but we are confident that with the help of the community, and a dedicated team, we will create a tool that surpasses its predecessor in every way.

Join us on this exciting journey as we innovate, create, and redefine the future of data visualization with the successor to the Node-RED Dashboard.


# FlowFuse now offers High Availability Node-RED

FlowFuse 1.8 introduces two key features that allow organizations to reliably deploy Node-RED applications into production. In 1.8, it is now possible to run Node-RED applications with high availability so the application is more scalable and more fault tolerant. FlowFuse 1.8 also introduces software deliver pipelines, so development teams can now set up dev/test/production environments for their Node-RED applications.

## More reliable and scalable Node-RED applications

FlowFuse now makes it possible to deploy business critical applications built in Node-RED that are reliable and scalable. The new 1.8 features allows a Node-RED instance to be deployed in high availability mode, meaning two instances of the same Node-RED flows are available behind a load balancer. This allows for increased traffic to be automatically distributed across the two Node-RED instances. This means your Node-RED applications can handle more traffic and experience less downtime. For more details, please see our [documentation](https://flowfuse.com/docs/user/high-availability).

Additionally, we're pleased to offer a 30-day premium trial license for self-managed installs on Kubernetes. To avail of this offer, book a demo at [flowforge.com/book-demo](https://flowfuse.com/book-demo).

High Availability is our first [preview feature](https://flowfuse.com/handbook/engineering/product/versioning/#preview-features), and your feedback is crucial. We encourage you to try out HA in your Node-RED instances and share your experiences with us. Your feedback will help us refine this feature and make it even better.

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: mbDkjKhVwIw
---
::

## DevOps Pipelines

FlowFuse 1.8 introduces the concept of Pipelines to better organize your Node-RED development. Development team can now set up different staging environments for different steps in the development cycle, ex. test, development and production. Node-RED instances can be pushed along a pipeline as they move along the development process. This allows for a better organized and predictable development process for your team.

The new Pipelines feature builds upon the Staged Development support that we introduced in[FlowFuse Version 1.4](https://flowfuse.com/blog/2023/02/flowforge-1-4-0-released/). We highly recommend that development teams avoid developing their flows directly in production instances. This approach fosters a more reliable and robust development process, reducing the risks associated with production environment modifications. Instead, start your development in a dedicated development or test instance and then deploy your Node-RED instance to production once they have been thoroughly tested and reviewed.

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: Pbql22f3vqY
---
::

## User interface for Device Agent

In our previous release, we introduced [Editor Access for Devices](https://flowfuse.com/blog/2023/05/flowforge-1-7-released/). Now, the FlowFuse Device Agent now comes with its very own User Interface (UI) for configuration.

Imagine this: Your industrial equipment arrives with the Device Agent preinstalled. In the past, you might have faced challenges in configuring and connecting your device with FlowFuse, particularly if you had no direct shell access. But not any more.

With the newly introduced UI, you can easily set up and connect your device with FlowFuse without needing to access the command line interface directly. This simplifies the process significantly and saves you time. For more details, see our [documentation](https://flowfuse.com/docs/device-agent/introduction/).

## Node-RED 3.1 Beta 3 Available

FlowFuse Cloud is a great place to try out the new Node-RED features, with FlowFuse Cloud now including the [Node-RED 3.1.0-beta.3](https://discourse.nodered.org/t/node-red-3-1-0-beta-3-released/78716){rel="&#x22;nofollow&#x22;"}. If you want to try this version you can [duplicate your instance](https://flowfuse.com/docs/user/instance-settings/) and [upgrade your stack](https://flowfuse.com/docs/user/changestack/).

## Ongoing Topics

### SOC2 Certification

We're making great strides on our journey towards SOC2 certification, striving to meet the highest industry standards for security and privacy. While we're not quite ready to disclose specific milestones, be assured that everything is progressing smoothly. As we continue working diligently towards our target, we promise to keep you informed every step of the way. Our unwavering commitment to deliver secure and private services to our customers and partners remains our foremost priority. Stay tuned for more updates!

## What's next?

We're always working to enhance your experience with FlowFuse. Here's how you can stay informed and contribute:

- **Roadmap Overview**: Check out our [Product Roadmap Page](https://flowfuse.com/changelog/) to see what we're planning for future updates.
- **Entire Roadmap**: Visit our [Roadmap on GitHub](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"} to follow our progress and contribute your ideas.
- **Feedback**: We're interested in your thoughts about FlowFuse. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Bug Fixes

When editing a device in developer mode via the tunnel/proxy connection, a list of team projects are not presented in the "Target" field of the project-link nodes. [#2228](https://github.com/FlowFuse/flowfuse/issues/2228){rel="&#x22;nofollow&#x22;"}

If a user invites an external user to their team with an sso-enable email domain, when that user registers and logs in, they are not added to the team they were invited to and must be re-invited. [#2232](https://github.com/FlowFuse/flowfuse/issues/2232){rel="&#x22;nofollow&#x22;"}

No warning given if tying to start device editor when NR is not running [#2233](https://github.com/FlowFuse/flowfuse/issues/2233){rel="&#x22;nofollow&#x22;"}

Stuck on the form Create a new Application & Instance after using an already known instance name [#2221](https://github.com/FlowFuse/flowfuse/issues/2221){rel="&#x22;nofollow&#x22;"}

If the device agent finds itself in Developer mode, it stops pulling snapshots from the platform [#97](https://github.com/FlowFuse/device-agent/issues/97){rel="&#x22;nofollow&#x22;"}

Accessing the Admin Settings General page resets the Platform Statstics token [#2140](https://github.com/FlowFuse/flowfuse/issues/2140){rel="&#x22;nofollow&#x22;"}

Selection of Team and Instance in nr-tools-plugin not possible [#15](https://github.com/FlowFuse/nr-tools-plugin/issues/15){rel="&#x22;nofollow&#x22;"}

HOME env var not set within Node-RED process [#117](https://github.com/FlowFuse/flowforge-nr-launcher/issues/117){rel="&#x22;nofollow&#x22;"}

## Try it out

We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.8.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go the the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# Use any npm module in Node-RED (2026)

Node-RED has [an incredibly rich resource of integrations available](https://flows.nodered.org/search?type=node), but sometimes you need that little bit of extra functionality, or access to a Node.js module that doesn't have it's own custom nodes in Node-RED. &#x2A;*We can easily import any npm module within the built-in Node-RED function nodes.**

Historically in Node-RED, you would have needed to manually `npm install` modules from the command line, but now that it's so easy to run Node-RED in the Cloud, where you don't have easy access to those tools, what are the other options available?

## Function Node - Setup

![Location of the "add" button in order to import an npm module intoa  function node](https://flowfuse.com/blog/2023/06/images/npmimport-add.jpg "Location of the 'add' button in order to import an npm module intoa  function node")

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

All you need is the name of the module you want to import, then:

1. Drop in a new "function" node & double-click it
2. Switch to the "Setup" tab
3. Underneath the "modules" tab, click "+ add" in the bottom-left of the window.
4. Enter the name of the module you want to use in the newly created row, and (optionally) modify the `variable` that this module will be imported in as.
5. Switch back to the "On Message" tab and write your function. Your new module will be available via the `variable` you defined in the "Setup" tab.

## Example: Moment.js

:video{controls="true" height="315" width="560"}

Recently we wanted to use [moment](https://www.npmjs.com/package/moment){rel="&#x22;nofollow&#x22;"} for some custom date calculations. Whilst there was set of [Moment Node-RED nodes](https://flows.nodered.org/node/node-red-contrib-moment){rel="&#x22;nofollow&#x22;"} already available, it didn't have all of the functionality we needed.

So, all we needed to do was import the module into a function node, and define our comparison there instead, here's a working example:

## Example: Easy CRC

:video{controls="true" height="315" width="560"}

Something we see [a lot on the Node-RED Forums](https://discourse.nodered.org/search?q=crc%20order%3Alatest){rel="&#x22;nofollow&#x22;"} are questions on how to conduct CRC calculations. There is a popular node module `easy-crc` that can be imported and used in the function nodes, e.g:

## Example: PostHog

:video{controls="true" height="315" width="560"}

Node-RED is great for [data integration](https://flowfuse.com/use-cases/data-integration/). We use [PostHog](https://posthog.com/) for our internal Product Analysis. We record live events as they occur on FlowFuse Cloud to better understand features that are (and are not) used.

We wanted to investigate whether or not we could add backdated data, which in theory was possible via their [posthog-node](https://posthog.com/docs/libraries/node) module. We wanted to populate it with data driven from our own database and API.

Within two minutes, we could wire up a node to retrieve data from our API, and then ingest it into `posthog-node` via the import of a function node.

## Simplify Function Node Creation with FlowFuse

[FlowFuse](https://flowfuse.com) provides a powerful platform to enhance, scale, and secure your Node-RED applications efficiently. One of our latest features, the **FlowFuse Assistant**, is designed to streamline the process of creating Function nodes.

With the FlowFuse Assistant, you can leverage AI to generate Function nodes effortlessly. Just input your prompt, and the Assistant will handle the creation for you, saving time and reducing manual coding.

To explore how to make the most of the FlowFuse Assistant and its capabilities, check out the [Assistants Documentation](https://flowfuse.com/docs/user/expert/).


# Introducing the FlowFuse Community Forum

We are thrilled to announce the launch of the [Community Forum for FlowFuse](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"}.
A forum dedicated to empowering developers and enthusiasts to create innovative
applications using FlowFuse, Node-RED and related technologies.

Our community faces a new set of challenges, for example how to configure FlowFuse templates as administrator, or integration of the FlowFuse platform into another existing environment. These questions do not fit on the Node-RED discourse which is why FlowFuse now sports our own Community Forum. Furthermore, it’s the intent to keep the Node-RED forums vendor agnostic by the OpenJS foundation. Given FlowFuse is a vendor, it’s a fine balance to find. We hope and intend to be additive to the Node-RED community at large.

At FlowFuse, our vision is to create a thriving community of Node-RED and MQTT enthusiasts who are passionate about building real-world solutions. We believe in the power of collaboration, knowledge sharing, and problem-solving. With this in mind, FlowFuse aims to foster a positive and inclusive environment where members can engage in discussions, exchange ideas, and support one another.

Initially the forum is used to allow for discussions under each blog post on the FlowFuse blog, as well as a venue to provide community support. We also welcome discussions on the roadmap and backlog of FlowFuse. We have hopes that this community thrives and provides guidance, inspiration and opportunity to learn.


# Node-RED as a No-Code EtherNet/IP to S7 Protocol Converter

Frequently in industrial automation, there's a need for two devices that use different protocols to communicate with each other, requiring protocol conversion. :br
In this tutorial, we present a mock scenario where Node-RED is used to enable an Allen Bradley PLC, which uses ethernet/IP, to communicate with a Siemens PLC, which uses S7, using a no-code solution. This example is geared toward beginners and assumes that the end-user knows how to use PLCs, but may be using FlowFuse or Node-RED for the first time.

## Premise

![Mock production facility](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-1.png "FlowFuse Mock production facility")

The figure above shows the layout of a mock production facility. Inside this facility, operations suggested adding stack lights as an extra visual aid for operators to get a quick status of its 4 conveyor lines, avoiding the need to constantly monitor the HMI/SCADA displays. :br
Engineering has suggested adding a siemens S7 1200 PLC with an IO link connection to 4 stacklights, with each line PLC sending basic status information to the stacklight PLC to control the stack light outputs. :br
Line 1-3 PLCs are Siemens-based, and can communicate with the stacklight PLC natively over S7. But line 4 is an Allen Bradley PLC that uses ethernet/IP, and can't communicate with the stacklight PLC without some form of protocol conversion. :br
Traditionally, we'd use protocol gateway hardware, like Anybus or Red Lion, to convert ethernet/IP to S7. :br
But for this application, we will instead use FlowFuse, a pure software-based approach, to convert ethernet/IP to S7. Let's walk through the process.

## Pre-Requisites and Set Up

### FlowFuse

In addition to our two PLCs, we’ll be using FlowFuse software to serve our Node-RED instance. You can either self-host, on-premise or in the cloud. Or use the managed service \[FlowFuse Cloud]\({{ site.appURL }}).

In this example, we will be using a self-hosted FlowFuse instance running on [Docker](https://flowfuse.com/docs/install/docker/).

### Data Treatment on Ethernet/IP PLC

In our Allen Bradley line 4 PLC, we will send some arbitrary tags of various datatypes to the stacklight PLC for illustrative purposes, described in table 1 below -

| **Tag**           | **Data Type** | **Description**              |
| ----------------- | ------------- | ---------------------------- |
| Conveyor\_RTS     | BOOL          | Conveyor Ready to Start      |
| Robot\_RTS        | BOOL          | Robot is Ready to Start      |
| Robot\_Position   | REAL          | Robot Arm position (degrees) |
| Conveyor\_Running | BOOL          | Conveyor is running          |
| Line4\_State      | DINT          | Line 4 Machine State         |
| Line4\_Fault      | BOOL          | Line 4 is faulted            |

Table 1 - Line 4 Tags to be sent to Stacklight PLC

We can send any atomic data type we want, but it must be globally (controller) scoped.

!["Screenshot showing the AB Controller Tags"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-2.png "Screenshot showing the AB Controller Tags")

Each tag must also have external read/write access enabled.

!["Screenshot showing the AB Tag Properties"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-3.png "Screenshot showing the AB Tag Properties")

### Data Treatment on S7 PLC

In the Siemens PLC, we have a DB for the data from the Line 4 PLC to be written to.

- In the DBs attributes, “optimized block access” must be disabled.
- The tags must be writeable and accessible
- !["Screenshot showing the Siemens Tag DB Properties"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-4.png "Screenshot showing the Siemens Tag DB Properties"):br “No protection” must be set in the CPU properties
- !["Screenshot showing the Siemens CPU Properties"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-5.png "Screenshot showing the Siemens CPU Properties")

## Create The Flow

With both PLCs up and running and properly set up to send/receive remote data, we can now create a flow to act as our protocol converter.

### Install Custom Nodes

First, we need to add two custom nodes that will give Node-RED the ability to read/write ethernet/IP and S7 data.

Click the hamburger icon → manage pallette

![Screenshot showing the 'Manage palette option' in the menu](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-6.png)

On the `install` tab, search for `s7` and install the `node-red-contrib-s7` node.

!["Installing S7 node"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-7.png "Installing S7 node")

Next, search for `ethernet` and install the `node-red-contrib-cip-ethernet-ip` node.

!["InstallING EthernetIP Node"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-8.png "InstallING EthernetIP Node")
Go to the `nodes` tab and confirm both custom nodes have been properly installed.

!["Screenshot of 'Nodes' tab showing Installed nodes List"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-9.png "Screenshot of 'Nodes' tab showing Installed nodes List")

### Set Up Ethernet/IP Data

Let’s start by dragging a `eth-ip in` node onto the pallette. Then add a new endpoint, which will point to our Line4 PLC.

!["Screenshot showing dragged 'eth-ip in' node and it's config tab"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-10.png "Screenshot showing dragged 'eth-ip in' node and it's config tab")

In the endpoint `connection` properties, the connection information must match the PLC, so set the IP address and CPU slot number appropriately. Also, the default cycle time is 500ms. Depending on your application, polling the CPU at 500ms may be appropriate. But being that this is a simple stacklight, 500ms is unnecessarily fast. So we will change it to 1000ms, which is a more appropriate polling rate for this type of application.

!["Screenshot showing the eth-ip Endpoint config"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-11.png "Screenshot showing the eth-ip Endpoint config")

On the `Tags` tab, populate the tag information to match our Allen Bradley PLC. Then select `Update` to complete configuration of the `eth-ip endpoint`.

!["Screenshot showing eth-ip Endpoint Tags"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-12.png "Screenshot showing eth-ip Endpoint Tags")

Now that we have our endpoint, let’s finish configuring the `eth-ip in` node.

1. select the endpoint we just created
2. select the first tag in the drop-down
3. give the node a descriptive name

![Screeshot showing the eth-ip in Node config](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-13.png "Screeshot showing the eth-ip in Node config")

Now let’s set up a quick test to confirm our PLC connection is valid by adding a `debug` node to the `eth-ip in` node. Then hit `deploy`.

- note - you can see we also have a `comment` above the nodes that describes what is happening. This is optional but good practice to help organize and understand your flow.

The output of the debug console did not report any errors so communication appears to be okay.

![Screenshot showing the output of eth-ip in Debug panel](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-14.png "Screenshot showing the output of eth-ip in Debug panel")

But just to confirm, let’s toggle the value and see if comes through.

![Screenshot showing the eth-ip node output in Debug panel after Toggle](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-15.png "Screenshot showing the eth-ip node output in Debug panel after Toggle")

So by toggling the value and see the result, here we confirmed 2 things:

- We can detect changes in value
- the `eth-ip in` node only sends a message when the value changes, also known as Report by Exception.

Because the `eth-ip in` node implicitly uses report by exception, and the protocol doesn't rely on contiguous data consistency (unlike modbus, for instance), we can receive our data one tag at a time to keep our flow simple.

Now we can remove the debug node and add the additional `eth-ip in` nodes to receive the remaining tags from our Line 4 PLC.

Here’s how the the flow should look at this point.

![Screenshot of Line 4 PLC Nodes](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-16.png "Screenshot of Line 4 PLC Nodes")

### Set Up S7 Data

Now we’ll set up the S7 endpoint, using an `s7 out` node.

![Screenshot of s7 out Node on Palette](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-17.png "Screenshot of s7 out Node on Palette")

Populate the connection properties to match your hardware. The cycle time is updated to 1000ms to match the cycle time of our `eth-ip in` nodes. You can adjust this value to match your intended application.

!["Screenshot showing the S7 endpoint Connection"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-18.png "Screenshot showing the S7 endpoint Connection")

On the `Variables` tab, some special formatting is required to point to the absolute reference of the tag DB location in the S7 PLC.

For information on how to format S7 absolute tag references in a way the `s7 endpoint` node is expecting, refer to the [node documentation](https://flows.nodered.org/node/node-red-contrib-s7){rel="&#x22;nofollow&#x22;"} for further information.

For reference, here is an example of how we set the tags in our stacklight PLC example and how it looks in our `s7 endpoint`.

!["Screenshot of s7 endpoint Variables"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-19.png "Screenshot of s7 endpoint Variables")

Once the tags are populated we can select our configured endpoint from the dropdown list, point to our first variable, `Conveyor_RTS`, and give the node a name.

!["Screenshot of S7 out Config"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-20.png "Screenshot of S7 out Config")

Repeat this process for the remaining tags.

!["Screenshot of Stacklight PLC Nodes"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-21.png "Screenshot of Stacklight PLC Nodes")

## Test the Conversion

The only thing remaining is to simply wire the nodes together, and confirm the values pass through.

!["Screenshot of the complete flow with live Data"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-22.png "Screenshot of the complete flow with live Data")

Manipulate the incoming values and confirm the data passes through as expected. Because of the report by exception nature of the `eth-ip in` node, tag changes should be near instantaneous on the receiving PLC.

We can stop here, but we can improve this flow by adding a `filter` node on our REAL data-type, `Robot_Position`.

### Add Filter to REAL data

Depending on how noisy the REAL data is, which is common with unfiltered 4-20mA field transmitters, and how much granularity you need to capture, it is good practice to add a filter on REAL data to reduce FieldBus traffic coming out of our soft protocol converter.

!["Screenshot showing the Filter node Configuration"](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-23.png "Screenshot showing the Filter node Configuration")

In the example above, we arbitrarily applied a 3% [deadband](https://flowfuse.com/node-red/core-nodes/filter/)
to the `Robot_Position` value, which means that the value must change by greater than or equal to 3% compared to the last input value, or else the data will be discarded before being sent to the stacklight PLC.

You can adjust the deadband to find the right balance for your particular application.

We can see the effect the deadband filter had by adding debug nodes before and after the filter.

![Filter Node Debug](https://flowfuse.com/blog/2023/06/images/ethip-to-S7/e-to-p-24.png "Filter Node Debug")

As shown above, when `Robot_Position` changed from 15.6 to 15.6999..., the value was captured on the input of the filter, but was discarded on the output.

When the `Robot_Position` went from 15.6999 to 18, the filter allowed it to pass as it exceeded the deadband limit we had set.

Use filters to optimize your fieldbus converter network performance, especially if dealing with noisy signals or large quantities of REAL datatypes.

## Conclusion

In this tutorial, we demonstrated how to use Node-RED as a free Ethernet/IP to S7 protocol converter using a simple no-code approach. We showed how to configure PLC tags to be sent remotely using Ethernet/IP, how to configure PLC tags to be received remotely using S7, and how to create the flow to use Node-RED to seamlessly convert incoming PLC data between the two protocols using `node-red-contrib-cip-ethernet-ip` and `node-red-contrib-s7` custom nodes. We also took things one step further and added a `filter` node to optimize FieldBus network traffic by putting a deadband on REAL data being sent to the receiving PLC.

The end result is a simple to set up, free and performant industrial protocol converter that requires minimal PLC configuration, which allows this application to be applied in non-mission critical production systems with minimal, if any downtime. Additionally, the protocol traffic can be visually observed in real-time for easy trouble-shooting and fault analysis by simply accessing the Node-RED UI.

In later tutorials, we can show ways this simple flow can be extended to add additional capabilities not normally available in traditional off-the-shelf protocol gateways. If you found this tutorial helpful, or have any questions or comments, please leave us a comment and let us know your thoughts.

JSON source code for the flow used in this tutorial is provided below -

::render-flow{:height='500'}
```json
[{"id":"ad7b17411c8e83aa","type":"tab","label":"Line 4 to Stacklight PLC","disabled":false,"info":"","env":[]},{"id":"c97a4c9bd1981757","type":"comment","z":"ad7b17411c8e83aa","name":"AB EIP/CIP - Line 4 PLC","info":"","x":190,"y":140,"wires":[]},{"id":"2cc5227ef6a90814","type":"eth-ip in","z":"ad7b17411c8e83aa","endpoint":"4ab2910b66e16220","mode":"single","variable":"Conveyor_RTS","program":"","name":"Read Conveyor_RTS","x":200,"y":200,"wires":[["fe18ef80f9e18c13"]]},{"id":"9308dcbda17274c7","type":"comment","z":"ad7b17411c8e83aa","name":"Siemens S7 - Stacklight PLC","info":"","x":620,"y":140,"wires":[]},{"id":"fe18ef80f9e18c13","type":"s7 out","z":"ad7b17411c8e83aa","endpoint":"a1bec25858c6f3ef","variable":"Conveyor_RTS","name":"Write Conveyor_RTS","x":620,"y":200,"wires":[]},{"id":"94fe6b73efa1c56b","type":"eth-ip in","z":"ad7b17411c8e83aa","endpoint":"4ab2910b66e16220","mode":"single","variable":"Robot_RTS","program":"","name":"Read Robot_RTS","x":180,"y":280,"wires":[["7774d6ce188c288c"]]},{"id":"7e9564cd59e3d0a2","type":"eth-ip in","z":"ad7b17411c8e83aa","endpoint":"4ab2910b66e16220","mode":"single","variable":"Robot_Position","program":"","name":"Read Robot_Position","x":200,"y":360,"wires":[["832807bfdc4b76f0"]]},{"id":"c0f712b9e355f1f8","type":"eth-ip in","z":"ad7b17411c8e83aa","endpoint":"4ab2910b66e16220","mode":"single","variable":"Conveyor_Running","program":"","name":"Read Conveyor_Running","x":210,"y":440,"wires":[["fbf1b3e38897a9c7"]]},{"id":"db77621e418f1222","type":"eth-ip in","z":"ad7b17411c8e83aa","endpoint":"4ab2910b66e16220","mode":"single","variable":"Line4_State","program":"","name":"Read Line4_State","x":190,"y":520,"wires":[["cdeffd9e52cc4384"]]},{"id":"848af9b76f969dd2","type":"eth-ip in","z":"ad7b17411c8e83aa","endpoint":"4ab2910b66e16220","mode":"single","variable":"Line4_Fault","program":"","name":"Read Line4_Fault","x":190,"y":600,"wires":[["0c595b0ac2550593"]]},{"id":"7774d6ce188c288c","type":"s7 out","z":"ad7b17411c8e83aa","endpoint":"a1bec25858c6f3ef","variable":"Robot_RTS","name":"Write Robot_RTS","x":610,"y":280,"wires":[]},{"id":"f1572463c50bb4cb","type":"s7 out","z":"ad7b17411c8e83aa","endpoint":"a1bec25858c6f3ef","variable":"Robot_Position","name":"Write Robot_Position","x":620,"y":360,"wires":[]},{"id":"fbf1b3e38897a9c7","type":"s7 out","z":"ad7b17411c8e83aa","endpoint":"a1bec25858c6f3ef","variable":"Conveyor_Running","name":"Write Conveyor_Running","x":630,"y":440,"wires":[]},{"id":"cdeffd9e52cc4384","type":"s7 out","z":"ad7b17411c8e83aa","endpoint":"a1bec25858c6f3ef","variable":"Line4_State","name":"Write Line4_State","x":610,"y":520,"wires":[]},{"id":"0c595b0ac2550593","type":"s7 out","z":"ad7b17411c8e83aa","endpoint":"a1bec25858c6f3ef","variable":"Line4_Fault","name":"Write Line4_Fault","x":610,"y":600,"wires":[]},{"id":"832807bfdc4b76f0","type":"rbe","z":"ad7b17411c8e83aa","name":"","func":"deadbandEq","gap":"3%","start":"","inout":"in","septopics":true,"property":"payload","topi":"topic","x":420,"y":360,"wires":[["f1572463c50bb4cb"]]},{"id":"4ab2910b66e16220","type":"eth-ip endpoint","address":"192.168.0.5","slot":"0","cycletime":"1000","name":"Line4","vartable":{"":{"Conveyor_RTS":{"type":"BOOL"},"Robot_RTS":{"type":"BOOL"},"Robot_Position":{"type":"REAL"},"Conveyor_Running":{"type":"BOOL"},"Line4_State":{"type":"DINT"},"Line4_Fault":{"type":"BOOL"}}}},{"id":"a1bec25858c6f3ef","type":"s7 endpoint","transport":"iso-on-tcp","address":"192.168.0.10","port":"102","rack":"0","slot":"1","localtsaphi":"01","localtsaplo":"00","remotetsaphi":"01","remotetsaplo":"00","connmode":"rack-slot","adapter":"","busaddr":"2","cycletime":"1000","timeout":"3000","name":"Stacklight PLC","vartable":[{"addr":"DB1,X0.0","name":"Conveyor_RTS"},{"addr":"DB1,X0.1","name":"Robot_RTS"},{"addr":"DB1,R2","name":"Robot_Position"},{"addr":"DB1,X6.0","name":"Conveyor_Running"},{"addr":"DB1,DI8","name":"Line4_State"},{"addr":"DB1,X12.0","name":"Line4_Fault"}]}]
```
::


# Community News July 2023

Welcome to the FlowFuse newsletter for July 2023, a monthly roundup of what’s been happening with FlowFuse and the wider Node-RED community.

## New Release

Last week we released FlowFuse 1.9, featuring new API documentation available in the Swagger UI and the ability to customize Node-RED palettes.

Read about the details of FlowFuse 1.9 in our [release announcement](https://flowfuse.com/blog/2023/07/flowforge-1-9-release/).

## Upcoming events

### How to deploy Node-RED to hundreds of PLCs and IoT edge devices

Our next webinar will be focused on the device management capabilities in the FlowFuse platform. Lots of companies are deploying Node-RED to PLCs and IIoT edge computers. FlowFuse allows these companies to scale and manage Node-RED deployment out to hundreds of these types of devices. Discover how during our next webinar.

[Sign-up today](https://flowfuse.com/webinars/2023/flowforge-device-management/) to join us on July 27.

## From our Blog and Documentation

- [The Next Step in Data Visualization - Announcing the Successor to the Node-RED Dashboard](https://flowfuse.com/blog/2023/06/dashboard-announcement/) - FlowFuse announces plans to develop the next version of the Node-RED Dashboard project.
- [Node-RED as a No-Code Ethernet/IP to S7 Protocol Converter](https://flowfuse.com/blog/2023/06/node-red-as-a-no-code-ethernet_ip-to-s7-protocol-converter/) - A guide to using Node-RED for converting ethernet IP data to Siemens S7. Also a [video version](https://youtu.be/dteXgcBXUnk){rel="&#x22;nofollow&#x22;"} of the same content.
- [MQTT and its Role in IoT and Industrial IoT](https://flowfuse.com/node-red/protocol/mqtt/) - A practical explainer on the role of MQTT in IoT use cases and how to connect with an MQTT broker in Node-RED.
- Two new Node-RED Nodes Explained articles
  - [Nodes explained: Split](https://flowfuse.com/node-red/core-nodes/split/)
  - [Nodes explained: Filter](https://flowfuse.com/node-red/core-nodes/filter/)

## From the Community

- [Node-RED & Industry 4.0: The Future is Now](https://youtu.be/1GKkXJOQMhU){rel="&#x22;nofollow&#x22;"} - An informative panel discussion led by Walker Reynolds on the role of Node-RED in the future of Industry 4.0.
- [Node-RED Terminology](http://blog.openmindmap.org/blog/node-red-terminology){rel="&#x22;nofollow&#x22;"} - An explanation of the different Node-RED terminology.

## Join Our Team

FlowFuse is expanding our team. Check out the current openings:

- [Contract Front-End Engineer – Node-RED Dashboard](https://boards.greenhouse.io/flowfuse/jobs/4911532004){rel="&#x22;nofollow&#x22;"}


# First Pre-Alpha Release of the new Node-RED Dashboard

Just weeks ago, we at FlowFuse [announced our plan](https://flowfuse.com/blog/2023/06/dashboard-announcement/) to develop a successor to the Node-RED Dashboard. Today, we're excited to reveal the pre-alpha release of this highly anticipated project, bringing us one step closer to a new era of data visualization in Node-RED.

## Sneak Peek into the New Node-RED Dashboard

The Node-RED Dashboard successor is now available for install as an npm package under the name [@flowforge/node-red-dashboard](https://www.npmjs.com/package/@flowforge/node-red-dashboard){rel="&#x22;nofollow&#x22;"} in your Node-RED palette manager.

This pre-alpha version includes the first set of Vue.js-based elements familiar to Node-RED Dashboard users:

!["new Node-RED Dashboard Elements"](https://flowfuse.com/blog/2023/07/images/nr-dashboard-screenshot.png "new Node-RED Dashboard Elements")

This is but a hint of what's to come. The objective of these pre-alpha releases is to provide early access to the current status.

The strength of the project comes from the community. Your insights, suggestions and contributions play a significant role in shaping the future of this dashboard. Keep them coming through our [Github page](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.

## Current Status and Next Steps

As of now, we've implemented the following Dashboard Widgets:

- UI Text ([ui-text Widget](https://github.com/FlowFuse/node-red-dashboard/issues/38){rel="&#x22;nofollow&#x22;"})
- Text Input ([ui-text-input Widget](https://github.com/FlowFuse/node-red-dashboard/issues/39){rel="&#x22;nofollow&#x22;"})
- Range Slider ([ui-slider Widget](https://github.com/FlowFuse/node-red-dashboard/issues/47){rel="&#x22;nofollow&#x22;"})
- Dropdown/Select ([ui-dropdown Widget](https://github.com/FlowFuse/node-red-dashboard/issues/45){rel="&#x22;nofollow&#x22;"})

We've also introduced a new widget:

- Markdown ([ui-markdown Widget](https://github.com/FlowFuse/node-red-dashboard/issues/62){rel="&#x22;nofollow&#x22;"})

Not yet part of the first Pre-Alpha Release:

- Toggle Switch ([ui-switch Widget](https://github.com/FlowFuse/node-red-dashboard/issues/42){rel="&#x22;nofollow&#x22;"})
- Color Picker ([ui-color-picker Widget](https://github.com/FlowFuse/node-red-dashboard/issues/46){rel="&#x22;nofollow&#x22;"})
- Number Input ([ui-numeric Widget](https://github.com/FlowFuse/node-red-dashboard/issues/41){rel="&#x22;nofollow&#x22;"})
- Form ([ui-form Widget](https://github.com/FlowFuse/node-red-dashboard/issues/49){rel="&#x22;nofollow&#x22;"})
- Date selector ([ui-date-picker](https://github.com/FlowFuse/node-red-dashboard/issues/32){rel="&#x22;nofollow&#x22;"})

Our immediate focus is to continue adding the missing elements from the original Node-RED Dashboard, releasing each as soon as they're fully developed. This will significantly increase the frequency of our releases in the upcoming weeks.

In addition to these releases, we plan to publish regular blog posts titled "What's New in Node-RED Dashboard". These posts will keep you informed of all the latest features, updates, and improvements.


# FlowFuse 1.9.3 and Device Agent 1.9.5 released

FlowFuse and the Device Agent both received updates yesterday that bring improvements to the Device Agent editor experience, making it more resilient to network issues.

## Improving the Device Agent editor experience

The ability to remotely edit flows running the Device Agent has been warmly welcomed by many users on the platform. Along with that comes great feedback we can use to continue improving the user experience.

Some early feedback identified issues with the resilience of the tunnel we connect between the Device Agent and the platform. If the tunnel was interrupted for any reason, the user would have to manually set it up again.

With the FlowFuse 1.9.3 release, now running FlowFuse Cloud, along with the latest version of the Device Agent, we have made the tunnel much more resilient. It can now restablish itself without any intervention from the user - making for a much more seamless experience.

- [#2488](https://github.com/FlowFuse/flowfuse/pull/2488){rel="&#x22;nofollow&#x22;"}
- [#2507](https://github.com/FlowFuse/flowfuse/pull/2507){rel="&#x22;nofollow&#x22;"}

## Other New Features and Bug Fixes

- Fixes incorrect 'start-failed' notifications when restarting an instance [#2505](https://github.com/FlowFuse/flowfuse/pull/2505){rel="&#x22;nofollow&#x22;"} The system log now includes more information about the callingThe FlowFuse device agent is now supported on Windows [#78](https://github.com/FlowFuse/device-agent/issues/78){rel="&#x22;nofollow&#x22;"}
- Ensures the system logging captures the proper source IP address of requests [#2505](https://github.com/FlowFuse/flowfuse/pull/2503){rel="&#x22;nofollow&#x22;"}
- A few documentation updates, including a clarfication on how to run the Device Agent under docker [#2498](https://github.com/FlowFuse/flowfuse/pull/2498){rel="&#x22;nofollow&#x22;"}

## What's next?

We're always working to enhance your experience with FlowFuse. Here's how you can stay informed and contribute:

- **Roadmap Overview**: Check out our [Product Roadmap Page](https://flowfuse.com/changelog/) to see what we're planning for future updates.
- **Entire Roadmap**: Visit our [Roadmap on GitHub](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"} to follow our progress and contribute your ideas.
- **Feedback**: We're interested in your thoughts about FlowFuse. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try it out

We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.9.3.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go the the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# FlowFuse now offers API Documentation with Swagger UI

FlowFuse 1.9 adds new features to make it easier to administer FlowFuse platform deployments, including new API documentation and the ability to create customized Node-RED palettes.

## API Documentation

FlowFuse API allows developers to programmatically interact with the FlowFuse platform. This makes it possible to integrate FlowFuse into different infrastructure technologies, create scripts to automate specific FlowFuse tasks and embed FlowFuse into other applications.

In the 1.9 release we are now publishing our [API documentation](https://flowfuse.com/docs/api/) using the [OpenAPI specification](https://swagger.io/specification/){rel="&#x22;nofollow&#x22;"} and making it viewable with the Swagger UI. Both these industrial standards will make using the FlowFuse API easier to use and understand.

## Customize Node-RED Palettes [#2002](https://github.com/FlowFuse/flowfuse/issues/2002){rel="&#x22;nofollow&#x22;"}

FlowFuse platform adminstrators are now able to create customized Node-RED palettes that will be used when a Node-RED instance is created. An adminstator can create pre-defined templates to specify the nodes that should be included in the palette. This makes it easier for FlowFuse teams to standardized on Node-RED usage across an organization.

Note: this feature is not available for FlowFuse cloud users since they do not have administrator access.

## New RBAC Role for Dashboard users [#2292](https://github.com/FlowFuse/flowfuse/issues/1924){rel="&#x22;nofollow&#x22;"}

A new FlowFuse user role has been created to view Node-RED dashboards. This allows for users to view Nod-RED dashboards without access to the Node-RED editor or requiring separate login credentials.

## Other New Features

- FlowFuse device agent is now supported on Windows [#78](https://github.com/FlowFuse/device-agent/issues/78){rel="&#x22;nofollow&#x22;"}
- Allow local configuration of https/httpStatic on a device [#110](https://github.com/FlowFuse/device-agent/issues/110){rel="&#x22;nofollow&#x22;"}
- Implementing custom certificate settings for device configuration [#2257](https://github.com/FlowFuse/flowfuse/issues/2257){rel="&#x22;nofollow&#x22;"}
- Allow devices to access the "Snapshot ID" and the "Snapshot Name" running on them [#94](https://github.com/FlowFuse/device-agent/issues/94){rel="&#x22;nofollow&#x22;"}
- High Availability logging enhanced: Individual Node-RED Instance replica querying and filtering [#2260](https://github.com/FlowFuse/flowfuse/issues/2260){rel="&#x22;nofollow&#x22;"}
- High Availability is now generally available [#2414](https://github.com/FlowFuse/flowfuse/issues/2412){rel="&#x22;nofollow&#x22;"}

## Bug Fixes

- Can not promote NR instance in DevOps Pipeline [#2363](https://github.com/FlowFuse/flowfuse/issues/2363){rel="&#x22;nofollow&#x22;"}
- Billing team menu item missing on first page load [#2398](https://github.com/FlowFuse/flowfuse/issues/2398){rel="&#x22;nofollow&#x22;"}
- Duplicate labels in Instance Import dialog [#2200](https://github.com/FlowFuse/flowfuse/issues/2200){rel="&#x22;nofollow&#x22;"}
- Broken littie animations [#2354](https://github.com/FlowFuse/flowfuse/issues/2354){rel="&#x22;nofollow&#x22;"}
- Instance Logs page doesn't handle errors well [#1083](https://github.com/FlowFuse/flowfuse/issues/1083){rel="&#x22;nofollow&#x22;"}
- Device continues to run edited flows once taken out of dev mode [#2323](https://github.com/FlowFuse/flowfuse/issues/2323){rel="&#x22;nofollow&#x22;"}
- Device Editor cannot pickup FF theme [#89](https://github.com/FlowFuse/device-agent/issues/89){rel="&#x22;nofollow&#x22;"}

## Community Contributions

Thanks to our community members for their contributions to this release.

- sumitshinde-84 - make Instance and application names in delete popup easily selectable [#2291](https://github.com/FlowFuse/flowfuse/pull/2291){rel="&#x22;nofollow&#x22;"}
- biancode - Fixed typo in doc [#2327](https://github.com/FlowFuse/flowfuse/pull/2327){rel="&#x22;nofollow&#x22;"}

## What's next?

We're always working to enhance your experience with FlowFuse. Here's how you can stay informed and contribute:

- **Roadmap Overview**: Check out our [Product Roadmap Page](https://flowfuse.com/changelog/) to see what we're planning for future updates.
- **Entire Roadmap**: Visit our [Roadmap on GitHub](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"} to follow our progress and contribute your ideas.
- **Feedback**: We're interested in your thoughts about FlowFuse. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try it out

We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.9.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go the the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# How to Build an OPC UA Client Dashboard in Node-RED - Part 3 (2026)

This article is the third and final part of our OPC UA content series. In the [first article](https://flowfuse.com/blog/2023/07/how-to-deploy-a-basic-opc-ua-server-in-node-red/), we cover some OPC UA fundamentals and walk through an example OPC UA Server flow. In the [second article](https://flowfuse.com/node-red/protocol/opc-ua/), we built a SSL-secured OPC UA server using data from an Allen Bradley PLC as a source.
In this article, we show how to build an OPC Client in Node-RED that communicates with a 3rd party OPC UA Server and utilizes an interactive dashboard.

This article will requires the [Prosys OPC UA Simulation Server](https://prosysopc.com/products/opc-ua-simulation-server/){rel="&#x22;nofollow&#x22;"}, an application designed for testing OPC UA client applications and learning the technology. It’s a free cross-platform application that supports Windows, Linux, and MacOS. This article will use the Windows version.

Note: full source code for the OPC Client Dashboard is included at the end of the article.

## Custom Nodes Used & Assumptions

Several custom nodes are required in order to properly deploy this flow. For more detailed information on how to install a custom node, follow the instructions from an [earlier article](https://flowfuse.com/blog/2023/06/node-red-as-a-no-code-ethernet_ip-to-s7-protocol-converter/) where the process on installing custom nodes is explained in detail.

- [@flowfuse/node-red-dashboard](https://flows.nodered.org/node/@flowfuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}
- [node-red-contrib-opcua](https://flows.nodered.org/node/node-red-contrib-opcua){rel="&#x22;nofollow&#x22;"}
- [@flowfuse/node-red-dashboard-2-ui-led](https://flows.nodered.org/node/@flowfuse/node-red-dashboard-2-ui-led){rel="&#x22;nofollow&#x22;"}

As this is not a production application, no security will be utilized, and it is assumed that the OPC UA Server is running on the same network as the Node-RED OPC Client.

Is it also assumed that the end user of this article has familiarization with dashboards. There are many dashboard basic guides available on our FlowFuse website, For more infomation go to [Node-RED Dashboard 2.0 guides](https://flowfuse.com/blog/dashboard/).

## Install and Deploy the Prosys OPC UA Simulation Server

The Prosys OPC UA Simulation Server is [free to download](https://prosysopc.com/products/opc-ua-simulation-server/evaluate/){rel="&#x22;nofollow&#x22;"}, but requires a sign-up process. Download and install the server, then run the application. Once the application is started, the first thing you should do is go to `options -> switch to expert mode`.

This will give us access to the address space tab, which we will need to develop our client application in Node-RED.

![expert-mode.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/expert-mode.png){dataZoomable=""}

When the application is run, an endpoint url will be displayed on the `status` tab, along with an indication that the server is currently running.

![opc-endpoint-url.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/opc-endpoint-url.png){dataZoomable=""}
Copy the connection endpoint, but be warned that you will likely need to replace the computer name (in my case `DESKTOP-0K0483A`, with the actual IP address of the machine running the server. The IP address of the machine on my local network is `192.168.0.141`, which changes my UA TCP endpoint address to `opc.tcp://192.168.0.141:53530/OPCUA/SimulationServer`.

Now the simulation server is set up and we are ready to start developing the OPC Client application.

## Objectives of the Node-RED OPC Client Dashboard Application

The goal is not to develop a production-level application, rather, it’s to show a variety of features that one can utilize to demonstrate common OPC UA Client application capabilities in Node-RED, while also demonstrating a variety of methods to visualize the results in a dashboard. There are 4 main objectives of the Node-RED OPC Client Dashboard application. They are:

1. Browse hierarchical server address space structure & display on a dashboard
2. Read OPC UA values from various namespaces, showing a variety of datatypes and different ways they can be visualized
3. Write OPC UA values back to the OPC UA server directly from the OPC UA Client dashboard
4. Read alarms & events from the OPC UA Server and display them on the dashboard

Rather than building the flow step-by-step, the flow source code will be presented for each objective, and a the flow will be explained so that it is understood what is happening in each section of code.

## Browse Hierarchical Server Address Space Structure With OPC UA Browser Node

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

The first flow will browse the hierarchical OPC UA Server address space structure and display it on the dashboard.

![image-20230727-085611.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/image-20230727-085611.png){dataZoomable=""}

You can import this flow into Node-RED using the code below:

::render-flow
```json
[{"id":"ca62be3e01388319","type":"group","z":"5b972161c4e0464e","name":"Browse Hierarchical Address Space Structure & Display on Dashboard","style":{"label":true,"color":"#000000"},"nodes":["6b17b2da2b942bb4","61797eccf2785257","4d92d940177b6ee3","68a113d5893b7c01","d0c969b6a59fac3a","639da01fc957e547","29437ca7222d9a64","49983d5da0958bf2","49040d0cf1144f0a","e7c55f412ef86543","de21b7ad98a05833","2d56e9a431c21a3b","ac95bd0e2b304eec","6fdabcc2950ccf4e","1c49fa5142d2cf17","335878527020598c","7b208f2e8cba6205","52dd2e5dcddad58f","a5acdccfd2033aec","157322c9c360446d","78a012e5db377fd9"],"x":94,"y":139,"w":1172,"h":422},{"id":"6b17b2da2b942bb4","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"ca62be3e01388319","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":550,"y":280,"wires":[["4d92d940177b6ee3","d0c969b6a59fac3a","639da01fc957e547"]]},{"id":"61797eccf2785257","type":"inject","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Get Base Folder Structure","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":"0.3","topic":"","payload":"","payloadType":"date","x":280,"y":280,"wires":[["6b17b2da2b942bb4"]]},{"id":"4d92d940177b6ee3","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Simulation Folder","rules":[{"t":"set","p":"Objects.Simulation.nodeId","pt":"flow","to":"payload[2].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[2].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":220,"wires":[["335878527020598c"]]},{"id":"68a113d5893b7c01","type":"comment","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Display on Dashboard","info":"","x":1140,"y":180,"wires":[]},{"id":"d0c969b6a59fac3a","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"MyObjects Folder","rules":[{"t":"set","p":"Objects.MyObjects.nodeId","pt":"flow","to":"payload[4].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[4].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":340,"wires":[["52dd2e5dcddad58f"]]},{"id":"639da01fc957e547","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"StaticData Folder","rules":[{"t":"set","p":"Objects.StaticData.nodeId","pt":"flow","to":"payload[3].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[3].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":280,"wires":[["7b208f2e8cba6205"]]},{"id":"29437ca7222d9a64","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"ca62be3e01388319","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":550,"y":440,"wires":[["49040d0cf1144f0a","e7c55f412ef86543"]]},{"id":"49983d5da0958bf2","type":"inject","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Get StaticData Folder Structure","props":[{"p":"payload"},{"p":"topic","v":"Objects.StaticData.nodeId","vt":"flow"}],"repeat":"","crontab":"","once":true,"onceDelay":"0.3","topic":"","payload":"","payloadType":"date","x":270,"y":440,"wires":[["29437ca7222d9a64"]]},{"id":"49040d0cf1144f0a","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"AnalogItemArrays Folder","rules":[{"t":"set","p":"Objects.StaticData.AnalogItemArrays.nodeId","pt":"flow","to":"payload[1].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[1].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":850,"y":460,"wires":[["157322c9c360446d"]]},{"id":"e7c55f412ef86543","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"StaticArrayVariables Folder","rules":[{"t":"set","p":"Objects.StaticData.StaticArrayVariables.nodeId","pt":"flow","to":"payload[6].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[6].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":860,"y":400,"wires":[["a5acdccfd2033aec"]]},{"id":"de21b7ad98a05833","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"MyDevice Object","rules":[{"t":"set","p":"Objects.MyObjects.MyDevice.nodeId","pt":"flow","to":"payload[0].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[0].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":520,"wires":[["78a012e5db377fd9"]]},{"id":"2d56e9a431c21a3b","type":"inject","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Get MyObjects Object Structure","props":[{"p":"payload"},{"p":"topic","v":"Objects.MyObjects.nodeId","vt":"flow"}],"repeat":"","crontab":"","once":true,"onceDelay":"0.5","topic":"","payload":"","payloadType":"date","x":270,"y":520,"wires":[["ac95bd0e2b304eec"]]},{"id":"ac95bd0e2b304eec","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"ca62be3e01388319","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":550,"y":520,"wires":[["de21b7ad98a05833"]]},{"id":"6fdabcc2950ccf4e","type":"comment","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Store & Parse nodeId & browseName","info":"","x":850,"y":180,"wires":[]},{"id":"1c49fa5142d2cf17","type":"comment","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Global Address Space Folder Browse","info":"","x":410,"y":220,"wires":[]},{"id":"335878527020598c","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"Simulation","order":1,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"inline-content\">\n        <p>Namespace 3</p>\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1110,"y":220,"wires":[[]]},{"id":"7b208f2e8cba6205","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"StaticData","order":2,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"inline-content\">\n        <p>Namespace 5</p>\n        <v-icon color=\"black\" icon=\"mdi-folder-arrow-down\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1110,"y":280,"wires":[[]]},{"id":"52dd2e5dcddad58f","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"MyObjects","order":5,"width":0,"height":0,"head":"","format":"<template>\n    <p>Namespace 6</p>\n    <div class=\"inline-content\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1110,"y":340,"wires":[[]]},{"id":"a5acdccfd2033aec","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"StaticArrayVariables","order":3,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"d-flex align-center ml-3\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1140,"y":400,"wires":[[]]},{"id":"157322c9c360446d","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"AnalogItemArrays","order":4,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"d-flex align-center ml-3\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1130,"y":460,"wires":[[]]},{"id":"78a012e5db377fd9","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"MyDevice","order":6,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"d-flex align-center ml-3\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1100,"y":520,"wires":[[]]},{"id":"53f4394dbf12c6b7","type":"OpcUa-Endpoint","endpoint":"opc.tcp://192.168.56.1:53530/OPCUA/SimulationServer","secpol":"None","secmode":"None","none":true,"login":false,"usercert":false,"usercertificate":"","userprivatekey":""},{"id":"ef9998baf5f61e8a","type":"ui-group","name":" Address Space Folder Structure","page":"44d3feb2a1143d7b","width":"2","height":"1","order":1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"44d3feb2a1143d7b","type":"ui-page","name":"OPC UA","ui":"5355e0c476f9da3b","path":"/opcua","icon":"home","layout":"grid","theme":"61eee6fc60281b9b","order":1,"className":"","visible":"true","disabled":"false"},{"id":"5355e0c476f9da3b","type":"ui-base","name":"My Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"navigationStyle":"default"},{"id":"61eee6fc60281b9b","type":"ui-theme","name":"Default Theme","colors":{"surface":"#0094ce","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
```
::

To understand what is going on in this flow, we must refer back to the OPC UA Simulation Server `Address Space` tab.

When we browse the OPC Server base folder structure in Node-RED, we will be browsing everything included under the `Objects` tree.

![address-space.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/address-space.png){dataZoomable=""}
In our flow, we get the base folder structure by using an OPC-UA Browser node, as shown, with an endpoint that points to our OPC UA Server endpoint url we grabbed earlier in this article. It is also worth noting we leave the `Topic` blank. By doing this, we will browse the entire folder structure by default.

![image-20230727-090252.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/image-20230727-090252.png){dataZoomable=""}
The configuration of the endpoint properties includes no security credentials, as shown below.

![endpoint-configure.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/endpoint-configure.png){dataZoomable=""}

Using the output of a debug node, we get from the OPC UA Browser yield a payload with an array of 5 objects.

![address-debug.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/address-debug.png){dataZoomable=""}

Each object returned represents the 5 objects that are in our OPC UA Server Objects tree.

![browse-payload-1.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/browse-payload-1.png){dataZoomable=""}

However, of those 5 objects, only 3 of them are folders that contain actual OPC values. `MyObjects`, `Simulation`, and `StaticData`. We can ignore `Aliases` and `Server`.

![address-space-folders-only.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/address-space-folders-only.png){dataZoomable=""}

So looking deeper into the payload of our global browse from the `OPC UA Browser node`, we can drill down into the details and see how they correlate with the folders in the server.

![browse-node.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/browse-node.png){dataZoomable=""}

As shown above, element 2 in the array returned from the global browse corresponds to the `Simulation` folder. And we are interested in two important values in this data-structure - the `NodeId`, which is topic an OPC Client uses to point specific OPC values, and the `browseName`, which is the name we see visually when we try to identify an OPC topic. We can now use this logic to parse out this useful information using a change node.

![simulation-folder.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/simulation-folder.png){dataZoomable=""}
This change node is grabbing the `nodeId` and `browseName` . The `nodeId` is stored in a context variable for later use, while the `browseName` is used as the payload to be displayed on our dashboard.

The rest of the flow follows this same pattern, to end up with a folder structure that we can display on our dashboard that matches the structure on our OPC Server

- note - to make the flow more manageable, not all browsable folders were included in the dashboard, as this flow is just meant to serve as an example, rather than be a 1:1 copy of everything in the server.

If you deploy the flow and pull up the dashboard, it results in the following output -

![address-space-dashboard.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/address-space-dashboard.png){dataZoomable=""}
Showing side-by-side with the server, you can see that we successfully browsed a portion of the address space and displayed the values on the dashboard. Admittedly, a lot of work for not much pay-off, but it’s a worthwhile exercise in understanding how to browse topics using the `OPC UA Browser` node. The browser node is best used for reading OPC UA values, which will be covered next.

## Read OPC UA Values Using OPC UA Browser Node

The next set of flows read OPC UA values from the server and displays them on the dashboard.

![read-opc-values.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/read-opc-values.png){dataZoomable=""}
You can import these flows into Node-RED using the code below:

::render-flow
```json
[{"id":"ca62be3e01388319","type":"group","z":"5b972161c4e0464e","name":"Browse Hierarchical Address Space Structure & Display on Dashboard","style":{"label":true,"color":"#000000"},"nodes":["6b17b2da2b942bb4","61797eccf2785257","4d92d940177b6ee3","68a113d5893b7c01","d0c969b6a59fac3a","639da01fc957e547","29437ca7222d9a64","49983d5da0958bf2","49040d0cf1144f0a","e7c55f412ef86543","de21b7ad98a05833","2d56e9a431c21a3b","ac95bd0e2b304eec","6fdabcc2950ccf4e","1c49fa5142d2cf17","335878527020598c","7b208f2e8cba6205","52dd2e5dcddad58f","a5acdccfd2033aec","157322c9c360446d","78a012e5db377fd9"],"x":94,"y":139,"w":1172,"h":422},{"id":"6b17b2da2b942bb4","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"ca62be3e01388319","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":550,"y":280,"wires":[["4d92d940177b6ee3","d0c969b6a59fac3a","639da01fc957e547"]]},{"id":"61797eccf2785257","type":"inject","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Get Base Folder Structure","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":"0.3","topic":"","payload":"","payloadType":"date","x":280,"y":280,"wires":[["6b17b2da2b942bb4"]]},{"id":"4d92d940177b6ee3","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Simulation Folder","rules":[{"t":"set","p":"Objects.Simulation.nodeId","pt":"flow","to":"payload[2].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[2].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":220,"wires":[["335878527020598c"]]},{"id":"68a113d5893b7c01","type":"comment","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Display on Dashboard","info":"","x":1140,"y":180,"wires":[]},{"id":"d0c969b6a59fac3a","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"MyObjects Folder","rules":[{"t":"set","p":"Objects.MyObjects.nodeId","pt":"flow","to":"payload[4].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[4].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":340,"wires":[["52dd2e5dcddad58f"]]},{"id":"639da01fc957e547","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"StaticData Folder","rules":[{"t":"set","p":"Objects.StaticData.nodeId","pt":"flow","to":"payload[3].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[3].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":280,"wires":[["7b208f2e8cba6205"]]},{"id":"29437ca7222d9a64","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"ca62be3e01388319","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":550,"y":440,"wires":[["49040d0cf1144f0a","e7c55f412ef86543"]]},{"id":"49983d5da0958bf2","type":"inject","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Get StaticData Folder Structure","props":[{"p":"payload"},{"p":"topic","v":"Objects.StaticData.nodeId","vt":"flow"}],"repeat":"","crontab":"","once":true,"onceDelay":"0.3","topic":"","payload":"","payloadType":"date","x":270,"y":440,"wires":[["29437ca7222d9a64"]]},{"id":"49040d0cf1144f0a","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"AnalogItemArrays Folder","rules":[{"t":"set","p":"Objects.StaticData.AnalogItemArrays.nodeId","pt":"flow","to":"payload[1].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[1].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":850,"y":460,"wires":[["157322c9c360446d"]]},{"id":"e7c55f412ef86543","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"StaticArrayVariables Folder","rules":[{"t":"set","p":"Objects.StaticData.StaticArrayVariables.nodeId","pt":"flow","to":"payload[6].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[6].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":860,"y":400,"wires":[["a5acdccfd2033aec"]]},{"id":"de21b7ad98a05833","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"MyDevice Object","rules":[{"t":"set","p":"Objects.MyObjects.MyDevice.nodeId","pt":"flow","to":"payload[0].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[0].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":520,"wires":[["78a012e5db377fd9"]]},{"id":"2d56e9a431c21a3b","type":"inject","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Get MyObjects Object Structure","props":[{"p":"payload"},{"p":"topic","v":"Objects.MyObjects.nodeId","vt":"flow"}],"repeat":"","crontab":"","once":true,"onceDelay":"0.5","topic":"","payload":"","payloadType":"date","x":270,"y":520,"wires":[["ac95bd0e2b304eec"]]},{"id":"ac95bd0e2b304eec","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"ca62be3e01388319","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":550,"y":520,"wires":[["de21b7ad98a05833"]]},{"id":"6fdabcc2950ccf4e","type":"comment","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Store & Parse nodeId & browseName","info":"","x":850,"y":180,"wires":[]},{"id":"1c49fa5142d2cf17","type":"comment","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Global Address Space Folder Browse","info":"","x":410,"y":220,"wires":[]},{"id":"335878527020598c","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"Simulation","order":1,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"inline-content\">\n        <p>Namespace 3</p>\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1110,"y":220,"wires":[[]]},{"id":"7b208f2e8cba6205","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"StaticData","order":2,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"inline-content\">\n        <p>Namespace 5</p>\n        <v-icon color=\"black\" icon=\"mdi-folder-arrow-down\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1110,"y":280,"wires":[[]]},{"id":"52dd2e5dcddad58f","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"MyObjects","order":5,"width":0,"height":0,"head":"","format":"<template>\n    <p>Namespace 6</p>\n    <div class=\"inline-content\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1110,"y":340,"wires":[[]]},{"id":"a5acdccfd2033aec","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"StaticArrayVariables","order":3,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"d-flex align-center ml-3\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1140,"y":400,"wires":[[]]},{"id":"157322c9c360446d","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"AnalogItemArrays","order":4,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"d-flex align-center ml-3\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1130,"y":460,"wires":[[]]},{"id":"78a012e5db377fd9","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"MyDevice","order":6,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"d-flex align-center ml-3\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1100,"y":520,"wires":[[]]},{"id":"53f4394dbf12c6b7","type":"OpcUa-Endpoint","endpoint":"opc.tcp://192.168.56.1:53530/OPCUA/SimulationServer","secpol":"None","secmode":"None","none":true,"login":false,"usercert":false,"usercertificate":"","userprivatekey":""},{"id":"ef9998baf5f61e8a","type":"ui-group","name":" Address Space Folder Structure","page":"44d3feb2a1143d7b","width":"2","height":"1","order":1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"44d3feb2a1143d7b","type":"ui-page","name":"OPC UA","ui":"5355e0c476f9da3b","path":"/opcua","icon":"home","layout":"grid","theme":"61eee6fc60281b9b","order":1,"className":"","visible":"true","disabled":"false"},{"id":"5355e0c476f9da3b","type":"ui-base","name":"My Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"navigationStyle":"default"},{"id":"61eee6fc60281b9b","type":"ui-theme","name":"Default Theme","colors":{"surface":"#0094ce","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"8557072f05e4bda0","type":"group","z":"5b972161c4e0464e","name":"Read Simulation Values & Display on Dashboard","style":{"label":true,"color":"#000000"},"nodes":["9659d40ac9063764","9f5b597ec8179fb4","a8d919f497fcff04","13f5c98b7fd5f5da","ec5dca5eb9d4971b","1780cb86597d3c67","1a2fcac87247cda4","4d9b758e39555124","da468bc150517fa6","82aa12173dd7bbca","57d8777e34b55b7b","10877909d1daf6fe","c4d4a3b0df372e4c","b0cf511f824f2a86","f2efc6b419414c9a"],"x":94,"y":599,"w":1372,"h":302},{"id":"9659d40ac9063764","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"8557072f05e4bda0","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":570,"y":760,"wires":[["ec5dca5eb9d4971b"]]},{"id":"9f5b597ec8179fb4","type":"inject","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Update Simulation Values @ 1 second","props":[{"p":"payload"},{"p":"topic","v":"Objects.Simulation.nodeId","vt":"flow"}],"repeat":"1","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":300,"y":760,"wires":[["9659d40ac9063764"]]},{"id":"a8d919f497fcff04","type":"comment","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Read Simulation Values","info":"","x":460,"y":720,"wires":[]},{"id":"13f5c98b7fd5f5da","type":"change","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Get Counter Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[1].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1070,"y":680,"wires":[["10877909d1daf6fe"]]},{"id":"ec5dca5eb9d4971b","type":"switch","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"empty check","property":"payload","propertyType":"msg","rules":[{"t":"nempty"}],"checkall":"true","repair":false,"outputs":1,"x":790,"y":760,"wires":[["13f5c98b7fd5f5da","1780cb86597d3c67","1a2fcac87247cda4","4d9b758e39555124"]]},{"id":"1780cb86597d3c67","type":"change","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Get Random Number Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[2].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1100,"y":740,"wires":[["c4d4a3b0df372e4c"]]},{"id":"1a2fcac87247cda4","type":"change","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Get Sawtooth Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[3].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1080,"y":800,"wires":[["b0cf511f824f2a86"]]},{"id":"4d9b758e39555124","type":"change","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Get Sawtooth Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[4].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1080,"y":860,"wires":[["f2efc6b419414c9a"]]},{"id":"da468bc150517fa6","type":"comment","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Discard Empty Datasets","info":"","x":780,"y":720,"wires":[]},{"id":"82aa12173dd7bbca","type":"comment","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Parse Simulation Values","info":"","x":1070,"y":640,"wires":[]},{"id":"57d8777e34b55b7b","type":"comment","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Display on Dashboard","info":"","x":1340,"y":640,"wires":[]},{"id":"10877909d1daf6fe","type":"ui-gauge","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Counter","group":"af263064820fb7d0","order":0,"width":3,"height":3,"gtype":"gauge-half","gstyle":"needle","title":"gauge","units":"units","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#5cd65c"},{"from":"15","color":"#ffc800"},{"from":"30","color":"#ea5353"}],"min":0,"max":"30","sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":1320,"y":680,"wires":[]},{"id":"c4d4a3b0df372e4c","type":"ui-text","z":"5b972161c4e0464e","g":"8557072f05e4bda0","group":"af263064820fb7d0","order":0,"width":0,"height":0,"name":"Random Number","label":"Random Number","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1350,"y":740,"wires":[]},{"id":"b0cf511f824f2a86","type":"ui-chart","z":"5b972161c4e0464e","g":"8557072f05e4bda0","group":"af263064820fb7d0","name":"","label":"Sawtooth","order":9007199254740991,"chartType":"line","category":"Sawtooth","categoryType":"str","xAxisProperty":"","xAxisPropertyType":"msg","xAxisType":"time","yAxisProperty":"","ymin":"","ymax":"","action":"append","pointShape":"line","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"60","removeOlderPoints":"","colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"width":"3","height":"4","className":"","x":1320,"y":800,"wires":[[]]},{"id":"f2efc6b419414c9a","type":"ui-chart","z":"5b972161c4e0464e","g":"8557072f05e4bda0","group":"af263064820fb7d0","name":"","label":"Sinusoid","order":9007199254740991,"chartType":"line","category":"Sawtooth","categoryType":"str","xAxisProperty":"","xAxisPropertyType":"msg","xAxisType":"time","yAxisProperty":"","ymin":"","ymax":"","action":"append","pointShape":"line","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"60","removeOlderPoints":"","colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"width":"3","height":"4","className":"","x":1320,"y":860,"wires":[[]]},{"id":"af263064820fb7d0","type":"ui-group","name":"Simulation values","page":"44d3feb2a1143d7b","width":"3","height":"1","order":2,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"5afdbddf71507886","type":"group","z":"5b972161c4e0464e","name":"Read StaticData Values & Display on Dashboard","style":{"label":true,"color":"#000000"},"nodes":["e998aa804042128b","6c9b7d4d195a1e9a","cd097b744d0ec625","18d21607c87ab153","7b5143c4960f92a1","0625b0cf6f546a4a","9d899fbb4d1648b3","6e1edc31687dde54","051e1f282076fed2","de2a1c3e380f743b","c74606c48ccf5a40","053bda13f2a2eabe","277dcf430dc86996","d708e6264cec0070"],"x":84,"y":939,"w":1382,"h":202},{"id":"e998aa804042128b","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"5afdbddf71507886","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":630,"y":1020,"wires":[["7b5143c4960f92a1"]]},{"id":"6c9b7d4d195a1e9a","type":"inject","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Update AnalogItemArrays Values @ 1 second","props":[{"p":"payload"},{"p":"topic","v":"Objects.StaticData.AnalogItemArrays.nodeId","vt":"flow"}],"repeat":"1","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":320,"y":1020,"wires":[["e998aa804042128b"]]},{"id":"cd097b744d0ec625","type":"comment","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Read StaticData Values","info":"","x":520,"y":980,"wires":[]},{"id":"18d21607c87ab153","type":"change","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Get ByteAnalogItemArray Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"$string(payload[0].item.value)\t","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":1070,"y":1020,"wires":[["277dcf430dc86996"]]},{"id":"7b5143c4960f92a1","type":"switch","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"empty check","property":"payload","propertyType":"msg","rules":[{"t":"nempty"}],"checkall":"true","repair":false,"outputs":1,"x":830,"y":1020,"wires":[["18d21607c87ab153"]]},{"id":"0625b0cf6f546a4a","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"5afdbddf71507886","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":630,"y":1100,"wires":[["051e1f282076fed2"]]},{"id":"9d899fbb4d1648b3","type":"inject","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Update StaticArrayVariables Values @1 second","props":[{"p":"payload"},{"p":"topic","v":"Objects.StaticData.StaticArrayVariables.nodeId","vt":"flow"}],"repeat":"1","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":320,"y":1100,"wires":[["0625b0cf6f546a4a"]]},{"id":"6e1edc31687dde54","type":"change","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Get BooleanArray Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[0].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1050,"y":1100,"wires":[["d708e6264cec0070"]]},{"id":"051e1f282076fed2","type":"switch","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"empty check","property":"payload","propertyType":"msg","rules":[{"t":"nempty"}],"checkall":"true","repair":false,"outputs":1,"x":830,"y":1100,"wires":[["6e1edc31687dde54"]]},{"id":"de2a1c3e380f743b","type":"comment","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Discard Empty Datasets","info":"","x":820,"y":980,"wires":[]},{"id":"c74606c48ccf5a40","type":"comment","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Parse StaticData Values","info":"","x":1070,"y":980,"wires":[]},{"id":"053bda13f2a2eabe","type":"comment","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Display on Dashboard","info":"","x":1340,"y":980,"wires":[]},{"id":"277dcf430dc86996","type":"ui-text","z":"5b972161c4e0464e","g":"5afdbddf71507886","group":"3d4f386e812e8b5f","order":0,"width":0,"height":0,"name":"","label":"ByteAnalogItemArray","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1340,"y":1020,"wires":[]},{"id":"d708e6264cec0070","type":"ui-text","z":"5b972161c4e0464e","g":"5afdbddf71507886","group":"3d4f386e812e8b5f","order":0,"width":0,"height":0,"name":"","label":"BooleanArray","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1320,"y":1100,"wires":[]},{"id":"3d4f386e812e8b5f","type":"ui-group","name":"StaticData Values","page":"44d3feb2a1143d7b","width":"4","height":"1","order":3,"showTitle":true,"className":"","visible":"true","disabled":"false"}]
```
::

The values are derived from the `nodeId` values we stored in memory in our previous flow, via our `change` nodes in the previous flow.

![flow-context-nodeid.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/flow-context-nodeid.png){dataZoomable=""}
As stated earlier, you reference a OPC UA topic by its `nodeId`. So we will use these node IDs to read actual values from our OPC nodes.

In our first flow, we want to read the values in the `Simulation` folder at a 1 second interval. So we use an `inject` node with a `msg.topic` that references the `nodeId` corresponding to the `Simulation` folder.

![simulation-injection.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/simulation-injection.png){dataZoomable=""}
That `msg.topic` tells the `OPC UA Browser` node what `nodeId` to browse. If we look at the debug output of the browser `msg.payload`, we can see that it produces an array of 7 objects, and an empty set array.

![simulation-debug.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/simulation-debug.png){dataZoomable=""}
If we allow that empty array to be passed, that means all values will be reset to 0 on each read. So to prevent that from happening, we use a `switch` node to filter out the empty set.

![empty-check.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/empty-check.png){dataZoomable=""}
Now only non-empty payloads will be passed, preventing the values being reset to 0 on each read.

Now we can actually read the values. To do this, we use a `change` node again, referencing the non-empty payload and drilling down to the `value` that corresponds to the `name` of the node we want to read. In this case, we’re getting the value of the node `Counter` located in the `Simulation` folder.

![get-counter-value.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/get-counter-value.png){dataZoomable=""}
Going back to our OPC Server, we can see that exactly where that value is derived below -

![sim-counter-server.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/sim-counter-server.png){dataZoomable=""}

Now we add a `gauge` dashboard node to visualize the counter on the dashboard. In the OPC Server, it is shown that the counter increments in a range of 0-30 in 1 count increments.

![counter-properties.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/counter-propertie.png){dataZoomable=""}
Now that we’ve gone through the full process of reading an OPC UA value and displaying it on the dashboard, we can apply the same logic other values published by the OPC UA Server, which are repeated in the remaining parts of the flow.

The end result on the dashboard now looks like this -

:video{ariaLabel="Video showing the OPC UA dashboard reading live values from the server" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

## Write OPC UA Values To Server Using OpcUa-Item and Opc-Ua-Client Nodes

The next flow writes OPC UA values to the server using dashboard UI elements.

![write-mydevice.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/write-mydevice.png){dataZoomable=""}
You can import this flow into Node-RED using the code below:

::render-flow
```json
[{"id":"3de6c861611c3afa","type":"group","z":"5b972161c4e0464e","name":"Write Mydevices values to OPC UA Server","style":{"label":true,"color":"#000000"},"nodes":["a66583d91b581cd8","3e8cb6e199012155","9fa33d1c9c621611","fb7f57b4da5883ae","9c5ff104eb9c8b10","77bcb828bec95336","afa83dbb46449d4a","fa08f0ed04296363","9f591797b56c565d"],"x":94,"y":1439,"w":792,"h":182},{"id":"a66583d91b581cd8","type":"OpcUa-Item","z":"5b972161c4e0464e","g":"3de6c861611c3afa","item":"ns=6;s=MySwitch","datatype":"Boolean","value":"","name":"Toggle MySwitch","x":470,"y":1520,"wires":[["3e8cb6e199012155"]]},{"id":"3e8cb6e199012155","type":"OpcUa-Client","z":"5b972161c4e0464e","g":"3de6c861611c3afa","endpoint":"53f4394dbf12c6b7","action":"write","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"name":"Write MySwitch","x":720,"y":1520,"wires":[[],[]]},{"id":"9fa33d1c9c621611","type":"comment","z":"5b972161c4e0464e","g":"3de6c861611c3afa","name":"Dashboard Input","info":"","x":200,"y":1480,"wires":[]},{"id":"fb7f57b4da5883ae","type":"OpcUa-Item","z":"5b972161c4e0464e","g":"3de6c861611c3afa","item":"ns=6;s=MyLevel","datatype":"Double","value":"","name":"Modify MyLevel","x":460,"y":1580,"wires":[["9c5ff104eb9c8b10"]]},{"id":"9c5ff104eb9c8b10","type":"OpcUa-Client","z":"5b972161c4e0464e","g":"3de6c861611c3afa","endpoint":"53f4394dbf12c6b7","action":"write","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"name":"Write MyLevel","x":720,"y":1580,"wires":[[],[]]},{"id":"77bcb828bec95336","type":"comment","z":"5b972161c4e0464e","g":"3de6c861611c3afa","name":"Call OPC UA Item","info":"","x":470,"y":1480,"wires":[]},{"id":"afa83dbb46449d4a","type":"comment","z":"5b972161c4e0464e","g":"3de6c861611c3afa","name":"Write OPC UA Item to Client","info":"","x":740,"y":1480,"wires":[]},{"id":"fa08f0ed04296363","type":"ui-switch","z":"5b972161c4e0464e","g":"3de6c861611c3afa","name":"","label":"Toggle MySwitch","group":"ec0ecb26fde8db3e","order":0,"width":0,"height":0,"passthru":false,"topic":"topic","topicType":"msg","style":"","className":"","onvalue":"true","onvalueType":"bool","onicon":"","oncolor":"","offvalue":"false","offvalueType":"bool","officon":"","offcolor":"","x":210,"y":1520,"wires":[["a66583d91b581cd8"]]},{"id":"9f591797b56c565d","type":"ui-slider","z":"5b972161c4e0464e","g":"3de6c861611c3afa","group":"ec0ecb26fde8db3e","name":"","label":"Modify MyLevel","tooltip":"","order":0,"width":0,"height":0,"passthru":false,"outs":"all","topic":"topic","topicType":"msg","thumbLabel":true,"min":"0","max":"100","step":1,"className":"","x":200,"y":1580,"wires":[["fb7f57b4da5883ae"]]},{"id":"53f4394dbf12c6b7","type":"OpcUa-Endpoint","endpoint":"opc.tcp://192.168.56.1:53530/OPCUA/SimulationServer","secpol":"None","secmode":"None","none":true,"login":false,"usercert":false,"usercertificate":"","userprivatekey":""},{"id":"ec0ecb26fde8db3e","type":"ui-group","name":"MyDevice Status & Control","page":"44d3feb2a1143d7b","width":"3","height":"1","order":4,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"44d3feb2a1143d7b","type":"ui-page","name":"OPC UA","ui":"5355e0c476f9da3b","path":"/opcua","icon":"home","layout":"grid","theme":"61eee6fc60281b9b","order":1,"className":"","visible":"true","disabled":"false"},{"id":"5355e0c476f9da3b","type":"ui-base","name":"My Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"navigationStyle":"default"},{"id":"61eee6fc60281b9b","type":"ui-theme","name":"Default Theme","colors":{"surface":"#0094ce","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
```
::

We have two values to write, a boolean value corresponding to the node object `MySwitch`, and an integer value corresponding to the object `MyLevel`. Therefore, we will use a toggle switch to toggle the `MySwitch`, and a slider to modify `MyLevel`.

There’s no need to modify the toggle switch properties, other than giving it a name. The slider needs to have the range modified to match the range of the level, which is 0-100%.

![level-range.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/level-range.png){dataZoomable=""}
For the `OpcUa-Item` nodes, copy the `NodeId` corresponding to each device,

![copy-node-id.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/copy-node-id.png){dataZoomable=""}
and paste it into `OpcUa-Item` node. You must also ensure the data-type matches with the value you’re writing to.

![opcua-item.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/opcua-item.png){dataZoomable=""}
The `Opc-Ua-Client` needs to have an endpoint and the action changed to `WRITE`.

![client-node.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/client-node.png){dataZoomable=""}
The process is the same for `MySwitch` and `MyLevel`, the only difference being what `NodeId` is referenced in the `OpcUa-Item` node.

When deployed, you can confirm values are being written to from the client to the server from the dashboard.

:video{ariaLabel="Video showing values being written from the client to the server on the dashboard" autoPlay="true" height="390" loop="true" muted="true" playsInline="true" preload="none" width="800"}

## Read Alarms & Events from OPC UA Server Using OpcUa-Event and Opc-Ua-Client Nodes

Our last flow we’ll show how to read OPC UA Alarms & Events.

![opc-event-flow.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/opc-event-flow.png){dataZoomable=""}
You can import this flow into Node-RED using the code below:

::render-flow
```json
[{"id":"a6e9abacd0bdf3b6","type":"group","z":"5b972161c4e0464e","name":"Read Alarms & Events From OPC UA Server","style":{"label":true,"color":"#000000"},"nodes":["90fb4ca64a642edf","b76f64786bc681c3","71e24b671bc03fb8","c7438df35b506470","c7e8919b636cb51d","5952b86dae22b056","04992b24a3836f19","325068cb935cd6d1","5b4d1bd8b342fc05","ba1ea89438335cb8","d662d662c5ccb9c1","1e3956200997581f","0b8ac86e5e4f9f8d","62b2e14ce0429eef"],"x":94,"y":1679,"w":1352,"h":282},{"id":"90fb4ca64a642edf","type":"comment","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Call OPC UA Item","info":"","x":470,"y":1820,"wires":[]},{"id":"b76f64786bc681c3","type":"OpcUa-Event","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","root":"ns=6;s=MyLevel.Alarm","activatecustomevent":false,"eventtype":"i=2041","customeventtype":"","name":"MyLevel Alarms","x":500,"y":1860,"wires":[["c7438df35b506470"]]},{"id":"71e24b671bc03fb8","type":"inject","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Trigger Alarm Event Capture","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":260,"y":1860,"wires":[["b76f64786bc681c3"]]},{"id":"c7438df35b506470","type":"OpcUa-Client","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","endpoint":"53f4394dbf12c6b7","action":"events","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"name":"Get MyLevel Events","x":720,"y":1860,"wires":[["c7e8919b636cb51d","5952b86dae22b056","04992b24a3836f19"],[]]},{"id":"c7e8919b636cb51d","type":"change","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Event Text","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.Message.text","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":990,"y":1800,"wires":[["d662d662c5ccb9c1","1e3956200997581f"]]},{"id":"5952b86dae22b056","type":"change","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Event Time","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.Time","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":990,"y":1860,"wires":[["0b8ac86e5e4f9f8d"]]},{"id":"04992b24a3836f19","type":"change","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Event Severity","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.Severity","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1000,"y":1920,"wires":[["62b2e14ce0429eef"]]},{"id":"325068cb935cd6d1","type":"comment","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Parse Event Dataset","info":"","x":990,"y":1760,"wires":[]},{"id":"5b4d1bd8b342fc05","type":"comment","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Get OPC Events from Client","info":"","x":720,"y":1820,"wires":[]},{"id":"ba1ea89438335cb8","type":"comment","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Display Events on Dashboard","info":"","x":1240,"y":1720,"wires":[]},{"id":"d662d662c5ccb9c1","type":"ui-notification","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","ui":"5355e0c476f9da3b","position":"center center","colorDefault":true,"color":"#000000","displayTime":"3","showCountdown":true,"outputs":1,"allowDismiss":true,"dismissText":"Close","raw":false,"className":"","name":"Event Notification","x":1230,"y":1800,"wires":[[]]},{"id":"1e3956200997581f","type":"ui-text","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","group":"ec0ecb26fde8db3e","order":0,"width":0,"height":0,"name":"","label":"Latest MyLevel Event","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1240,"y":1840,"wires":[]},{"id":"0b8ac86e5e4f9f8d","type":"ui-text","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","group":"ec0ecb26fde8db3e","order":0,"width":0,"height":0,"name":"","label":"Latest MyLevel Event Timestamp","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1280,"y":1880,"wires":[]},{"id":"62b2e14ce0429eef","type":"ui-text","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","group":"ec0ecb26fde8db3e","order":0,"width":0,"height":0,"name":"","label":"Latest MyLevel Event Severity","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1270,"y":1920,"wires":[]},{"id":"53f4394dbf12c6b7","type":"OpcUa-Endpoint","endpoint":"opc.tcp://192.168.56.1:53530/OPCUA/SimulationServer","secpol":"None","secmode":"None","none":true,"login":false,"usercert":false,"usercertificate":"","userprivatekey":""},{"id":"5355e0c476f9da3b","type":"ui-base","name":"My Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"navigationStyle":"default"},{"id":"ec0ecb26fde8db3e","type":"ui-group","name":"MyDevice Status & Control","page":"44d3feb2a1143d7b","width":"3","height":"1","order":4,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"44d3feb2a1143d7b","type":"ui-page","name":"OPC UA","ui":"5355e0c476f9da3b","path":"/opcua","icon":"home","layout":"grid","theme":"61eee6fc60281b9b","order":1,"className":"","visible":"true","disabled":"false"},{"id":"61eee6fc60281b9b","type":"ui-theme","name":"Default Theme","colors":{"surface":"#0094ce","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
```
::

We use an inject node to trigger the `OpcUa-Event` node. In the properties of the event node, we get the `NodeId` from the `MyLevelAlarm` event from the OPC Server -

![mylevel-event.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/mylevel-event.png){dataZoomable=""}
And copy that `NodeId` into the `OpcUa-Event` node. Event type will be `BaseEvent (all)`.

![event-node-properties.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/event-node-properties.png){dataZoomable=""}
In the `Opc-Ua-Client` node, we set the `Action` to `EVENTS`.

![client-events.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/client-events.png){dataZoomable=""}
If we stick a debug node on the output of the client event, we can see how the OPC Server annunciates events.

![event-debug.png](https://flowfuse.com/blog/2023/07/images/opc-ua-3/event-debug.png){dataZoomable=""}
Every time `MyLevel` exceeds certain thresholds (10%, 30%, 70% and 90%) it will flag a `Level Exceeded` alarm. The event is timestamped and assigned a severity level, which we will record and put onto the dashboard.

To make things simple, we’ll only track the last event. But in a production system, you’d likely want to store these events in a relational database (historian) to keep an alarm history. We’ll also include a notification pop-up when an alarm occurs to notify someone monitoring the dashboard a new alarm has occurred.

Adding alarms and events to our dashboard creates the following result -

:video{ariaLabel="Video showing alarms and events displayed on the dashboard" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

## Using FlowFuse to Enhance Your Node-RED Application: Security, Scalability, and Robustness

So, you've successfully built your Node-RED application, congratulations! But now, how do you ensure its security, scalability, and ease of collaboration? What if you want to invite your team to work on the application simultaneously or access it remotely?

Enter [FlowFuse](https://flowfuse.com), a cloud-based platform designed to add production-grade features to your Node-RED applications. With FlowFuse, you can seamlessly integrate advanced security measures, scale your application as needed, and collaborate effortlessly with your team. It simplifies management and deployment, turning your Node-RED project into a robust, scalable solution.

If you're interested in learning how to use Node-RED for professional use cases, check out our eBook: [Ultimate Beginner's Guide to Professionals](https://flowfuse.com/ebooks/beginner-guide-to-a-professional-nodered/). For additional resources, visit our [Node-RED Learning Resources section](https://flowfuse.com/node-red/core-nodes/), where you can explore integrations with different protocols, messaging services, databases, hardware, and much more.

## Conclusion

In this final article, we went over building a OPC UA Client dashboard that can browse the address space, read values from an OPC Server, write values to an OPC Server, and get events from an OPC Server.

This flow provides examples that can serve as a foundation for an interactive OPC Client application built in Node-RED. This now concludes the OPC UA Series.

full source code for this project -

::render-flow
```json
[{"id":"ca62be3e01388319","type":"group","z":"5b972161c4e0464e","name":"Browse Hierarchical Address Space Structure & Display on Dashboard","style":{"label":true,"color":"#000000"},"nodes":["6b17b2da2b942bb4","61797eccf2785257","4d92d940177b6ee3","68a113d5893b7c01","d0c969b6a59fac3a","639da01fc957e547","29437ca7222d9a64","49983d5da0958bf2","49040d0cf1144f0a","e7c55f412ef86543","de21b7ad98a05833","2d56e9a431c21a3b","ac95bd0e2b304eec","6fdabcc2950ccf4e","1c49fa5142d2cf17","335878527020598c","7b208f2e8cba6205","52dd2e5dcddad58f","a5acdccfd2033aec","157322c9c360446d","78a012e5db377fd9"],"x":94,"y":139,"w":1172,"h":422},{"id":"6b17b2da2b942bb4","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"ca62be3e01388319","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":550,"y":280,"wires":[["4d92d940177b6ee3","d0c969b6a59fac3a","639da01fc957e547"]]},{"id":"61797eccf2785257","type":"inject","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Get Base Folder Structure","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":"0.3","topic":"","payload":"","payloadType":"date","x":280,"y":280,"wires":[["6b17b2da2b942bb4"]]},{"id":"4d92d940177b6ee3","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Simulation Folder","rules":[{"t":"set","p":"Objects.Simulation.nodeId","pt":"flow","to":"payload[2].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[2].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":220,"wires":[["335878527020598c"]]},{"id":"68a113d5893b7c01","type":"comment","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Display on Dashboard","info":"","x":1140,"y":180,"wires":[]},{"id":"d0c969b6a59fac3a","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"MyObjects Folder","rules":[{"t":"set","p":"Objects.MyObjects.nodeId","pt":"flow","to":"payload[4].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[4].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":340,"wires":[["52dd2e5dcddad58f"]]},{"id":"639da01fc957e547","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"StaticData Folder","rules":[{"t":"set","p":"Objects.StaticData.nodeId","pt":"flow","to":"payload[3].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[3].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":280,"wires":[["7b208f2e8cba6205"]]},{"id":"29437ca7222d9a64","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"ca62be3e01388319","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":550,"y":440,"wires":[["49040d0cf1144f0a","e7c55f412ef86543"]]},{"id":"49983d5da0958bf2","type":"inject","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Get StaticData Folder Structure","props":[{"p":"payload"},{"p":"topic","v":"Objects.StaticData.nodeId","vt":"flow"}],"repeat":"","crontab":"","once":true,"onceDelay":"0.3","topic":"","payload":"","payloadType":"date","x":270,"y":440,"wires":[["29437ca7222d9a64"]]},{"id":"49040d0cf1144f0a","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"AnalogItemArrays Folder","rules":[{"t":"set","p":"Objects.StaticData.AnalogItemArrays.nodeId","pt":"flow","to":"payload[1].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[1].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":850,"y":460,"wires":[["157322c9c360446d"]]},{"id":"e7c55f412ef86543","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"StaticArrayVariables Folder","rules":[{"t":"set","p":"Objects.StaticData.StaticArrayVariables.nodeId","pt":"flow","to":"payload[6].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[6].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":860,"y":400,"wires":[["a5acdccfd2033aec"]]},{"id":"de21b7ad98a05833","type":"change","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"MyDevice Object","rules":[{"t":"set","p":"Objects.MyObjects.MyDevice.nodeId","pt":"flow","to":"payload[0].item.nodeId","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"payload[0].item.browseName.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":830,"y":520,"wires":[["78a012e5db377fd9"]]},{"id":"2d56e9a431c21a3b","type":"inject","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Get MyObjects Object Structure","props":[{"p":"payload"},{"p":"topic","v":"Objects.MyObjects.nodeId","vt":"flow"}],"repeat":"","crontab":"","once":true,"onceDelay":"0.5","topic":"","payload":"","payloadType":"date","x":270,"y":520,"wires":[["ac95bd0e2b304eec"]]},{"id":"ac95bd0e2b304eec","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"ca62be3e01388319","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":550,"y":520,"wires":[["de21b7ad98a05833"]]},{"id":"6fdabcc2950ccf4e","type":"comment","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Store & Parse nodeId & browseName","info":"","x":850,"y":180,"wires":[]},{"id":"1c49fa5142d2cf17","type":"comment","z":"5b972161c4e0464e","g":"ca62be3e01388319","name":"Global Address Space Folder Browse","info":"","x":410,"y":220,"wires":[]},{"id":"335878527020598c","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"Simulation","order":1,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"inline-content\">\n        <p>Namespace 3</p>\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1110,"y":220,"wires":[[]]},{"id":"7b208f2e8cba6205","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"StaticData","order":2,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"inline-content\">\n        <p>Namespace 5</p>\n        <v-icon color=\"black\" icon=\"mdi-folder-arrow-down\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1110,"y":280,"wires":[[]]},{"id":"52dd2e5dcddad58f","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"MyObjects","order":5,"width":0,"height":0,"head":"","format":"<template>\n    <p>Namespace 6</p>\n    <div class=\"inline-content\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1110,"y":340,"wires":[[]]},{"id":"a5acdccfd2033aec","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"StaticArrayVariables","order":3,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"d-flex align-center ml-3\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1140,"y":400,"wires":[[]]},{"id":"157322c9c360446d","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"AnalogItemArrays","order":4,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"d-flex align-center ml-3\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1130,"y":460,"wires":[[]]},{"id":"78a012e5db377fd9","type":"ui-template","z":"5b972161c4e0464e","g":"ca62be3e01388319","group":"ef9998baf5f61e8a","page":"","ui":"","name":"MyDevice","order":6,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"d-flex align-center ml-3\">\n        <v-icon color=\"black\" icon=\"mdi-folder\" size=\"large\"></v-icon> {{ msg.payload }}\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1100,"y":520,"wires":[[]]},{"id":"53f4394dbf12c6b7","type":"OpcUa-Endpoint","endpoint":"opc.tcp://192.168.56.1:53530/OPCUA/SimulationServer","secpol":"None","secmode":"None","none":true,"login":false,"usercert":false,"usercertificate":"","userprivatekey":""},{"id":"ef9998baf5f61e8a","type":"ui-group","name":" Address Space Folder Structure","page":"44d3feb2a1143d7b","width":"2","height":"1","order":1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"44d3feb2a1143d7b","type":"ui-page","name":"OPC UA","ui":"5355e0c476f9da3b","path":"/opcua","icon":"home","layout":"grid","theme":"61eee6fc60281b9b","order":1,"className":"","visible":"true","disabled":"false"},{"id":"5355e0c476f9da3b","type":"ui-base","name":"My Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"navigationStyle":"default"},{"id":"61eee6fc60281b9b","type":"ui-theme","name":"Default Theme","colors":{"surface":"#0094ce","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"8557072f05e4bda0","type":"group","z":"5b972161c4e0464e","name":"Read Simulation Values & Display on Dashboard","style":{"label":true,"color":"#000000"},"nodes":["9659d40ac9063764","9f5b597ec8179fb4","a8d919f497fcff04","13f5c98b7fd5f5da","ec5dca5eb9d4971b","1780cb86597d3c67","1a2fcac87247cda4","4d9b758e39555124","da468bc150517fa6","82aa12173dd7bbca","57d8777e34b55b7b","10877909d1daf6fe","c4d4a3b0df372e4c","b0cf511f824f2a86","f2efc6b419414c9a"],"x":94,"y":599,"w":1372,"h":302},{"id":"9659d40ac9063764","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"8557072f05e4bda0","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":570,"y":760,"wires":[["ec5dca5eb9d4971b"]]},{"id":"9f5b597ec8179fb4","type":"inject","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Update Simulation Values @ 1 second","props":[{"p":"payload"},{"p":"topic","v":"Objects.Simulation.nodeId","vt":"flow"}],"repeat":"1","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":300,"y":760,"wires":[["9659d40ac9063764"]]},{"id":"a8d919f497fcff04","type":"comment","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Read Simulation Values","info":"","x":460,"y":720,"wires":[]},{"id":"13f5c98b7fd5f5da","type":"change","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Get Counter Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[1].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1070,"y":680,"wires":[["10877909d1daf6fe"]]},{"id":"ec5dca5eb9d4971b","type":"switch","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"empty check","property":"payload","propertyType":"msg","rules":[{"t":"nempty"}],"checkall":"true","repair":false,"outputs":1,"x":790,"y":760,"wires":[["13f5c98b7fd5f5da","1780cb86597d3c67","1a2fcac87247cda4","4d9b758e39555124"]]},{"id":"1780cb86597d3c67","type":"change","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Get Random Number Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[2].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1100,"y":740,"wires":[["c4d4a3b0df372e4c"]]},{"id":"1a2fcac87247cda4","type":"change","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Get Sawtooth Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[3].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1080,"y":800,"wires":[["b0cf511f824f2a86"]]},{"id":"4d9b758e39555124","type":"change","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Get Sawtooth Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[4].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1080,"y":860,"wires":[["f2efc6b419414c9a"]]},{"id":"da468bc150517fa6","type":"comment","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Discard Empty Datasets","info":"","x":780,"y":720,"wires":[]},{"id":"82aa12173dd7bbca","type":"comment","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Parse Simulation Values","info":"","x":1070,"y":640,"wires":[]},{"id":"57d8777e34b55b7b","type":"comment","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Display on Dashboard","info":"","x":1340,"y":640,"wires":[]},{"id":"10877909d1daf6fe","type":"ui-gauge","z":"5b972161c4e0464e","g":"8557072f05e4bda0","name":"Counter","group":"af263064820fb7d0","order":0,"width":3,"height":3,"gtype":"gauge-half","gstyle":"needle","title":"gauge","units":"units","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#5cd65c"},{"from":"15","color":"#ffc800"},{"from":"30","color":"#ea5353"}],"min":0,"max":"30","sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":1320,"y":680,"wires":[]},{"id":"c4d4a3b0df372e4c","type":"ui-text","z":"5b972161c4e0464e","g":"8557072f05e4bda0","group":"af263064820fb7d0","order":0,"width":0,"height":0,"name":"Random Number","label":"Random Number","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1350,"y":740,"wires":[]},{"id":"b0cf511f824f2a86","type":"ui-chart","z":"5b972161c4e0464e","g":"8557072f05e4bda0","group":"af263064820fb7d0","name":"","label":"Sawtooth","order":9007199254740991,"chartType":"line","category":"Sawtooth","categoryType":"str","xAxisProperty":"","xAxisPropertyType":"msg","xAxisType":"time","yAxisProperty":"","ymin":"","ymax":"","action":"append","pointShape":"line","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"60","removeOlderPoints":"","colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"width":"3","height":"4","className":"","x":1320,"y":800,"wires":[[]]},{"id":"f2efc6b419414c9a","type":"ui-chart","z":"5b972161c4e0464e","g":"8557072f05e4bda0","group":"af263064820fb7d0","name":"","label":"Sinusoid","order":9007199254740991,"chartType":"line","category":"Sawtooth","categoryType":"str","xAxisProperty":"","xAxisPropertyType":"msg","xAxisType":"time","yAxisProperty":"","ymin":"","ymax":"","action":"append","pointShape":"line","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"60","removeOlderPoints":"","colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"width":"3","height":"4","className":"","x":1320,"y":860,"wires":[[]]},{"id":"af263064820fb7d0","type":"ui-group","name":"Simulation values","page":"44d3feb2a1143d7b","width":"3","height":"1","order":2,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"5afdbddf71507886","type":"group","z":"5b972161c4e0464e","name":"Read StaticData Values & Display on Dashboard","style":{"label":true,"color":"#000000"},"nodes":["e998aa804042128b","6c9b7d4d195a1e9a","cd097b744d0ec625","18d21607c87ab153","7b5143c4960f92a1","0625b0cf6f546a4a","9d899fbb4d1648b3","6e1edc31687dde54","051e1f282076fed2","de2a1c3e380f743b","c74606c48ccf5a40","053bda13f2a2eabe","277dcf430dc86996","d708e6264cec0070"],"x":84,"y":939,"w":1382,"h":202},{"id":"e998aa804042128b","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"5afdbddf71507886","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":630,"y":1020,"wires":[["7b5143c4960f92a1"]]},{"id":"6c9b7d4d195a1e9a","type":"inject","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Update AnalogItemArrays Values @ 1 second","props":[{"p":"payload"},{"p":"topic","v":"Objects.StaticData.AnalogItemArrays.nodeId","vt":"flow"}],"repeat":"1","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":320,"y":1020,"wires":[["e998aa804042128b"]]},{"id":"cd097b744d0ec625","type":"comment","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Read StaticData Values","info":"","x":520,"y":980,"wires":[]},{"id":"18d21607c87ab153","type":"change","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Get ByteAnalogItemArray Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"$string(payload[0].item.value)\t","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":1070,"y":1020,"wires":[["277dcf430dc86996"]]},{"id":"7b5143c4960f92a1","type":"switch","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"empty check","property":"payload","propertyType":"msg","rules":[{"t":"nempty"}],"checkall":"true","repair":false,"outputs":1,"x":830,"y":1020,"wires":[["18d21607c87ab153"]]},{"id":"0625b0cf6f546a4a","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"5afdbddf71507886","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":630,"y":1100,"wires":[["051e1f282076fed2"]]},{"id":"9d899fbb4d1648b3","type":"inject","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Update StaticArrayVariables Values @1 second","props":[{"p":"payload"},{"p":"topic","v":"Objects.StaticData.StaticArrayVariables.nodeId","vt":"flow"}],"repeat":"1","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":320,"y":1100,"wires":[["0625b0cf6f546a4a"]]},{"id":"6e1edc31687dde54","type":"change","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Get BooleanArray Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[0].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1050,"y":1100,"wires":[["d708e6264cec0070"]]},{"id":"051e1f282076fed2","type":"switch","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"empty check","property":"payload","propertyType":"msg","rules":[{"t":"nempty"}],"checkall":"true","repair":false,"outputs":1,"x":830,"y":1100,"wires":[["6e1edc31687dde54"]]},{"id":"de2a1c3e380f743b","type":"comment","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Discard Empty Datasets","info":"","x":820,"y":980,"wires":[]},{"id":"c74606c48ccf5a40","type":"comment","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Parse StaticData Values","info":"","x":1070,"y":980,"wires":[]},{"id":"053bda13f2a2eabe","type":"comment","z":"5b972161c4e0464e","g":"5afdbddf71507886","name":"Display on Dashboard","info":"","x":1340,"y":980,"wires":[]},{"id":"277dcf430dc86996","type":"ui-text","z":"5b972161c4e0464e","g":"5afdbddf71507886","group":"3d4f386e812e8b5f","order":0,"width":0,"height":0,"name":"","label":"ByteAnalogItemArray","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1340,"y":1020,"wires":[]},{"id":"d708e6264cec0070","type":"ui-text","z":"5b972161c4e0464e","g":"5afdbddf71507886","group":"3d4f386e812e8b5f","order":0,"width":0,"height":0,"name":"","label":"BooleanArray","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1320,"y":1100,"wires":[]},{"id":"3d4f386e812e8b5f","type":"ui-group","name":"StaticData Values","page":"44d3feb2a1143d7b","width":"4","height":"1","order":3,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"25f95391088d4a08","type":"group","z":"5b972161c4e0464e","name":"Read MyDevice Values & Display on Dashboard","style":{"label":true,"color":"#000000"},"nodes":["bfe4274963a84e2e","0662c62c7f0cfac0","249c223139c5779e","efb293f13af17dc1","507d2c11c7586957","3b7695a52a1bf6e0","594ec38acadc9673","d4e2915ba92db8a6","85619f0eab615ac7","cd4941a8db3edcb6","ad91d2ca81697fc2"],"x":94,"y":1179,"w":1292,"h":182},{"id":"bfe4274963a84e2e","type":"OpcUa-Browser","z":"5b972161c4e0464e","g":"25f95391088d4a08","endpoint":"53f4394dbf12c6b7","item":"","datatype":"","topic":"","items":[],"name":"OPC Client Namespace Browse","x":590,"y":1280,"wires":[["507d2c11c7586957"]]},{"id":"0662c62c7f0cfac0","type":"inject","z":"5b972161c4e0464e","g":"25f95391088d4a08","name":"Read MyDevice Values @ 1 second","props":[{"p":"payload"},{"p":"topic","v":"Objects.MyObjects.MyDevice.nodeId","vt":"flow"}],"repeat":"1","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":290,"y":1280,"wires":[["bfe4274963a84e2e"]]},{"id":"249c223139c5779e","type":"comment","z":"5b972161c4e0464e","g":"25f95391088d4a08","name":"Read MyDevice","info":"","x":480,"y":1240,"wires":[]},{"id":"efb293f13af17dc1","type":"change","z":"5b972161c4e0464e","g":"25f95391088d4a08","name":"Get MyLevel Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[0].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1030,"y":1260,"wires":[["cd4941a8db3edcb6"]]},{"id":"507d2c11c7586957","type":"switch","z":"5b972161c4e0464e","g":"25f95391088d4a08","name":"empty check","property":"payload","propertyType":"msg","rules":[{"t":"nempty"}],"checkall":"true","repair":false,"outputs":1,"x":810,"y":1280,"wires":[["efb293f13af17dc1","3b7695a52a1bf6e0"]]},{"id":"3b7695a52a1bf6e0","type":"change","z":"5b972161c4e0464e","g":"25f95391088d4a08","name":"Get MySwitch Value","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload[4].item.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1040,"y":1320,"wires":[["ad91d2ca81697fc2"]]},{"id":"594ec38acadc9673","type":"comment","z":"5b972161c4e0464e","g":"25f95391088d4a08","name":"Display on Dashboard","info":"","x":1260,"y":1220,"wires":[]},{"id":"d4e2915ba92db8a6","type":"comment","z":"5b972161c4e0464e","g":"25f95391088d4a08","name":"Parse MyDevice Values","info":"","x":1040,"y":1220,"wires":[]},{"id":"85619f0eab615ac7","type":"comment","z":"5b972161c4e0464e","g":"25f95391088d4a08","name":"Discard Empty Datasets","info":"","x":800,"y":1240,"wires":[]},{"id":"cd4941a8db3edcb6","type":"ui-gauge","z":"5b972161c4e0464e","g":"25f95391088d4a08","name":"Level","group":"ec0ecb26fde8db3e","order":0,"width":3,"height":3,"gtype":"gauge-half","gstyle":"needle","title":"Level","units":"%","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#0094ce"},{"from":"25","color":"#0094ce"},{"from":"50","color":"#0094ce"},{"from":"100","color":"#0094ce"}],"min":0,"max":"100","sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":1250,"y":1260,"wires":[]},{"id":"ad91d2ca81697fc2","type":"ui-led","z":"5b972161c4e0464e","g":"25f95391088d4a08","name":"","group":"ec0ecb26fde8db3e","order":-1,"width":0,"height":0,"label":"Switch","labelPlacement":"left","labelAlignment":"flex-start","states":[{"value":"false","valueType":"bool","color":"#ff0000"},{"value":"true","valueType":"bool","color":"#00ff00"}],"allowColorForValueInMessage":false,"shape":"circle","showBorder":true,"showGlow":true,"x":1250,"y":1320,"wires":[]},{"id":"ec0ecb26fde8db3e","type":"ui-group","name":"MyDevice Status & Control","page":"44d3feb2a1143d7b","width":"3","height":"1","order":4,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"3de6c861611c3afa","type":"group","z":"5b972161c4e0464e","name":"Write Mydevices values to OPC UA Server","style":{"label":true,"color":"#000000"},"nodes":["a66583d91b581cd8","3e8cb6e199012155","9fa33d1c9c621611","fb7f57b4da5883ae","9c5ff104eb9c8b10","77bcb828bec95336","afa83dbb46449d4a","fa08f0ed04296363","9f591797b56c565d"],"x":94,"y":1439,"w":792,"h":182},{"id":"a66583d91b581cd8","type":"OpcUa-Item","z":"5b972161c4e0464e","g":"3de6c861611c3afa","item":"ns=6;s=MySwitch","datatype":"Boolean","value":"","name":"Toggle MySwitch","x":470,"y":1520,"wires":[["3e8cb6e199012155"]]},{"id":"3e8cb6e199012155","type":"OpcUa-Client","z":"5b972161c4e0464e","g":"3de6c861611c3afa","endpoint":"53f4394dbf12c6b7","action":"write","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"name":"Write MySwitch","x":720,"y":1520,"wires":[[],[]]},{"id":"9fa33d1c9c621611","type":"comment","z":"5b972161c4e0464e","g":"3de6c861611c3afa","name":"Dashboard Input","info":"","x":200,"y":1480,"wires":[]},{"id":"fb7f57b4da5883ae","type":"OpcUa-Item","z":"5b972161c4e0464e","g":"3de6c861611c3afa","item":"ns=6;s=MyLevel","datatype":"Double","value":"","name":"Modify MyLevel","x":460,"y":1580,"wires":[["9c5ff104eb9c8b10"]]},{"id":"9c5ff104eb9c8b10","type":"OpcUa-Client","z":"5b972161c4e0464e","g":"3de6c861611c3afa","endpoint":"53f4394dbf12c6b7","action":"write","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"name":"Write MyLevel","x":720,"y":1580,"wires":[[],[]]},{"id":"77bcb828bec95336","type":"comment","z":"5b972161c4e0464e","g":"3de6c861611c3afa","name":"Call OPC UA Item","info":"","x":470,"y":1480,"wires":[]},{"id":"afa83dbb46449d4a","type":"comment","z":"5b972161c4e0464e","g":"3de6c861611c3afa","name":"Write OPC UA Item to Client","info":"","x":740,"y":1480,"wires":[]},{"id":"fa08f0ed04296363","type":"ui-switch","z":"5b972161c4e0464e","g":"3de6c861611c3afa","name":"","label":"Toggle MySwitch","group":"ec0ecb26fde8db3e","order":0,"width":0,"height":0,"passthru":false,"topic":"topic","topicType":"msg","style":"","className":"","onvalue":"true","onvalueType":"bool","onicon":"","oncolor":"","offvalue":"false","offvalueType":"bool","officon":"","offcolor":"","x":210,"y":1520,"wires":[["a66583d91b581cd8"]]},{"id":"9f591797b56c565d","type":"ui-slider","z":"5b972161c4e0464e","g":"3de6c861611c3afa","group":"ec0ecb26fde8db3e","name":"","label":"Modify MyLevel","tooltip":"","order":0,"width":0,"height":0,"passthru":false,"outs":"all","topic":"topic","topicType":"msg","thumbLabel":true,"min":"0","max":"100","step":1,"className":"","x":200,"y":1580,"wires":[["fb7f57b4da5883ae"]]},{"id":"a6e9abacd0bdf3b6","type":"group","z":"5b972161c4e0464e","name":"Read Alarms & Events From OPC UA Server","style":{"label":true,"color":"#000000"},"nodes":["90fb4ca64a642edf","b76f64786bc681c3","71e24b671bc03fb8","c7438df35b506470","c7e8919b636cb51d","5952b86dae22b056","04992b24a3836f19","325068cb935cd6d1","5b4d1bd8b342fc05","ba1ea89438335cb8","d662d662c5ccb9c1","1e3956200997581f","0b8ac86e5e4f9f8d","62b2e14ce0429eef"],"x":94,"y":1679,"w":1352,"h":282},{"id":"90fb4ca64a642edf","type":"comment","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Call OPC UA Item","info":"","x":470,"y":1820,"wires":[]},{"id":"b76f64786bc681c3","type":"OpcUa-Event","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","root":"ns=6;s=MyLevel.Alarm","activatecustomevent":false,"eventtype":"i=2041","customeventtype":"","name":"MyLevel Alarms","x":500,"y":1860,"wires":[["c7438df35b506470"]]},{"id":"71e24b671bc03fb8","type":"inject","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Trigger Alarm Event Capture","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":260,"y":1860,"wires":[["b76f64786bc681c3"]]},{"id":"c7438df35b506470","type":"OpcUa-Client","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","endpoint":"53f4394dbf12c6b7","action":"events","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"name":"Get MyLevel Events","x":720,"y":1860,"wires":[["c7e8919b636cb51d","5952b86dae22b056","04992b24a3836f19"],[]]},{"id":"c7e8919b636cb51d","type":"change","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Event Text","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.Message.text","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":990,"y":1800,"wires":[["d662d662c5ccb9c1","1e3956200997581f"]]},{"id":"5952b86dae22b056","type":"change","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Event Time","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.Time","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":990,"y":1860,"wires":[["0b8ac86e5e4f9f8d"]]},{"id":"04992b24a3836f19","type":"change","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Event Severity","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.Severity","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1000,"y":1920,"wires":[["62b2e14ce0429eef"]]},{"id":"325068cb935cd6d1","type":"comment","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Parse Event Dataset","info":"","x":990,"y":1760,"wires":[]},{"id":"5b4d1bd8b342fc05","type":"comment","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Get OPC Events from Client","info":"","x":720,"y":1820,"wires":[]},{"id":"ba1ea89438335cb8","type":"comment","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","name":"Display Events on Dashboard","info":"","x":1240,"y":1720,"wires":[]},{"id":"d662d662c5ccb9c1","type":"ui-notification","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","ui":"5355e0c476f9da3b","position":"center center","colorDefault":true,"color":"#000000","displayTime":"3","showCountdown":true,"outputs":1,"allowDismiss":true,"dismissText":"Close","raw":false,"className":"","name":"Event Notification","x":1230,"y":1800,"wires":[[]]},{"id":"1e3956200997581f","type":"ui-text","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","group":"ec0ecb26fde8db3e","order":0,"width":0,"height":0,"name":"","label":"Latest MyLevel Event","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1240,"y":1840,"wires":[]},{"id":"0b8ac86e5e4f9f8d","type":"ui-text","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","group":"ec0ecb26fde8db3e","order":0,"width":0,"height":0,"name":"","label":"Latest MyLevel Event Timestamp","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1280,"y":1880,"wires":[]},{"id":"62b2e14ce0429eef","type":"ui-text","z":"5b972161c4e0464e","g":"a6e9abacd0bdf3b6","group":"ec0ecb26fde8db3e","order":0,"width":0,"height":0,"name":"","label":"Latest MyLevel Event Severity","format":"{{msg.payload}}","layout":"row-spread","style":false,"font":"","fontSize":16,"color":"#717171","className":"","x":1270,"y":1920,"wires":[]}]
```
::


# How to Deploy a Basic OPC-UA Server in Node-RED - Part 1 (2026)

This article is the first part of a series of OPC-UA content. Here, we will explain some basic concepts of OPC-UA as they apply to building a server in Node-RED, then walk through and deploy an example OPC-UA Server.

## What is OPC-UA?

Open Platform Communications Unified Architecture (OPC UA) is an open, platform independent communication framework frequently utilized in industrial automation, and is considered one of the key protocol standards for Industry 4.0 and Industrial IoT (IIoT). The standard is developed and maintained by a consortium called the OPC Foundation, with recognizable industry names such as Siemens, Honeywell, Microsoft, Beckhoff, SAP, Yokogawa, ABB, Rockwell, and Schneider Electric.

Because of OPC-UA’s wide industry acceptance, it is increasingly becoming natively supported on devices and systems spanning the entirety of the automation pyramid.

!["Automation Pyramid"](https://flowfuse.com/blog/2023/07/images/opc-ua-1/automation-pyramid.jpg "Automation Pyramid")&#x2A;Image reference - [imagecontroltips.com](https://www.motioncontroltips.com/what-is-opc-ua-and-how-does-it-compare-with-industrial-ethernet/){rel="&#x22;nofollow&#x22;"}*

## Fieldbus Model vs OPC-UA Information Model

As of today, industrial ethernet fieldbuses dominate the field/device-level (level 0) and controller/PLC-level (level 1) of the automation pyramid.
!["OPC-UA Pyramid"](https://flowfuse.com/blog/2023/07/images/opc-ua-1/OPC-UA-pyramid-2.webp "OPC-UA Pyramid")&#x2A;Image reference - [mdpi.com](https://www.mdpi.com/1424-8220/21/14/4656){rel="&#x22;nofollow&#x22;"}*

Fieldbuses such as Profinet, Ethernet/IP, and EtherCAT, employ deterministic, real-time communication, which is essential for mission-critical and safety-oriented automation tasks. OPC-UA is most commonly encountered at the SCADA level and above (level 2-4). However, with the inclusion of [Time Sensitive Networking (TSN) into the OPC-UA technology stack](https://www.tttech-industrial.com/resource-library/blog-posts/opc-ua-fx){rel="&#x22;nofollow&#x22;"}, OPC-UA can be feasibly used for real-time communication all the way down to the device level.

Traditionally, fieldbus protocols transmit only raw data from field devices (ie, a float to represent a pressure, or a boolean to represent the position of a switch). The fieldbus data gets pushed up the automation stack layer by layer, where eventually it will be converted to a format suitable for IT systems to consume (such as OPC-UA).

!["Fieldbus Model"](https://flowfuse.com/blog/2023/07/images/opc-ua-1/fieldbus-model.png "Fieldbus Model")

In contrast to fieldbus protocols, OPC-UA represents automation data in the form of nodes. The framework for constructing nodes is referred to as the [OPC Information model](https://reference.opcfoundation.org/Core/Part5/v104/docs/){rel="&#x22;nofollow&#x22;"}, and consists of pre-defined classes and methods that are programmed in the OPC Server address space.

!["OPC Information Model"](https://flowfuse.com/blog/2023/07/images/opc-ua-1/opc-information-model.png "OPC Information Model")
Devices can be described as objects that give a holistic view of the device, beyond simply the raw value. To construct a device object, we can take different individual attributes associated with a device, such as the transmitter raw value, transmitter fault flag, alarm setpoint, and combine them, similar to how user-defined datatypes (UDTs) are objects used to represent devices in PLCs. The information model also defines a folder structure, to allow devices information to reside in a structured hierarchy. Using the example temperature transmitter above, an example folder structure can be constructed as follows:

`/Root/Objects/Calcinator 1 PLC/Temperature Transmitters/Tank 1 Temperature/Transmitter Value`

This folder structure will be exposed via the OPC Client browser, allowing end-users to easily “drill down” to individual node information in a logical manner.

!["OPC Client Browser"](https://flowfuse.com/blog/2023/07/images/opc-ua-1/opc-client-browser.png "OPC Information Model")
In summary, OPC-UA represents a trade-off between complex information modeling, with the versatility for that data to be consumed by devices and systems all the way up the automation pyramid layers. The data does not have to pass through subsequent automation layers on the way up, nor does the data need to undergo any conversion along the way.

!["OPC-UA Distributed Model"](https://flowfuse.com/blog/2023/07/images/opc-ua-1/OPC-UA-distributed-model.jpg "OPC-UA Distributed Model")&#x2A;Image reference - [ifr.org](https://ifr.org/post/faster-robot-communication-through-the-opc-robotics-companion-specification){rel="&#x22;nofollow&#x22;"}*

The OPC client simply needs to subscribe to the OPC Server endpoint url (ex. opc.tcp\://server.address), and the client will be able to browse the structured OPC data as it’s modeled in the server. Any client will receive the information in the same manner, regardless if it’s a PLC, SCADA, MES, or ERP system. This opens the possibility for horizontal and vertical system integration in a standardized manner. Additionally, the more information that is exposed about a device, the easier it is to track, and use said data to autonomously reconfigure, or pre-emptively take maintenance actions.

## Deploying an Example OPC-UA Server in Node-RED

With some background on OPC-UA and how information is modeled in mind, we can take a look at the [node-red-contrib-opcua-server](https://flows.nodered.org/node/node-red-contrib-opcua-server){rel="&#x22;nofollow&#x22;"} node, which is merely a compact version of the [node-red-contrib-opcua](https://flows.nodered.org/node/node-red-contrib-opcua){rel="&#x22;nofollow&#x22;"} node that only focuses on the OPC-UA server and hence requires less dependencies.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

An [example flow](https://github.com/BiancoRoyal/node-red-contrib-opcua-server/blob/master/examples/server-with-context.json){rel="&#x22;nofollow&#x22;"} is provided on github that can serve as a basis for understanding how a OPC-UA server is constructed. Let’s get the example server up and running.

Deploying the example flow yields the following result -

![Compact Server Flow](https://flowfuse.com/blog/2023/07/images/opc-ua-1/compact-server-flow.png "Compact Server Flow")

- an inject node is trigging the function `set flow context Inputs` at a one second interval, which creates 7 randomly generated float values and stores them as flow context variables, `isoInput2` - `isoInput8` (isolated inputs). The values will change to a new random number each time the node is injected.

```javascript
flow.set('isoInput2', Math.random() + 12.0)
flow.set('isoInput3', Math.random() + 13.0)
flow.set('isoInput4', Math.random() + 14.0)
flow.set('isoInput5', Math.random() + 15.0)
flow.set('isoInput6', Math.random() + 16.0)
flow.set('isoInput7', Math.random() + 17.0)
flow.set('isoInput8', Math.random() + 18.0)

...
```

- another inject node is triggering the function `set flow context Outputs`, also at a one second interval, which creates another set of 7 randomly generated float values and stores them as flow context variables, `isoOutput2` - `isoOutput8` (isolated inputs). The values will change to a new random number each time the node is injected.

```javascript
flow.set('isoOutput2', Math.random() + 2.0)
flow.set('isoOutput3', Math.random() + 3.0)
flow.set('isoOutput4', Math.random() + 4.0)
flow.set('isoOutput5', Math.random() + 5.0)
flow.set('isoOutput6', Math.random() + 6.0)
flow.set('isoOutput7', Math.random() + 7.0)
flow.set('isoOutput8', Math.random() + 8.0)

...
```

We can confirm the values are being stored in memory by checking the flow context data and pressing the refresh button.

!["Screenshot showing the Context Data option"](https://flowfuse.com/blog/2023/07/images/opc-ua-1/context-data-1.png "Screenshot showing the Context Data option")

![Screenshot showing the flow variables in the context data tab](https://flowfuse.com/blog/2023/07/images/opc-ua-1/context-data-2.png "Screenshot showing the flow variables in the context data tab")
Each time we hit refresh, the values change, confirming that the values are randomly changing every second.

The last, and most important part of the flow, is the `Compact-Server` node, which actually stands alone without any incoming or outgoing connections.

!["Compact Server Node"](https://flowfuse.com/blog/2023/07/images/opc-ua-1/compact-server-node.png "Compact Server Node")
In the `Compact-Server` node properties, the first tab is `Settings`, and the two important properties here are `Port` and `Show Errors`. As can be seen in the node screenshot above, the node is reporting `active`, which means the server is configured correctly.

![Screenshot showing the Settings Tab of compact server node](https://flowfuse.com/blog/2023/07/images/opc-ua-1/settings-tab.png "Screenshot showing the Settings Tab of compact server node")

The `Limits` tab specifies some default limits that we can configure if we like, but are not necessary to be modified for test purposes.

The `Security` tab has one important option, `Allow Anonymous`. By default, anonymous access is enabled.

![Screenshot showing the Security Tab of compact server node](https://flowfuse.com/blog/2023/07/images/opc-ua-1/security-tab.png "Screenshot showing the Security Tab of compact server node")
For a production system, we will want to enable security, but for test purposes, we will leave anonymous access enabled.

`Users & Sets` tab is related to security and permissions. We can leave this empty for testing.

The `Address Space` tab is where our server OPC Information Model is constructed, using classes and methods from the [node-opcua sdk](https://node-opcua.github.io/){rel="&#x22;nofollow&#x22;"}.

Breaking down the provided example code for further context, it starts with a function that is responsible for invoking the OPC-UA server,

```javascript
  const opcua = coreServer.choreCompact.opcua;
```

and then the namespace is created.

```javascript
const namespace = addressSpace.getOwnNamespace();
```

Further down, the variables that will be published by the server (which are our `isoInput` & `isoOutput` flow context variables) are initialized,

```javascript
  this.sandboxFlowContext.set("isoInput1", 0);
  this.setInterval(() => {
    flexServerInternals.sandboxFlowContext.set(
      "isoInput1",
      Math.random() + 50.0
    );
  }, 500);
  this.sandboxFlowContext.set("isoInput2", 0);
  this.sandboxFlowContext.set("isoInput3", 0);
...
```

and an OPC folder structure is defined.

```javascript
  coreServer.debugLog("init dynamic address space");
  const rootFolder = addressSpace.findNode("RootFolder");

  node.warn("construct new address space for OPC UA");

  const myDevice = namespace.addFolder(rootFolder.objects, {
    "browseName": "RaspberryPI-Zero-WLAN"
  });
...
```

Then, with our variables and folder structure defined, nodes are added to the namespace for each context variable.

```javascript
  const gpioDI1 = namespace.addVariable({
    "organizedBy": isoInputs,
    "browseName": "I1",
    "nodeId": "ns=1;s=Isolated_Input1",
    "dataType": "Double",
    "value": {
      "get": function() {
        return new Variant({
          "dataType": DataType.Double,
          "value": flexServerInternals.sandboxFlowContext.get("isoInput1")
        });
      },
      "set": function(variant) {
        flexServerInternals.sandboxFlowContext.set(
          "isoInput1",
          parseFloat(variant.value)
        );
        return opcua.StatusCodes.Good;
      }
    }
  });

...
```

Last, OPC views are defined. Views create custom hierarchies our OPC Client can browse as an alternative to the default folder structure.

```javascript
  const viewDI = namespace.addView({
    "organizedBy": rootFolder.views,
    "browseName": "RPIW0-Digital-Ins"
  });

  const viewDO = namespace.addView({
    "organizedBy": rootFolder.views,
    "browseName": "RPIW0-Digital-Outs"
  });

  viewDI.addReference({
    "referenceType": "Organizes",
    "nodeId": gpioDI1.nodeId
  });

...

```

Finally, on the `Discovery` tab, we must define an endpoint for an OPC Client to subscribe to.

The `Endpoint Url` follows the format `opc.tcp://<address>:port`. Our port was defined on the `Settings` tab, which by default, is port `54845`. The address will be either the url or ip address of your Node-RED instance. In my case, it’s 192.168.0.114. So my Endpoint Url = `opc.tcp://192.168.0.114:54845`

![Screenshot showing the Discovery Tab of compact server node](https://flowfuse.com/blog/2023/07/images/opc-ua-1/discovery-tab.png "Screenshot showing the Discovery Tab of compact server node")
Once the endpoint url is added, deploy the flow, and confirm the server is reporting “active”.

![Screenshot showing the Active Tab of compact server node](https://flowfuse.com/blog/2023/07/images/opc-ua-1/compact-server-active.png "Screenshot showing the Active Tab of compact server node")

## Connect to Example OPC-Server Using OPC-UA Browser

To connect to our OPC endpoint, we need an OPC Client. Prosys provides a [free OPC-UA Browser ](https://www.prosysopc.com/products/opc-ua-browser/){rel="&#x22;nofollow&#x22;"}that supports Windows, Linux, and Mac OS. To test our Server, the Windows version of Prosys OPC-UA Browser will be utilized.

To connect to our Node-RED OPC server, enter the endpoint url and press “connect to server”.

!["Screenshot showing the OPC Client"](https://flowfuse.com/blog/2023/07/images/opc-ua-1/opc-client-connect.png "Screenshot showing the OPC Client")
It will ask for security. Remember that we allowed anonymous access, so the default security mode of `None` is the correct option.

Once connected, we can browse our OPC Server.

![OPC Client UI](https://flowfuse.com/blog/2023/07/images/opc-ua-1/opc-client-ui.png)
If we navigate to `Objects → RaspberryPI-Zero-WLAN → GPIO → Inputs`, we can see a list of inputs that correspond to the `isoInput` context variables defined in the example flow, which are randomly generated numbers.

Clicking `I1` we can see the value in real-time, along with some additional properties.

![OPC Client Node](https://flowfuse.com/blog/2023/07/images/opc-ua-1/opc-client-node.png "OPC Client Node")
If we go to `Views`, we can see the custom hierarchy defined in the example server, which divides the data by Digital-Ins and Digital-Outs.

![OPC Client View](https://flowfuse.com/blog/2023/07/images/opc-ua-1/opc-client-view.png)

## Summary

In this article, we compare OPC-UA to traditional fieldbus protocols, explain the importance of the OPC UA Information Model to understand how data is modeled in the address space of an OPC Server, and then walk through and deploy an example compact OPC-UA Server flow.

This isn't just a lab exercise: [Opto 22, one of the original vendors behind the OPC standard, ships Node-RED pre-installed on its groov EPIC edge controllers](https://flowfuse.com/customer-stories/opto22-embraces-node-red/), putting this same OPC-UA server pattern into production on the factory floor.

In our next article, we will build a custom OPC-UA Server in Node-RED with data pulled from an Allen Bradley PLC over Ethernet/IP, using the PLC data to develop a custom OPC UA Information Model programmed in the OPC server address space.


# How to add images to Node-RED dashboards when using FlowFuse (2026)

Using images in your Node-RED dashboards can significantly improve your users' experience. The most common method to add images to dashboards is to store them within the filesystem of an Node-RED instance but sometimes that's not an option. How can you easily use images when working in a containerized environment such as Docker, or Kubernetes? We will also explore latest feature from FlowFuse that makes this step super easy.

When designing a dashboard, images allow you to significantly enrich your content. Some examples include:

- displaying maps to guide engineers to a problem which needs resolving.
- displaying pictures of specific hardware on a factory-floor which needs to be checked.
- displaying physical tools which should be used to resolve a problem.

### Prerequisites

Before we begin, ensure you have the following custom nodes installed:

- [@flowfuse/node-red-dashboard](https://flows.nodered.org/node/@flowfuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"} - A set of dashboard nodes for Node-RED. We will use this dashboard to demonstrate how to quickly display images using static assets. If you're a beginner and want to dive deeper, refer to [Getting started with FlowFuse Dashboarad](https://flowfuse.com/blog/2024/03/dashboard-getting-started/).
- [node-red-contrib-string](https://flows.nodered.org/node/node-red-contrib-string){rel="&#x22;nofollow&#x22;"} - A string manipulation node based on the lightweight stringjs library.
- [node-red-node-base64](https://flows.nodered.org/node/node-red-node-base64){rel="&#x22;nofollow&#x22;"} - A Node-RED node to encode and decode data to and from base64.

## Easily Add Images to Node-RED Dashboards with FlowFuse’s Static Asset Service

[FlowFuse's static assets](https://flowforge.com/docs/user/static-asset-service/){rel="&#x22;nofollow&#x22;"} service provides a simple way to manage images and other assets in Node-RED. Follow these steps to quickly add images to your Node-RED dashboard.

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

### Steps to Add Images Using the Static Asset Service:

##### 1. Access the Static Assets Service

- Log into your FlowFuse account, navigate to your **Node-RED instance**, and click on the **Static Assets Service** tab.

##### 2. Create a New Folder (Optional)

- Click the **New Folder** button to create a folder that will help you organize your assets. Provide a folder name and **confirm** the creation.

##### 3. Upload Your Image

- Enter the folder (or skip this step if not using folders), click **Upload**, select your image file, and **confirm**.

##### 4. Copy the Image Path

- Once uploaded, click the **copy icon** next to the image to get the path for use in Node-RED.

##### 5. Set Up the Image Flow in Node-RED

- Open the Node-RED editor for the relevant instance.
- Drag an `inject` node onto the canvas and set it to trigger immediately when the flow is deployed.
- Drag a `read file` node, paste the copied file path in the **Filename** field, and set the output to Single buffer object.

##### 6. Prepare the Image for Display

- Add a `string` node to convert the buffer to a base64 string. Set **From** as `msg.filename` and adjust the **Method** to `getmost`.
- Add a `change` node and configure it to add the elements shown in the following image: :br![The change node showing added elements](https://flowfuse.com/blog/2023/07/images/change-node.png "The change node showing added elements")

##### 7. Display the Image in the Dashboard

- Drag a `ui-template` node onto the canvas.
- Add the code in `ui-template` with an `<img>` tag, configuring the `src` attribute with `msg.payload`, as shown in the following code. Alternatively, you can use the following code directly if you want to display the image in the top-left corner of your dashboard header:
  ```javascript
  <template>
      <Teleport v-if="mounted" to="#app-bar-title">
          <img :src="msg.payload" style="height: 32px;" />
      </Teleport>
  </template>

  <script>
      export default {
          data() {
              return {
                  mounted: false
              }
          },
          mounted() {
              this.mounted = true;
          }
      }
  </script>
  ```

##### 8. Connect the Nodes

- Finally connect the nodes in the following order:
  the **output** of the `inject` node to the **input** of the `read file` node, then link to the `string node`, followed by the `change` node, and finally to the `ui-template` node. :br`inject → read file → string → change → ui-template`

::render-flow
```json
[{"id":"e50f7c57189d62f8","type":"group","z":"d4aa6dd5b63a56de","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["3bf4c71150bd0524","4d3ca1b96c181645","315948cc6a2cc9e8","fcf061d4cc732e2e","6563d8715af4cb06","d40caa36040de881"],"x":514,"y":699,"w":1752,"h":82},{"id":"3bf4c71150bd0524","type":"ui-template","z":"d4aa6dd5b63a56de","g":"e50f7c57189d62f8","group":"","page":"","ui":"25f447d87d1ce5c9","name":"Display image","order":0,"width":0,"height":0,"head":"","format":"<template>\n    <!-- Teleport the image to the #app-bar-title area when mounted -->\n    <Teleport v-if=\"mounted\" to=\"#app-bar-title\">\n        <img :src=\"msg.payload\" style=\"height: 32px;\" />\n    </Teleport>\n</template>\n\n<script>\n    export default {\n        data() {\n            return {\n                mounted: false\n            }\n        },\n        mounted() {\n            // Set mounted to true when the component is mounted\n            this.mounted = true\n        }\n    }\n</script>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"widget:ui","className":"","x":2160,"y":740,"wires":[[]]},{"id":"4d3ca1b96c181645","type":"inject","z":"d4aa6dd5b63a56de","g":"e50f7c57189d62f8","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":630,"y":740,"wires":[["315948cc6a2cc9e8"]]},{"id":"315948cc6a2cc9e8","type":"file in","z":"d4aa6dd5b63a56de","g":"e50f7c57189d62f8","name":"","filename":"Images/ff-logo--wordmark--light.png","filenameType":"str","format":"","chunk":false,"sendError":false,"encoding":"none","allProps":false,"x":880,"y":740,"wires":[["d40caa36040de881"]]},{"id":"fcf061d4cc732e2e","type":"change","z":"d4aa6dd5b63a56de","g":"e50f7c57189d62f8","name":"Add the file type to the mimetype, add to image content","rules":[{"t":"set","p":"mimetype","pt":"msg","to":"\"data:image/\"&msg.filetype&\";base64,\"","tot":"jsonata"},{"t":"set","p":"output","pt":"msg","to":"msg.mimetype&msg.payload","tot":"jsonata"},{"t":"move","p":"output","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1820,"y":740,"wires":[["3bf4c71150bd0524"]]},{"id":"6563d8715af4cb06","type":"string","z":"d4aa6dd5b63a56de","g":"e50f7c57189d62f8","name":"Get file type from file name","methods":[{"name":"getRightMost","params":[{"type":"str","value":"."}]}],"prop":"filename","propout":"filetype","object":"msg","objectout":"msg","x":1480,"y":740,"wires":[["fcf061d4cc732e2e"]]},{"id":"d40caa36040de881","type":"base64","z":"d4aa6dd5b63a56de","g":"e50f7c57189d62f8","name":"Convert Buffer to Base 64 String","action":"","property":"payload","x":1210,"y":740,"wires":[["6563d8715af4cb06"]]},{"id":"25f447d87d1ce5c9","type":"ui-base","name":"Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-control","ui-notification"],"showPathInSidebar":false,"showPageTitle":false,"titleBarStyle":"default"}]
```
::

Using the FlowFuse Static Assets service is highly beneficial when you want to display images in Node-RED dashboards, as it saves time compared to alternative solutions. However, it’s important to note that moving Node-RED instances through a DevOps pipeline currently does not support handling static assets. This feature is expected in future updates. If you want to manage images effectively within your Node-RED dashboards, consider the alternative solutions discussed in this blog, ensuring that the movement of instances does not affect the usage of these assets.

## Why not just store them in Node-RED's host operating system?

Storing images locally can work well when you can access and edit the images on an operating system, but that approach doesn't scale if you are moving instances through a DevOps pipeline. It can also not work well when deploying to environments where you don't have easy access to the host operating system.

How can we include images in dashboards, and be confident that a given build of an application will show the correct images, no matter where your Node-RED instances are hosted?

## Inspiration

There are various solutions to this problem, I wanted to share one I came across when working with a FlowFuse customer recently. I've modified the flows to make them more general in design, but the underlying principal is the same. I asked if I was OK to credit the customer but they said there was no need. Thanks for the inspiration, kind customer!

## Solution explanation

There are three key sections to this solution:

1. Pull the images we need from URLs
2. Store those images in the temporary filesystem of Node-RED
3. Serve up those images as needed in the dashboard

It is possible for us to skip step 2, but I wanted to have the images stored locally, in the Node-RED instance. storing the images locally will improve the loading times of the dashboard. This is especially beneficial when your dashboard is dynamically displaying relevant images, e.g. to show an image of a specific machine which needs to be attended to.

The key benefit of pulling the images from URLs this way is, no matter where you are running Node-RED, the correct images will be shown in your dashboard.

## Prequsite

Before moving forward, ensure you have the following nodes installed, as the flows shared later will require them:

- [node-red-contrib-calc](https://flows.nodered.org/node/node-red-contrib-calc){rel="&#x22;nofollow&#x22;"} - A Node-RED node to perform basic mathematical calculations.
- [node-red-contrib-image-output](https://flows.nodered.org/node/node-red-contrib-image-output){rel="&#x22;nofollow&#x22;"} - A simple way to preview and examine images in your flows.
- [node-red-contrib-os](https://flows.nodered.org/node/node-red-contrib-os){rel="&#x22;nofollow&#x22;"} - Nodes for obtaining system information like CPU usage.
- [node-red-contrib-string](https://flows.nodered.org/node/node-red-contrib-string){rel="&#x22;nofollow&#x22;"} - A string manipulation node based on the lightweight stringjs library.
- [@flowfuse/node-red-dashboard](https://flows.nodered.org/node/@flowfuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"} - A set of dashboard nodes for Node-RED.
- [node-red-node-base64](https://flows.nodered.org/node/node-red-node-base64){rel="&#x22;nofollow&#x22;"} - A Node-RED node to encode and decode data to and from base64.

## File and file-in nodes

I've included the flows as json below so you can try them out yourself. Please note, I'm using FlowFuse's own [file and file-in nodes](https://flowfuse.com/docs/user/filenodes/) in these examples. If you want to use these flows on hosting other than FlowFuse, you will need to replace the nodes with the standard Node-RED file and file-in nodes.

## The flows

The first flow takes image URLs in an array, each image is downloaded, processed, then saved to the local file storage. Let's take a look at the flow:

::render-flow
```json
[{"id":"6b8059f703d0f574","type":"group","z":"c6f2a894be05d857","name":"Write the images to disk from the URLs","style":{"label":true},"nodes":["04fb6911559797a0","8a3c077f0f85a905","22c5026dd58e418b","6fcca5cfee2bcb89"],"x":38,"y":53,"w":1004,"h":434},{"id":"04fb6911559797a0","type":"group","z":"c6f2a894be05d857","g":"6b8059f703d0f574","name":"Inject the image URLs to download","style":{"label":true},"nodes":["e635ceb0577a86d5","29fe40a054be5b2b","1e81a35c27aae6ad"],"x":74,"y":79,"w":502,"h":82},{"id":"e635ceb0577a86d5","type":"inject","z":"c6f2a894be05d857","g":"04fb6911559797a0","name":"Send in image URLs as an array","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"[\"https://openjsf.org/wp-content/uploads/sites/84/2023/02/ff-logo-wordmark-light_4x.png\",\"https://nodered.org/images/nr-image-1.png\",\"/img/screen-pseudo-overview-2QvTVle3Mr-384.avif\"]","payloadType":"json","x":250,"y":120,"wires":[["29fe40a054be5b2b"]]},{"id":"29fe40a054be5b2b","type":"split","z":"c6f2a894be05d857","g":"04fb6911559797a0","name":"","splt":"\\n","spltType":"str","arraySplt":1,"arraySpltType":"len","stream":false,"addname":"","x":450,"y":120,"wires":[["1e81a35c27aae6ad"]]},{"id":"1e81a35c27aae6ad","type":"link out","z":"c6f2a894be05d857","g":"04fb6911559797a0","name":"link out 3","mode":"link","links":["f582702ec222069c"],"x":535,"y":120,"wires":[]},{"id":"8a3c077f0f85a905","type":"group","z":"c6f2a894be05d857","g":"6b8059f703d0f574","name":"Download the images","style":{"label":true},"nodes":["453f3b9d7d312bd2","ecbd7b1a410ecd9d","4d650baa2118036e","f582702ec222069c"],"x":84,"y":179,"w":532,"h":82},{"id":"453f3b9d7d312bd2","type":"http request","z":"c6f2a894be05d857","g":"8a3c077f0f85a905","name":"Get the image","method":"GET","ret":"bin","paytoqs":"ignore","url":"","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":460,"y":220,"wires":[["4d650baa2118036e"]]},{"id":"ecbd7b1a410ecd9d","type":"change","z":"c6f2a894be05d857","g":"8a3c077f0f85a905","name":"Set URL to download","rules":[{"t":"move","p":"payload","pt":"msg","to":"url","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":260,"y":220,"wires":[["453f3b9d7d312bd2"]]},{"id":"4d650baa2118036e","type":"link out","z":"c6f2a894be05d857","g":"8a3c077f0f85a905","name":"link out 1","mode":"link","links":["8bc38803dec97185"],"x":575,"y":220,"wires":[]},{"id":"f582702ec222069c","type":"link in","z":"c6f2a894be05d857","g":"8a3c077f0f85a905","name":"link in 3","links":["1e81a35c27aae6ad"],"x":125,"y":220,"wires":[["ecbd7b1a410ecd9d"]]},{"id":"22c5026dd58e418b","type":"group","z":"c6f2a894be05d857","g":"6b8059f703d0f574","name":"Save the images to the local storage","style":{"label":true},"nodes":["95c819560d22f394","0fe7f013b6356c5d","7edc6cb2b0d243db","829bfc8e6e293ada","8bc38803dec97185","98980d88013c6e12"],"x":84,"y":279,"w":932,"h":82},{"id":"95c819560d22f394","type":"base64","z":"c6f2a894be05d857","g":"22c5026dd58e418b","name":"convert to base64","action":"str","property":"payload","x":250,"y":320,"wires":[["829bfc8e6e293ada"]]},{"id":"0fe7f013b6356c5d","type":"file","z":"c6f2a894be05d857","g":"22c5026dd58e418b","name":"Write file to storage","filename":"filename","filenameType":"msg","appendNewline":true,"createDir":false,"overwriteFile":"true","encoding":"none","x":850,"y":320,"wires":[["98980d88013c6e12"]]},{"id":"7edc6cb2b0d243db","type":"string","z":"c6f2a894be05d857","g":"22c5026dd58e418b","name":"Get filename from the URL","methods":[{"name":"getRightMost","params":[{"type":"str","value":"/"}]}],"prop":"responseUrl","propout":"filename","object":"msg","objectout":"msg","x":620,"y":320,"wires":[["0fe7f013b6356c5d"]]},{"id":"829bfc8e6e293ada","type":"image","z":"c6f2a894be05d857","g":"22c5026dd58e418b","name":"preview","width":"150","data":"payload","dataType":"msg","thumbnail":false,"active":true,"pass":true,"outputs":1,"x":420,"y":320,"wires":[["7edc6cb2b0d243db"]]},{"id":"8bc38803dec97185","type":"link in","z":"c6f2a894be05d857","g":"22c5026dd58e418b","name":"link in 1","links":["4d650baa2118036e"],"x":125,"y":320,"wires":[["95c819560d22f394"]]},{"id":"98980d88013c6e12","type":"link out","z":"c6f2a894be05d857","g":"22c5026dd58e418b","name":"link out 2","mode":"link","links":["1e94b5bab542830a"],"x":975,"y":320,"wires":[]},{"id":"6fcca5cfee2bcb89","type":"group","z":"c6f2a894be05d857","g":"6b8059f703d0f574","name":"Output a debug once all images have been processed","style":{"label":true},"nodes":["d1a6feea3ac829c6","119f8008752bc4fb","1e94b5bab542830a"],"x":64,"y":379,"w":382,"h":82},{"id":"d1a6feea3ac829c6","type":"debug","z":"c6f2a894be05d857","g":"6fcca5cfee2bcb89","name":"debug 140","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":330,"y":420,"wires":[]},{"id":"119f8008752bc4fb","type":"join","z":"c6f2a894be05d857","g":"6fcca5cfee2bcb89","name":"","mode":"auto","build":"object","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":"false","timeout":"","count":"","reduceRight":false,"x":190,"y":420,"wires":[["d1a6feea3ac829c6"]]},{"id":"1e94b5bab542830a","type":"link in","z":"c6f2a894be05d857","g":"6fcca5cfee2bcb89","name":"link in 2","links":["98980d88013c6e12"],"x":105,"y":420,"wires":[["119f8008752bc4fb"]]}]
```
::

We've now downloaded the images we need, and saved them to our local storage, to make them load more quickly when a user views them in the dashboard.

Onto the second flow, which will get the images from the local storage and then load them into the dashboard. Let's take a look at it:

![Get the images from the local storage and place them in a dashboard](https://flowfuse.com/blog/2023/07/images/load-images-from-disk-and-show-in-dashboard.png "Get the images from the local storage and place them in a dashboard")

You can import this flow into Node-RED using the code below:

::render-flow
```json
[{"id":"596006fe79275d55","type":"group","z":"d4aa6dd5b63a56de","name":"Get the images from the filestore and display in the Dashboard","style":{"label":true},"nodes":["be421f8265c4c090","d2dc98b4f3d6b968","b9029adc6097bd14","1e54acecec6bd411","99aaee673fc70bc2"],"x":1228,"y":3733,"w":974,"h":654},{"id":"be421f8265c4c090","type":"group","z":"d4aa6dd5b63a56de","g":"596006fe79275d55","name":"Get the images from the local storage","style":{"label":true},"nodes":["c698b2945583e126","ab22b978a2f5d80f","2836914f9b643e34","8e32aba67d9ac9d4"],"x":1264,"y":3899,"w":492,"h":82},{"id":"c698b2945583e126","type":"image","z":"d4aa6dd5b63a56de","g":"be421f8265c4c090","name":"preview","width":"150","data":"payload","dataType":"msg","thumbnail":false,"active":true,"pass":true,"outputs":1,"x":1620,"y":3940,"wires":[["8e32aba67d9ac9d4"]]},{"id":"ab22b978a2f5d80f","type":"file in","z":"d4aa6dd5b63a56de","g":"be421f8265c4c090","name":"Read file from storage","filename":"payload","filenameType":"msg","format":"utf8","chunk":false,"sendError":false,"encoding":"none","allProps":false,"x":1440,"y":3940,"wires":[["c698b2945583e126"]]},{"id":"2836914f9b643e34","type":"link in","z":"d4aa6dd5b63a56de","g":"be421f8265c4c090","name":"link in 4","links":["a9958e1e4b07191a"],"x":1305,"y":3940,"wires":[["ab22b978a2f5d80f"]]},{"id":"8e32aba67d9ac9d4","type":"link out","z":"d4aa6dd5b63a56de","g":"be421f8265c4c090","name":"link out 5","mode":"link","links":["bbdd3a2e737e1074"],"x":1715,"y":3940,"wires":[]},{"id":"d2dc98b4f3d6b968","type":"group","z":"d4aa6dd5b63a56de","g":"596006fe79275d55","name":"Prepare each image to be shown in the dashboard","style":{"label":true},"nodes":["54f0e7fddf447d10","d856077cc6d37093","bbdd3a2e737e1074","2d29c953bcdab787"],"x":1264,"y":3999,"w":832,"h":82},{"id":"54f0e7fddf447d10","type":"change","z":"d4aa6dd5b63a56de","g":"d2dc98b4f3d6b968","name":"Add the file type to the mimetype, add to image content","rules":[{"t":"set","p":"mimetype","pt":"msg","to":"\"data:image/\"&msg.filetype&\";base64,\"","tot":"jsonata"},{"t":"set","p":"output","pt":"msg","to":"msg.mimetype&msg.payload","tot":"jsonata"},{"t":"move","p":"output","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1810,"y":4040,"wires":[["2d29c953bcdab787"]]},{"id":"d856077cc6d37093","type":"string","z":"d4aa6dd5b63a56de","g":"d2dc98b4f3d6b968","name":"Get file type from file name","methods":[{"name":"getRightMost","params":[{"type":"str","value":"."}]}],"prop":"filename","propout":"filetype","object":"msg","objectout":"msg","x":1460,"y":4040,"wires":[["54f0e7fddf447d10"]]},{"id":"bbdd3a2e737e1074","type":"link in","z":"d4aa6dd5b63a56de","g":"d2dc98b4f3d6b968","name":"link in 5","links":["8e32aba67d9ac9d4"],"x":1305,"y":4040,"wires":[["d856077cc6d37093"]]},{"id":"2d29c953bcdab787","type":"link out","z":"d4aa6dd5b63a56de","g":"d2dc98b4f3d6b968","name":"link out 6","mode":"link","links":["c5e4febe48363987"],"x":2055,"y":4040,"wires":[]},{"id":"b9029adc6097bd14","type":"group","z":"d4aa6dd5b63a56de","g":"596006fe79275d55","name":"Send the images to the correct section of the dashboard","style":{"label":true},"nodes":["fa873d7bccd2b6be","c5e4febe48363987","d80e5a54a7c5b2f8","fb0c76a6934b0a7f","4e4105a9774c7b5c","917c842a1b46ad4c"],"x":1264,"y":4099,"w":912,"h":162},{"id":"fa873d7bccd2b6be","type":"switch","z":"d4aa6dd5b63a56de","g":"b9029adc6097bd14","name":"Send the image to the correct section of the dashboard","property":"filename","propertyType":"msg","rules":[{"t":"eq","v":"ff-logo-wordmark-light_4x.png","vt":"str"},{"t":"eq","v":"screen-pseudo-overview-2QvTVle3Mr-384.avif","vt":"str"},{"t":"eq","v":"nr-image-1.png","vt":"str"}],"checkall":"true","repair":false,"outputs":3,"x":1550,"y":4180,"wires":[["917c842a1b46ad4c"],["4e4105a9774c7b5c"],["fb0c76a6934b0a7f"]]},{"id":"c5e4febe48363987","type":"link in","z":"d4aa6dd5b63a56de","g":"b9029adc6097bd14","name":"link in 6","links":["2d29c953bcdab787"],"x":1305,"y":4180,"wires":[["fa873d7bccd2b6be"]]},{"id":"d80e5a54a7c5b2f8","type":"link out","z":"d4aa6dd5b63a56de","g":"b9029adc6097bd14","name":"link out 7","mode":"link","links":["c9de7384c9ca672f"],"x":2135,"y":4180,"wires":[]},{"id":"fb0c76a6934b0a7f","type":"ui-template","z":"d4aa6dd5b63a56de","g":"b9029adc6097bd14","group":"ec62d482d77f7908","page":"","ui":"","name":"Display the image on the Dashboard","order":6,"width":"3","height":"1","head":"","format":"<template>\n    <div>\n        <img :src= \"msg.paylaod\" alt=\"Image loaded from the filestore\" style=\"width:100%\"><br>\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1930,"y":4220,"wires":[["d80e5a54a7c5b2f8"]]},{"id":"4e4105a9774c7b5c","type":"ui-template","z":"d4aa6dd5b63a56de","g":"b9029adc6097bd14","group":"ec62d482d77f7908","page":"","ui":"","name":"Display the image on the Dashboard","order":5,"width":"3","height":"1","head":"","format":"<template>\n    <div>\n        <img :src= \"msg.paylaod\" alt=\"Image loaded from the filestore\" style=\"width:100%\"><br>\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1930,"y":4180,"wires":[["d80e5a54a7c5b2f8"]]},{"id":"917c842a1b46ad4c","type":"ui-template","z":"d4aa6dd5b63a56de","g":"b9029adc6097bd14","group":"ec62d482d77f7908","page":"","ui":"","name":"Display the image on the Dashboard","order":2,"width":0,"height":0,"head":"","format":"<template>\n    <div>\n        <img :src= \"msg.paylaod\" alt=\"Image loaded from the filestore\" style=\"width:100%\"><br>\n    </div>\n</template>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1930,"y":4140,"wires":[["d80e5a54a7c5b2f8"]]},{"id":"ec62d482d77f7908","type":"ui-group","name":"Default","page":"550c9ac3b2ed01c9","width":"6","height":"1","order":1,"showTitle":false,"className":"","visible":"true","disabled":"false"},{"id":"550c9ac3b2ed01c9","type":"ui-page","name":"Home","ui":"25f447d87d1ce5c9","path":"/","icon":"home","layout":"grid","theme":"c68088445147719b","breakpoints":[{"name":"Default","px":0,"cols":3},{"name":"Tablet","px":576,"cols":6},{"name":"Small Desktop","px":768,"cols":9},{"name":"Desktop","px":1024,"cols":12}],"order":1,"className":"","visible":true,"disabled":false},{"id":"25f447d87d1ce5c9","type":"ui-base","name":"Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-control","ui-notification"],"showPathInSidebar":false,"showPageTitle":false,"titleBarStyle":"default"},{"id":"c68088445147719b","type":"ui-theme","name":"Theme Name","colors":{"surface":"#ffffff","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"}},{"id":"1e54acecec6bd411","type":"group","z":"d4aa6dd5b63a56de","g":"596006fe79275d55","name":"Output a debug once all images have been processed","style":{"label":true},"nodes":["c9de7384c9ca672f","b073cd4970e6ddf2","c1b52f44fd4260b3"],"x":1254,"y":4279,"w":392,"h":82},{"id":"c9de7384c9ca672f","type":"link in","z":"d4aa6dd5b63a56de","g":"1e54acecec6bd411","name":"link in 7","links":["d80e5a54a7c5b2f8"],"x":1295,"y":4320,"wires":[["b073cd4970e6ddf2"]]},{"id":"b073cd4970e6ddf2","type":"join","z":"d4aa6dd5b63a56de","g":"1e54acecec6bd411","name":"","mode":"auto","build":"object","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":"false","timeout":"","count":"","reduceRight":false,"x":1380,"y":4320,"wires":[["c1b52f44fd4260b3"]]},{"id":"c1b52f44fd4260b3","type":"debug","z":"d4aa6dd5b63a56de","g":"1e54acecec6bd411","name":"debug 141","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1530,"y":4320,"wires":[]},{"id":"99aaee673fc70bc2","type":"group","z":"d4aa6dd5b63a56de","g":"596006fe79275d55","name":"Inject the image files' names","style":{"label":true},"nodes":["11787d1ab6c8a9ec","49b8f3cce48dd5a9","a9958e1e4b07191a","c452f250e1303c69","08b30802899573a6"],"x":1254,"y":3759,"w":782,"h":122},{"id":"11787d1ab6c8a9ec","type":"inject","z":"d4aa6dd5b63a56de","g":"99aaee673fc70bc2","name":"Inject","props":[],"repeat":"","crontab":"","once":true,"onceDelay":"1","topic":"","x":1350,"y":3800,"wires":[["c452f250e1303c69"]]},{"id":"49b8f3cce48dd5a9","type":"split","z":"d4aa6dd5b63a56de","g":"99aaee673fc70bc2","name":"","splt":"\\n","spltType":"str","arraySplt":1,"arraySpltType":"len","stream":false,"addname":"","property":"payload","x":1910,"y":3800,"wires":[["a9958e1e4b07191a"]]},{"id":"a9958e1e4b07191a","type":"link out","z":"d4aa6dd5b63a56de","g":"99aaee673fc70bc2","name":"link out 4","mode":"link","links":["2836914f9b643e34"],"x":1995,"y":3800,"wires":[]},{"id":"c452f250e1303c69","type":"change","z":"d4aa6dd5b63a56de","g":"99aaee673fc70bc2","name":"Image file names as an array","rules":[{"t":"set","p":"payload","pt":"msg","to":"[\"ff-logo-wordmark-light_4x.png\",\"screen-pseudo-overview-2QvTVle3Mr-384.avif\",\"nr-image-1.png\"]","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":1720,"y":3800,"wires":[["49b8f3cce48dd5a9"]]},{"id":"08b30802899573a6","type":"ui-event","z":"d4aa6dd5b63a56de","g":"99aaee673fc70bc2","ui":"25f447d87d1ce5c9","name":"Update images on dashboard open","x":1420,"y":3840,"wires":[["c452f250e1303c69"]]}]
```
::

I have also included some simple dashboard elements you can view alongside the images. Let's take a look at the dashboard:

:video{ariaLabel="The dashboard showing our images alongside other standard elements" autoPlay="true" height="656" loop="true" muted="true" playsInline="true" preload="none" width="646"}

If you import these flows into Node-RED, you should see the images automatically loaded into the dashboard when you view it. You can also replace the URLs and file paths to try using some different images if you'd like to.

## More things to try

In this example, the images are static but it's simple to load images depending on the state of the flow. As mentioned in this article's introduction, you could display context aware images guiding the user of the dashboard to a specific location on a map, to complete a maintenance task. If you're interested in seeing examples of dynamic image loading please comment below.

## Conclusion

Images can significantly enhance dashboards, but ensuring their proper display in different Node-RED hosting environments, especially within DevOps pipelines, can be challenging. The techniques discussed here enable effective use of images in dashboards, even within containerized setups. Additionally, if you are using FlowFuse, the new features simplify adding and managing static assets.
I'd love to hear your comments and suggestions on this article. please tell us what you think about this article, and how you might use these techniques in the comments section below.


# Creating a Historical Data Dashboard with InfluxDB and Node-RED

Every new dashboard is met with the fast-following request, “can we save this data and somehow look back on it?” Yes, you can, and let’s use InfluxDB to make it happen!

:product-update-note

Edge devices are often polling sensors at regular intervals and are a perfect candidate to be paired with a database purpose-built for time-series data, like InfluxDB. Let’s capture some data, create a live chart, store the data, and then create a GUI for retrieving the data.

Here’s a screenshot of the dashboard we will create, which is divided into two sections. The first section displays live data, while the second section consists of fields that enable users to query the database and retrieve historical data. Looking at the live data, the chart depicts a sinusoidal graph that represents the scale measurements used for quality assurance in the aggregate production process at an automated mining operation. The graph showcases fluctuations in weight over time, indicating variations in the samples being weighed. This monitoring process ensures the quality and consistency of the aggregates being produced. The historical data shows a snippet of this information that was retrieved from InfluxDB.

!["Screenshot showing the historical dashboard"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/dashboard-1.png "Screenshot showing the historical dashboard")

:br

Here is a screenshot of the simple Node-RED flow to create that dashboard. We will dive into the details through this article, and, by the end, you will be able to create this flow yourself.

![Screenshot showing the historical dashboard flow](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/flow-2.png "Screenshot showing the historical dashboard flow")

## Capturing serial port data

The live view is fed by data coming from a simple scale with a serial interface. This [Brecknell LPS-150](https://www.brecknellscales.com/wp-content/uploads/2022/09/LPS-Series_u_en_fr_501724-1.pdf){rel="&#x22;nofollow&#x22;"} scale will auto power-on, remembers the last tare setting, and continuously sends its reading via RS-232, so it is a great unit to use for unattended IoT projects.

On the Node-RED side, a serial node can be configured to capture this incoming data. If your device running Node-RED doesn’t have an RS-232 port, there are many variations of RS-232-to-USB cables to help you connect. This scale is sending data at a very high-speed interval so it is important to use a “delay” node before the rest of your flow gets bogged down.

Below, I have configured the serial port node with the same settings that were used to set up the scale. These settings are commonly documented as "9600 8N1" in shorthand. In serial communication it is necessary for the two devices to have the exact same settings or the data becomes garbled. The incoming stream of ASCII text is divided using the hex value 0x0D, which corresponds to the return character. This character is used as a delimiter to separate the individual chunks of text within the incoming data stream.

!["Screenshot showing the serial port node config"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/serial-port-node-3.png "Screenshot showing the serial port node config")

:br

With this “delay” node, we now have a new message from the scale at a rate of 1 msg per 5 seconds

!["Screenshot showing the delay node properties tab"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/delay-4.png "Screenshot showing the delay node properties tab")

:br

The debugger allows us to see the raw data as it is captured.

!["Debugger"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/debugger-5.png "Debugger")

:br

Unfortunately, these values are not in a friendly form to work with. Ideally, we want our payload to just be a number, not this string with odd characters, extra spaces, and the units.

!["Screenshot showing the change node setting payload"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/change-node-6.png "Screenshot showing the change node setting payload")

:br

:cta-image{alt="Power Workplace relies on FlowFuse for scalability, reliability and security audits - book a demo" cta="demo" src="https://flowfuse.com/images/cta/power-workplace-book-demo.png"}

We need to extract the numeric part of the string using a regular expression with a “change” node and the JSONata expression `$number($match(msg.payload, /-?(\d+(\.\d+)?)/, 10).match)`. `$match` and `/-?(\d+(\.\d+)?)/` help the function pull out the numeric components of the string and `$number` parses these components to be an actual number data type.

Here are the properties of the “change” node.

When we look in the debugger we see the payload specified as a “number” and the value displayed in blue, both indications that we have successfully extracted the weight as the correct data type.

!["Screenshot showing the output type in the debug panel"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/number-7.png "Screenshot showing the output type in the debug panel")

## Setting up serverless InfluxDB in the cloud

Now we have some live data, let’s store it using InfluxDB. Below are the steps to set up an account with the InfluxDB free service. Navigate to <https://www.influxdata.com/products/influxdb-overview/>{rel="&#x22;nofollow&#x22;"} and let’s begin. Click on “Get Started for Free” under Cloud, InfluxDB Cloud Serverless.

!["Screenshot showing the Influxdb cloud 'Getting started' button"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/run-influxdb-8.png "Screenshot showing the Influxdb cloud 'Getting started' button")

For this example the Free plan will work fine.

!["Screenshot showing the influxdb cloud tiers"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/free-influxdb-9.png "Screenshot showing the influxdb cloud tiers")

Create a bucket to store the data.

!["Screenshot showing the 'Go to buckets' button"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/bucket-influxdb-10.png "Screenshot showing the 'Go to buckets' button")

!["Screenshot showing the 'Create Bucket' button"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/load-data-influxdb-11.png "Screenshot showing the 'Create Bucket' button")

Generate a token to direct the calls from Node-RED to your InfluxDB account when they hit the InfluxDB server:

!["Screenshot showing the 'Genrate token' button"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/token-influxdb-12.png "Screenshot showing the 'Genrate token' button")

I selected “Generate All Access API Token,” but eventually you will want a custom, more restricted approach.

!["Screenshot showing the 'prompt' asing to enter the description for token"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/generate-token-influxdb-13.png "Screenshot showing the 'prompt' asing to enter the description for token")

Copy your token and do not share it! (mine will be deleted later)

## Connecting Node-RED to InfluxDB

Navigate to “Manage Palette” in the Node-RED hamburger menu in the upper right corner of the flow editor. I did a search for InfluxDB and selected the most popular one, “node-red-contrib-influxdb” by looking at the number of downloads per week at <https://flows.nodered.org/node/node-red-contrib-influxdb>{rel="&#x22;nofollow&#x22;"}. When you are just starting out, it can be a smart decision to go with the popular option. The popularity indicates a level of trust and adoption within the community, making it a reliable choice for beginners

!["Screenshot showing the influxdb node in the manage palette"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/install-contrib-influxdb-14.png "Screenshot showing the influxdb node in the manage palette")

:br

After installing this package you will see three new nodes in your flow editor.

![Screenshot showing the installed influxdb nodes in the palette](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/influxdb-nodes-15.png "Screenshot showing the installed influxdb nodes in the palette")

Drag and drop the “influxdb out” node into your flow, double click on it, and start filling out the needed fields. The naming convention of `test&lt;<THING>>` works well for initial setups to make it clear what names should go where.

!["Screenshot showing the influxdb-out node config"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/influxdb-out-node-16.png "Screenshot showing the influxdb-out node config")

:br

It was a little unclear what URL to use with this serverless option, but I guessed it was the same as the URL for the InfluxDB resource center account page, “<https://us-east-1-1.aws.cloud2.influxdata.com/>{rel="&#x22;nofollow&#x22;"}” and it worked. Then, enter the API token that was generated earlier.

!["image\_tooltip"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/influxdb-node-17.png "image_tooltip")

:br

The “influxdb out” node is now ready to start storing payloads. The documentation for the InfluxDB nodes at <https://flows.nodered.org/node/node-red-contrib-influxdb>{rel="&#x22;nofollow&#x22;"} gives more detail as to extra options, such as tags, that you might want to attach to your data being stored. In this simple example, we are just going to send the “influxdb out” node a number via the msg.payload.

![Screenshot showing the flow sending data to InfluxDB and to a dashboard chart widget"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/flow-influxdb-out-18.png "Screenshot showing the flow sending data to InfluxDB and to a dashboard chart widget")

:br

Here is a chart of the live data which is also being stored.

!["Screenshot showing the dashboard with live data chart"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/live-data-chart-19.png "Screenshot showing the dashboard with live data chart")

:br

The InfluxDB Data Explorer helps you create a SQL call and allows you to run it right in the browser so you can verify that your data is being stored correctly.

!["Screenshot showing the InfluxDB Explorer"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/influxdb-explorer-20.png "Screenshot showing the InfluxDB Explorer")

:br

## Creating a historical data GUI

Now we have our data being stored, but we aren’t quite finished. We still want an easy way to pull this information up and for it to be presented in a chart, just like the live data.

Here is the Dashboard group we will create for this GUI.

!["Screenshot showing the GUI for historical data"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/historical-data-21.png "Screenshot showing the GUI for historical data")

And here is the flow to create it.

!["Screenshot showing the flow of historical data GUI."](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/data-flow-22.png "Screenshot showing the flow of historical data GUI")

A “template” node creates a convenient way to create a plain text output with variable properties within. Below you can see that `msg.query` is created from a string of text with “rangeStart” and “rangeEnd” dynamically inserted using the “mustache” syntax. More information about how to query InfluxDB can be found here: <https://docs.influxdata.com/influxdb/v2.0/query-data/get-started/query-influxdb/>{rel="&#x22;nofollow&#x22;"}.

!["Screenshot showing the template node"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/template-node-23.png "Screenshot showing the template node")

:br

Using the "Form" dashboard node is an easy way to collect all the required information for our query. We need to be able to enter in a date and time to start gathering the data, and a window to know how long a range of values to pull.

!["Screenshot of the form widget"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/form-node-24.png "Screenshot of the form widget")

Here is the code from the “time/date” function node. A bit of juggling of local time versus UTC time is needed to allow the user to intuitively query the correct data for their timezone.

!["Screenshot of the function node properties tab"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/function-node-25.png "Screenshot of the function node properties tab")

:br

Here is the “change” node used to create the msg.rangeEnd. The JSONatta expression is `$fromMillis($toMillis(msg.rangeStart) + msg.payload.window * 60 * 1000)`. The expression combines the milliseconds from the `msg.rangeStart` with the calculated milliseconds in the “Window (minutes)” from the GUI.

!["Screenshot of the change node properties tab"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/change-node-26.png "Screenshot of the change node properties tab")

:br

Now that the query is coming back from InfluxDB, let’s break down how to transform this data object into one that can be read by the “chart” node. Below, we see on the left column what the object looks like from InfluxDB and on the right we see how it must be structured to be viewed in the chart.

!["Screenshot showing the formated data in the debug panel"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/data-format-27.png "Screenshot showing the formated data in the debug panel")

Rob Marcer has a great article on working with persistent chart data found here: [/blog/2023/05/persisting-chart-data-in-node-red/](https://flowfuse.com/blog/2023/05/persisting-chart-data-in-node-red/).

We can use a series of nodes from the Node-RED core package to transform this data.

!["Screenshot showing the flow to transform the data"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/transform-data-28.png "Screenshot showing the flow to transform the data")

:br

First, a “switch” node is used to determine if the response InfluxDB contains any data so that we can either format the data properly, or clear the chart and indicate “No Data.”

!["Screenshot of the switch node properties tab"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/switch-node-28.png "Screenshot of the switch node properties tab")

:br

The “Label” field in the “chart” node can also be dynamically created with the mustache syntax.

!["Screenshot of the chart widget setting label dynamically"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/chart-node-29.png "Screenshot of the chart widget setting label dynamically")

:br

If the “is not empty” “switch” node sees an empty payload, this “change” node sets the payload to an empty array, clearing the chart, and sets the `msg.title` to “No Data” so users know their query, though successful, returned an empty set of values.

!["Screenshot of the change node properties tab"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/change-node-30.png "Screenshot of the change node properties tab")

:br

The parameters for the “split” node can be left as-is.

!["Screenshot of the split node properties tab"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/split-node-31.png "Screenshot of the split node properties tab")

:br

In the “chartData” “change” node, will pull out the two values we need for the chart, milliseconds since the UNIX epoch for the x-value and the measurement from the scale for the y-value. A simple JSONatta expression helps us transform the date from a string to milliseconds for the x-value.

!["Screenshot of the change node properties tab"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/change-node-32.png "Screenshot of the change node properties tab")

:br

The “join” node just needs to be set to “Combine each” msg.chartData object and configured “to create” an array.

!["Screenshot of the join node properties tab"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/join-node-33.png "Screenshot of the join node properties tab")

:br

The final “change” node, “format,” is where we prescribe the format needed for the “chart” node, [{"series": [""],"data":\[\[]],"labels": [""] }], and finally we insert our `msg.chartData` array into that structure. Notice `msg.title` is now set to “Data Received.”

!["Screenshot of the change node properties tab"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/change-node-33.png "Screenshot of the change node properties tab")

:br

And, there you have it. You can query the same range of data found on the live chart to ensure the code is working and then you can use the dashboard to pull up historical data, way in the past from what is shown on the live chart.

!["Screenshot of the dashboard showing the historical and live data chart"](https://flowfuse.com/blog/2023/07/images/influxdb-historical-data/final-dashboard-34.png "Screenshot of the dashboard showing the historical and live data chart")

Your current version is clear and concise, great for a blog or call-to-action section. Here's a slightly refined version with improved flow, punctuation, and tone for polish, while keeping the structure intact:

## Final Thoughts

You’ve successfully built a powerful dashboard that captures real-time data and stores it in InfluxDB for historical analysis. This setup provides valuable insights into your process data and helps identify trends over time.

If you are planning to run this dashboard in production, a few important questions may come to mind: How do you ensure it runs reliably 24/7? How do you deploy it to other locations? What happens if someone accidentally breaks the flow?

This is where **FlowFuse** comes in. It takes your existing Node-RED flows and adds:

- Automatic backups and instant recovery
- Easy deployment to multiple locations
- Version control for safe and trackable updates
- Team collaboration without conflicts
- Remote instance management, and much more

Your flows continue to work just as they are, FlowFuse simply makes them production-ready.

[Try FlowFuse free for 30 days](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and see how it transforms Node-RED into a scalable, enterprise-ready platform.


# FlowFuse is now available on AWS Marketplace

Many customers want to run FlowFuse in their own cloud environment, AWS being a great example. Today we're excited to announce that FlowFuse is now available from the [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-3ycrknfg67rug?sr=0-1&ref_=beagle&applicationId=AWSMPContessa){rel="&#x22;nofollow&#x22;"}. This makes it very easy for customers to install and run Node-RED and FlowFuse within minutes.

FlowFuse allows organizations to reliably deliver Node-RED applications in a continuous, collaborative and secure manner. Customers running FlowFuse on AWS Cloud will benefit from FlowFuse's features, including:

- Team collaboration for Node-RED developers, allowing multiple developers to work together on a single Node-RED instance, including the ability to have an audit log of changes.
- DevOps deliver pipelines that support a software development lifecycle for Node-RED development. Pipelines can be setup to establish development, test and production environments for Node-RED instances.
- Snapshot of Node-RED instances to create a version history of changes to Node-RED applications. This also includes the ability to rollback to a previous version of a Node-RED instance.

FlowFuse on the AWS Marketplace is available under the Apache License c2.0 open source license. Customers can use FlowFuse free of charge but will need to pay AWS EC2 usage for hosting FlowFuse. FlowFuse offers commercially licensed Premimum and Enterprise tiers that includes enterprise oriented features, including:

- 24/7 technical support
- Single Sign-on
- High Availability for Node-RED applications
- Remote device management

Customers can easily upgrade to the premium or enterprise tier by obtaining a commercial license from FlowFuse. To understand what FlowFuse can do for your use-case, please [book a demo](https://flowfuse.com/book-demo).

FlowFuse on AWS Marketplace is available [immediately](https://aws.amazon.com/marketplace/pp/prodview-3ycrknfg67rug?sr=0-1&ref_=beagle&applicationId=AWSMPContessa){rel="&#x22;nofollow&#x22;"}. Please refer to our [documentation](https://flowfuse.com/docs/install/docker/aws-marketplace/#installing-flowfuse-from-aws-market-place) and give it a try and let us know what you think.


# Community News August 2023

Welcome to the FlowFuse newsletter for August 2023, a monthly roundup of what’s been happening with FlowFuse and the wider Node-RED community.

## New Release

Last week we released FlowFuse 1.10, featuring improvements to our device management solutions and the new ability to import environment variable templates. Read about the details of FlowFuse 1.10 in our [release announcement](https://flowfuse.com/blog/2023/08/flowforge-1-10-release/).

## Upcoming events

### Getting Started with OPC-UA and Node-RED

OPC-UA is a popular communication protocol used to communicate industrial data between different types of hardware and software. Our next webinar show how to use Node-RED to create an OPC-UA client that can read OPC data and visualize the data in Node-RED. We are glad to welcome Mika Karaila, Research Director @ Valmet Automation and creator of the OPC-UA nodes, as our webinar speaker.

[Sign-up today](https://flowfuse.com/webinars/2023/getting-started-opcua-node-red/) to join us on July 27.

## From our Blog

- Our developer advocate, Richard Meyer, published a series of articles on OPC-UA:
  - Part 1: [How to Deploy a Basic OPC-UA Server in Node-RED](https://flowfuse.com/blog/2023/07/how-to-deploy-a-basic-opc-ua-server-in-node-red/)
  - Part 2: [How to Build a Secure OPC-UA Server for PLCs in Node-RED](https://flowfuse.com/node-red/protocol/opc-ua/)
  - Part 3: [How to Build an OPC UA Client Dashboard in Node-RED](https://flowfuse.com/blog/2023/07/how-to-build-a-opc-client-dashboard-in-node-red/)
- [First Pre-Alpha Release of the new Node-RED Dashboard](https://flowfuse.com/blog/2023/07/dashboard-0-1-release/) - update on FlowFuse's work to develop the next generation of Node-RED dashboard.
- [How to add images to Node-RED dashboards when using FlowFuse](https://flowfuse.com/blog/2023/07/images-in-node-red-dashboards/) - some tips on how to add images to a dashboard when running Node-RED instances in a docker environment, like FlowFuse.
- [Creating a Historical Data Dashboard with InfluxDB and Node-RED](https://flowfuse.com/blog/2023/07/influxdb-historical-data/) - an in-depth article on how to store historical data in InfluxDB that can be visualize with Node-RED dashboard.

## From the Community

- **Featured Node**: [Buffer Parser](https://flows.nodered.org/node/node-red-contrib-buffer-parser){rel="&#x22;nofollow&#x22;"} - a really useful node for parsing buffers/arrays that are common in industrial data.

## Join Our Team

FlowFuse is expanding our team. Check out the current openings:

- [Contract Front-End Engineer – Node-RED Dashboard](https://boards.greenhouse.io/flowfuse/jobs/4911532004){rel="&#x22;nofollow&#x22;"}


# Dashboard 2.0 - Community Update

Welcome to the latest Node-RED Dashboard 2.0 update. We've added lots of new widgets, cleaned up compatibility issues alongside Dashboard 1.0 and made strides to improve the events system linking the Node-RED editor with the Dashboard.

I firstly need to begin with a &#x2A;"Thank You"* to the dozens of pre-alpha users we've had so far. Thanks for being patient whilst we're shipping fast and breaking things. We've had some great feedback, and we're working hard to implement is as best as possible.

With all of the changes we've been making, we've also made the decision to jump to minor version numbers, and so, **0.1.0 is available now**.

Below you'll find a summary of the changes we've made since our [last community update](https://flowfuse.com/blog/2023/07/dashboard-0-1-release).

## New Widgets

### Template ([docs](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html))

Steve has been doing some incredible work on the new `ui-template` widget. This widget allows you to create your own custom components using raw HTML, but also works with any of the components in the [Vuetify](https://vuetifyjs.com/en/components/all/){rel="&#x22;nofollow&#x22;"} component library. It's a powerful tool that will enable users to be creative with their own widgets that are not currently available with the standard set of widgets.

![Examples of ui-template](https://dashboard.flowfuse.com/images/node-examples/ui-template.png)

The Template node also provides access to two built-in functions that can be used to send data back to Node-RED:

- **send(msg)**: Outputs a message (defined by the input to this function call) from this node in the Node-RED flow.
- **submit()**: Send a `FormData` object when attached to a `<form>` element. The created object will consist of the `name` attributes for each form element, corresponding to their respective `value` attributes.

### Toggle Switch ([docs](https://dashboard.flowfuse.com/nodes/widgets/ui-switch.html))

![Examples of ui-switch](https://dashboard.flowfuse.com/images/node-examples/ui-switch.png)

Adds a toggle switch to the user interface that can be rendered with a label, and traditional toggle switch, or, as in Dashboard 1.0, can be a square element with an icon & color provided.

## Fixes & Other Changes

### Sidebar

As requested on multiple occasions by the community when we released v0.0.4 of Dashboard 2.0, we've now added a side menu, as per Dashboard 1.0. Currently, this *just* provides a link to the Dashboard UI, but gives us a canvas on which to expand functionality in the future.

### Improved Events System

We've re-structured the hierarchy of the events system to make it more streamlined. Now, the `ui-base` manages comms via single channels dedicated to each event type, and the widget's ID is then used as a topic. Previously, we had a separate channel for each `action:id`.

If you're interested in learning more about our events architecture, you can read about it [here](https://dashboard.flowfuse.com/contributing/guides/events.html){rel="&#x22;nofollow&#x22;"} in the docs.

### Documentation Updates

It's not glamorous, but it's important. We've made sure that all documentation and help text inside Node-RED is fully up to date for the Dashboard 2.0 nodes. We've also include rendered examples for all widgets in our [online documentation](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"} too.

We've also made sure that any legacy options that had been transferred over from Dashboard 1.0 that haven't been fully implemented yet are temporarily hidden. This means, any options you're seeing, *should* be working. If they're not - it's a bug.

## What's Next?

We have a lot of things to keep us busy, we are documenting them all in GitHub, and have made public our [planning board](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}. You can see what we're working on, what's coming up next, and what we've got planned for the future.

As always, we're open to ideas, feedback & contributions. If you'd like to get involved, please check out our GitHub Repository [here](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.

## Join Our Team

If you'd like to be paid to directly contribute to Dashboard 2.0, we are hiring for a 2-3 month position to do just that:

- [Contract Front-End Engineer – Node-RED Dashboard](https://boards.greenhouse.io/flowfuse/jobs/4911532004){rel="&#x22;nofollow&#x22;"}


# FlowFuse 1.10 Release Now Available

FlowFuse 1.10 release includes improvements to device management and importing environment variable templates.

## Import Environment Variable Templates [#2372](https://github.com/FlowFuse/flowfuse/issues/2372){rel="&#x22;nofollow&#x22;"}

FlowFuse 1.10 now allows users to import environment variable templates. This makes it much easier and less error prone to maintain and add new environment variables to Node-RED instances running on FlowFuse.

## DevOps Pipelines now can include devices [#2243](https://github.com/FlowFuse/flowfuse/issues/2243){rel="&#x22;nofollow&#x22;"}

DevOps pipelines have proven very popular for creating dev/test/production environments for Node-RED flow development. Now, devices can be associated with a pipeline so when a snapshot is created it can be pushed to all the devices associated with the pipeline. This will improve the overall quality and reliability of Node-RED development for remote devices.

## Devices can now access the team library [#2294](https://github.com/FlowFuse/flowfuse/issues/2294){rel="&#x22;nofollow&#x22;"}

Team libraries allow Node-RED development team to share common flows and nodes through a shared library. Until the 1.10 release, Node-RED running remotely on a device did not have access to the team library. This limitation is now removed so device development can benefit from reusing standard flows.

## Other New Features

- Add description of device type field [#2428](https://github.com/FlowFuse/flowfuse/issues/2428){rel="&#x22;nofollow&#x22;"}
- Improve reliability of device editor [#2483](https://github.com/FlowFuse/flowfuse/issues/2483){rel="&#x22;nofollow&#x22;"}
- Improve error feedback from device editor tunnel [#2473](https://github.com/FlowFuse/flowfuse/issues/2473){rel="&#x22;nofollow&#x22;"}

## Bug Fixes

- Improve visualization of Last Seen & Last Known with large amounts of devices. [#2380](https://github.com/FlowFuse/flowfuse/issues/2380){rel="&#x22;nofollow&#x22;"}
- Fix billing information error in FlowFuse Cloud [#2416](https://github.com/FlowFuse/flowfuse/issues/2416){rel="&#x22;nofollow&#x22;"}
- Fix T\&C checkbox on sign-up page [#2419](https://github.com/FlowFuse/flowfuse/issues/2419){rel="&#x22;nofollow&#x22;"}

## Community Contributions

Thanks to our community members for their contributions to this release.

- [dfulgham](https://github.com/dfulgham){rel="&#x22;nofollow&#x22;"} - Added support for annotation substitutions [#95](https://github.com/FlowFuse/flowforge-driver-k8s/pull/95){rel="&#x22;nofollow&#x22;"}
- [elanaviter](https://github.com/elenaviter){rel="&#x22;nofollow&#x22;"} - Editors: allow optional service account linkage [#92](https://github.com/FlowFuse/flowforge-driver-k8s/pull/92){rel="&#x22;nofollow&#x22;"}

## What's next?

We're always working to enhance your experience with FlowFuse. Here's how you can stay informed and contribute:

- **Roadmap Overview**: Check out our [Product Roadmap Page](https://flowfuse.com/changelog/) to see what we're planning for future updates.
- **Entire Roadmap**: Visit our [Roadmap on GitHub](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"} to follow our progress and contribute your ideas.
- **Feedback**: We're interested in your thoughts about FlowFuse. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try it out

We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.10.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go the the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# FlowForge is now FlowFuse

We are happy to announce that FlowForge is changing its name to FlowFuse. Changing our corporate identity wasn’t our top priority but a recent trademark challenge has promoted us to create a new brand for our company.

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

We believe that this new name better reflects our core mission and aspirations. Just as electricity fuses elements to create energy, the FlowFuse platform fuses together data, ideas, processes, and technologies to generate a powerful force of innovation and transformation.

Selecting a new name for a company or product is never easy. Some of the requirements we set for a new name were: 1) it should be reasonably close to FlowForge so it will be easier to transition the brand identity, 2) it should even better reflect our mission, and 3) keeping the FF acronym will help with environment variable prefixes :-). I think we have accomplished all the above and am delighted to move forward as FlowFuse.

**What to Expect Next**

Our team is heads down building a platform to allow organizations to reliably deliver Node-RED applications in a continuous, collaborative, and secure manner. We'll continue to release regular updates packed with new features and enhancements that keeps moving us towards this goal.

A complete rebranding is a big piece of work - today marks the start of a process as we introduce the new FlowFuse name and updated [website](https://flowfuse.com). Over the next number of days and weeks we'll continue to roll this change out, including our social media accounts and other accounts. The product branding will be changed over the next couple of releases, including FlowForge Cloud and FlowForge open source edition. The underlying software will be the as-if you’re running the next FlowForge release, though now called FlowFuse. We'll share more technical details of this when any changes are made.

We are excited by the future FlowFuse presents to our customers and the industry. Node-RED and FlowFuse is a powerful combination that gives access to industrial data to transform organizations and drive forward innovation across industries. Join us as we continue our journey.


# FlowFuse 1.11 makes it easier to get started with FlowFuse and Node-RED

FlowFuse 1.11 introduces a new starter tier for FlowFuse Cloud that makes it easier to get started with FlowFuse and Node-RED.

:product-update-note

## New FlowFuse Cloud Starter Tier [#2328](https://github.com/FlowFuse/flowfuse/issues/2328){rel="&#x22;nofollow&#x22;"}

It is now easier for Node-RED developers to get started with FlowFuse and Node-RED. The new starter tier allows developers to use two Node-RED instances and two remote device deployments. Ideal for creating proof of concepts or running a home automation system with Node-RED.

FlowFuse provides a cloud hosted version of Node-RED so developers don't need to worry about Node-RED installation or operation. This makes it a lot easier to get started with Node-RED and easier to maintain a running instance.

## FlowFuse API access now possible via personal access tokens [#14](https://github.com/FlowFuse/flowfuse/issues/14){rel="&#x22;nofollow&#x22;"}

FlowFuse APIs are now accessible via personal access tokens (PAT). This makes it possible to create automation scripts that interact with the FlowFuse platform using the API and authenticate the scripts with the PAT.

## Usability Improvements to Device Management [#2294](https://github.com/FlowFuse/flowfuse/issues/2334){rel="&#x22;nofollow&#x22;"}

A number of usability improvements have been added to the FlowFuse device management solution to make it more flexible and intuitive to use. These improvements include being able to associate devices at the application level allowing for easier editing of Node-RED instances on edge devices.

## FlowFuse Rebranding [#119](https://github.com/orgs/FlowFuse/projects/1?pane=issue&itemId=34719640){rel="&#x22;nofollow&#x22;"}

Earlier in August, [FlowForge announced](https://flowfuse.com/blog/2023/08/flowforge-is-now-flowfuse/) a change to our company and product name to FlowFuse. Work has begun to change the product branding to FlowFuse. The UI has been rebranded and the remaining points will be changed in the next release.

## Other New Features

- Add ability to add a description to an application and display it in the portal [#2279](https://github.com/FlowFuse/flowfuse/issues/2279){rel="&#x22;nofollow&#x22;"}
- UI Improvements to device management [#2427](https://github.com/FlowFuse/flowfuse/issues/2427){rel="&#x22;nofollow&#x22;"}
- Improve landing page for documentation [#842](https://github.com/FlowFuse/website/issues/842){rel="&#x22;nofollow&#x22;"}
- Restructure of user interface navigation [#2474](https://github.com/FlowFuse/flowfuse/issues/2474){rel="&#x22;nofollow&#x22;"}

## Bug Fixes

- Device running old snapshot [#132](https://github.com/FlowFuse/device-agent/issues/132){rel="&#x22;nofollow&#x22;"}

## What's next?

We're always working to enhance your experience with FlowFuse. Here's how you can stay informed and contribute:

- **Roadmap Overview**: Check out our [Product Roadmap Page](https://flowfuse.com/changelog/) to see what we're planning for future updates.
- **Entire Roadmap**: Visit our [Roadmap on GitHub](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"} to follow our progress and contribute your ideas.
- **Feedback**: We're interested in your thoughts about FlowFuse. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try it out

We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 1.11.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go to the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# Why the Automation Pyramid blocks digital transformation - The Role of Unified Namespace

A few years ago, I wrote an [article](https://www.linkedin.com/pulse/iiot-circle-marian-raphael-demme/){rel="&#x22;nofollow&#x22;"}, in German, detailing my understanding of how the Automation Pyramid, a widely adopted reference model for the IT landscape of manufacturing firms, is essentially hindering digital transformation. Now, as conversations around the Unified Namespace (UNS) and particular frameworks continue to evolve, I revisit my earlier notions, review the latest updates to reference frameworks, and update my article.

## The Pyramid’s Dilemma

The Automation Pyramid is grounded in the standard [ISA-95](https://www.isa.org/products/ansi-isa-95-00-01-2010-iec-62264-1-mod-enterprise){rel="&#x22;nofollow&#x22;"}, which aligns with [IEC 62264](https://www.iso.org/standard/57308.html){rel="&#x22;nofollow&#x22;"} and [DIN EN 62264](https://www.beuth.de/en/standard/din-en-62264-1/207270059){rel="&#x22;nofollow&#x22;"}. It delineates the functional hierarchy within a manufacturing enterprise. Over 25 variations of the Automation Pyramid exist in academic literature, all of them fundamentally mapping to the same core concept, tracing back to the [Computer-integrated manufacturing](https://en.wikipedia.org/wiki/Computer-integrated_manufacturing){rel="&#x22;nofollow&#x22;"} (CIM)-Pyramid of the 1970s. Although ISA-95 does not explicitly refer to a pyramid, it introduces five functional hierarchical levels often visualized as a pyramid.

#### ISA-95 - Visualization

![ISA95](https://flowfuse.com/blog/2023/08/images/UNS/ISA95.svg)

#### Automation Pyramid - Visualization

![Automation Pyramid](https://flowfuse.com/blog/2023/08/images/UNS/Automation-Pyramid.png)
Source: Katti, Badarinath. (2020). Ontology-Based Approach to Decentralized Production Control in the Context of Cloud Manufacturing Execution Systems. 10.13140/RG.2.2.11486.46402.

A notable critique of ISA-95 is the absence of some operational functions and hierarchical levels commonly seen in manufacturing, leading to a rigidity that limits its applicability. This inflexibility has been acknowledged in a more recent framework, called the ["Reference Architectural Model Industry 4.0"](https://www.isa.org/intech-home/2019/march-april/features/rami-4-0-reference-architectural-model-for-industr){rel="&#x22;nofollow&#x22;"} RAMI 4.0 ([IEC PAS 63088](https://www.beuth.de/en/norm/pd-iec-pas-63088/272832590){rel="&#x22;nofollow&#x22;"}). As a result, the authors' introduced a ["Smart Grid Architecture Model"](https://syc-se.iec.ch/wp-content/uploads/2019/10/Reference_Architecture_final.pdf){rel="&#x22;nofollow&#x22;"} (SGAM) with three primary dimensions: Life Cycle & Value Stream ([IEC 62890](https://www.vde-verlag.de/iec-normen/248992/iec-62890-2020.html){rel="&#x22;nofollow&#x22;"}), Hierarchy Levels ([IEC 62264](https://www.iso.org/standard/57308.html){rel="&#x22;nofollow&#x22;"} and [IEC 61512](https://www.vde-verlag.de/iec-normen/216764/iec-61512-4-2009.html){rel="&#x22;nofollow&#x22;"}), and six main layers displaying the functional architecture of the asset and the separation into physical and digital world.

:video{ariaLabel="RAMI4.0" autoPlay="true" height="292" loop="true" muted="true" playsInline="true" preload="none" width="520"}

However, my primary critique revolves around another issue – the structure and proposed communication methodology. Models based on layers, where each tier represents a functional area and could be covered by one or more applications, almost always lead to three fundamental problems:

### Problem 1: Information Loss and Transaction Costs

In the traditional model, data collection flows upward from Levels 0 to 4, while planning goes downward from Level 4 to 0. Information traversing from Level 0 to Level 4 has to pass through at least four stages. Despite the theoretical lossless transmission of information, the practical scenario inevitably results in some degree of information loss between levels. The result is that the original information from Level 0 arrives at Level 4 late, altered, or not at all.

**Example:** In a manufacturing plant, multiple sensors at Level 1 detect a sudden event. By the time this information passes through intermediary layers (e.g. PLC, SCADA, MES) to reach Level 4 where a planning decision can be made, it is delayed and distorted due to the multiple transitions. The factory might suffer damage before proper actions are taken because the original data didn't arrive on time or at all.

### Problem 2: The Expense of One-to-One Connections

The Automation Pyramid is based on different layers. Consequently, one-to-one connections between IT systems become a necessity for data transfer between levels. For example, Level 3 IT systems need at least two connections to the adjacent levels. This can lead to thousands of one-to-one interfaces between IT systems, incurring exorbitant costs for projects and maintenance.

**Example:** In a semiconductor company, the Manufacturing Execution System (MES) serves as a critical intermediary in the Automation Pyramid. It must be integrated both with PLCs at the lower level for real-time control and with the ERP system at the higher level for business planning. This complex integration leads to the creation of numerous one-to-one connections. Furthermore, in implementing Industry 4.0 use cases like analytical applications, MES data is often required, creating even more connections. The multitude of connections complicates the system, making changes extremely difficult and maintenance intensive. This inflexibility becomes a barrier to adaptability and growth, hindering the efficient digital transformation of the manufacturing process.

### Problem 3: AI's Dependence on Data

Artificial intelligence (AI) requires extensive, well-organized data. Given the current architecture, data would have to be collected and prepared from case to case for each individual system and level. This would invariably lead to numerous new one-to-one connections, offering no flexibility. Hence, AI and the Automation Pyramid can only collaborate in a significantly restricted manner.

**Example:** A car manufacturing firm aims to leverage a neural network for predictive maintenance. Within the constraints of the existing Automation Pyramid's architecture, the positioning for such an application is nonexistent. To train the neural network and subsequently analyse the data, a consolidation of varying hierarchical data is essential, such as sensory input, maintenance records, production scheduling plans, etc. Under the current architecture, the introduction of this application precipitates the creation of a multitude of new one-to-one connections. Consequently, it underscores the pressing need to rethink the structural paradigms.

## IIoT Circle and Unified Namespace

To overcome the limitations of traditional industrial data architecture, a paradigm shift towards a modern distributed architecture is necessary. Rather than allowing data to exist in silos within and across layers of the technology stack, data should be made accessible in a unified manner, creating a single, centralized repository. This approach facilitates a single centralized source for all enterprise systems to access the required data for their operations. This framework, which I have been calling the IIoT Circle, modernizes the original idea of the Automation Pyramid. A "Unified Namespace" operates as the core element that processes, and permits data streams to be loaded and exported from other systems. All other applications communicate exclusively through the Unified Namespace, requiring only a single interface to be maintained per application.

![IToT Circle Image](https://flowfuse.com/blog/2023/08/images/UNS/IIoT-Circle.svg)

In essence, Unified Namespace serves as the main data exchange hub within an organization. It structures, organizes, and maintains a real-time flow of data from a variety of sources, becoming the indisputable source of truth across the business. It simplifies data integration, eliminating the frequently convoluted, layered approach of traditional data systems.

### Single Source of Truth

The Unified Namespace breaks down the linear and deterministic data structure, which create data silos restricted to their specific systems. Instead, Unified Namespace centralizes data from across the entire organization. This results in a 'single source of truth' - a consolidated, current, and comprehensive overview of the organization's data.

### The Organizational Structure

Unified Namespace organizes data using a semantic hierarchy, similar to a meticulously arranged file share system. It can use the [ISA-95 part 2](https://www.isa.org/products/ansi-isa-95-00-02-2018-enterprise-control-system-i){rel="&#x22;nofollow&#x22;"} or the RAMI 4.0 Hierarchy Level standards to structure the hierarchy. This data organization facilitates navigation, management, and decision-making.

### The Pub-Sub Approach

The Publish-Subscribe (Pub-Sub) model facilitates communication that decouples the sender (publisher) from the receiver (subscriber), providing an efficient communication protocol to avoid one-to-one connections. It offers flexibility and scalability as it allows for one-to-many and many-to-one communications, enabling data to flow freely between systems.

## A Necessity for Open Source

Moreover, in this discourse on the Unified Namespace, we cannot overlook the role of open-source. Owning foundational digital services, such as the Unified Namespace, is a necessity for any corporation embarking on its digital transformation journey. This ownership provides a solid foundation, allowing companies to chart their destinies. To avoid the constraining bounds of vendor lock-in, which can significantly limit a company's digital capabilities; open-source or self-developed software offers the best recourse. By its nature, open-source promotes transparency, collaboration, and freedom of use. These aspects are fundamental to fostering innovation and continuous improvement. As exemplified by the [MING Stack](https://flowfuse.com/blog/2023/02/ming-blog/), open source software can and should be incorporated into every level of the hierarchy.

## Summary – Advancing Current Standards

The lag of standards behind the latest innovation is an open secret, a problem rooted in the nature and development of these standards. However, maintaining and updating these standards remains crucial as many people adhere to them.

ISA-95 Part 6 mentions a Messaging Service Model (MSM) and proposes a "publish-subscribe" model as an option for transactions. This is a great step in the right direction. My recommendation for ISA-95 is to further develop Part 6 to clearly delineate the implementation pattern of the Unified Namespace. Additionally, ISA-95 Part 1 should make explicit references to the communication pattern detailed in Part 6 and transition from a layer model to a cycle, with the Unified Namespace as an integral part of the framework.

RAMI 4.0's Communication Layer is rather abstract. It suggests the use of OPC-UA for everything in manufacturing, from "Product" to "Work Center". For "Enterprise" and "Connected World", it states "still undecided". My improvement suggestion is to define the "Communication Layer" new and to be more technology-agnostic. Be more explicit about what needs to be done and more flexible about how to do it.


# Our Open Source offering is a tier, not our competition

More than once we’ve been in discussion with prospective customers on what tier
is the right tier for their current Node-RED adoption. The question is likely to
come up "Why wouldn't we just use the open source version of FlowFuse?". The
implicit discussion created is one that is alike the question:
“Why wouldn’t we go with your competition?”. For FlowFuse, and most other open-core
companies like us, the open licensed and free to use core is tier, not competition.

In the traditional sense, the prospective customer is right. By the definition,
a customer **buys** goods or services by exchanging it for **money**. For
FlowFuse’s open-source edition, which is free as in beer and free as in speech,
no money changes hands. It can be installed and run by anyone. Once the software
is being installed and used, we consider we've gained a new customer.
There’s an agreement in place, the Apache 2.0 license, and value is obtained by
the customer. The only missing component compared to an ‘ordinary’ sale is the lack
of money from the customer to FlowFuse. The fact that no monetary value is exchanged,
like the situation where a customer picks the competitor, doesn’t make the open
source tier competition. It is just a free tier.

Another reason it's really a tier is that the core of the product is the same. In
many open-core products, the path to upgrade from the open source license product to
the paid tier is much alike customers are used to on SaaS models. In the reals of
self-managed software that's mostly uploading a license and at times a few configuration
steps.

Furthermore, the open tier is a tier as the customer choses to not adopt all
capabilities. They're leaving value on the table. Either this is because it's not
quite clear what the value is or if the higher tiers provides
enough business value to warrant the expense. Or the adoption journey for the
customer doesn't yet require the full featured tiers.

What’s unique about open source software, is that customers can exchange value
towards the company and community building the software in other forms: by
opening issues, updating documentation, advocating for the OSS variant, among
other ways. While this is not **money**, it is significant for a young company
like FlowFuse.

## Challenges with a open core free tier

That's not to say that an open source tier is a silver bullet for a company. For
one, it's hard to track how many users a software package has, and who these users
are. For example; FlowFuse has [Telemetry](https://flowfuse.com/docs/admin/telemetry/#usage-telemetry),
though it can be turned off. Nor do we know who hosts this software.

Another challenge is around product and feature packaging. At FlowFuse and other open core companies it's
uncommon to move features from the open tier to paid tier only. If this choice has
been made it's a done deal, even when the product team got it wrong. Usually the
initial thoughts are therefor to move all features into the paid tiers. However,
this hampers long term growth as adoption of paid features are adopted later or
not at all. We follow the
[Open-Core buyer based model](https://opencoreventures.com/blog/2023-01-open-core-standard-pricing-model){rel="&#x22;nofollow&#x22;"}
to segregate the value, about which I'll write a post next time.

Photo by [Matt Hardy](https://unsplash.com/@matthardy).


# FlowFuse announces a Node-RED stack for Industry 4.0 applications on ctrlX AUTOMATION

FlowFuse is pleased to announce they are now offering Node-RED plus select third party nodes from the Bosch Rexroth ctrlX World marketplace.

FlowFuse is pleased to announce they are now offering Node-RED plus select third party nodes from the [Bosch Rexroth ctrlX Store](https://developer.community.boschrexroth.com/t5/Store-and-How-to/FlowFuse-Node-RED/ba-p/82135){rel="&#x22;nofollow&#x22;"} marketplace. Rexroth customers building Industry 4.0 applications will now have a trusted vendor, in FlowFuse, to provide support and updates for using open source Node-RED in production. By partnering with FlowFuse, customers can reduce their risk of using Node-RED in production by relying upon FlowFuse Node-RED experts to assist with any development or production issues.

[Node-RED](https://nodered.org/){rel="&#x22;nofollow&#x22;"} is a popular open source low-code development environment widely used in industries for collecting and processing industrial data to deliver Industry 4.0 applications. FlowFuse is uniquely positioned to partner with ctrlX customers looking to use Node-RED in production. FlowFuse CTO Nick O’Leary is the co-creator and project leader of Node-RED. FlowFuse employs many Node-RED experts who have years of experience helping customers with successful deployment of Node-RED applications.

The FlowFuse package offered in the ctrlX World marketplace will provide ctrlX customers the following benefits:

- Support for Node-RED development and production deployments
- Support for third party nodes of popular industrial protocols including: Modbus, OMRON, S7 and MC Protocol.

FlowFuse is the only vendor providing professional technical support for Node-RED on the ctrlX platform.

The package is available today at ctrlX World. Interested customers should contact their Rexroth sales representative for purchasing details. Interested customers can also contact FlowFuse directly at <sales@flowfuse.com> for additional information about the offering.


# How ChatGPT improves Node-RED Developer Experience

ChatGPT has the potential to have a significant impact on the Node-RED community. It is a powerful language model that can be used to generate flows, interpret them, and provide documentation, maybe soon even write the flow! The combination of ChatGPT, or generative AI at large, with Node-RED can significantly improve the developer experience with Node-RED. In this post we’ll review what the community has already built.

## How generative AI like ChatGPT is used for Node-RED

### Function node <3 ChatGPT

ChatGPT, and other models, can write code for you, much like [GitHub CoPilot](https://github.com/features/copilot){rel="&#x22;nofollow&#x22;"} or [GitLab Duo](https://about.gitlab.com/gitlab-duo/){rel="&#x22;nofollow&#x22;"}. As Node-RED is ‘low-code’ the ability for generative AI to write the required code for you creates a paradigm shift to ‘no-code’!

![Example of Chat GPT to generate contents of a function node](https://flowfuse.com/blog/2023/09/images/chatgpt-fcn-example.png)

At FlowFuse we’ve written about this [before](https://flowfuse.com/blog/2023/05/chatgpt-nodered-fcn-node/), and published a [plugin](https://github.com/FlowFuse/node-red-function-gpt){rel="&#x22;nofollow&#x22;"}. This node allows flow developers to be more productive and efficient. While this works only for the function node, there’s countless other possibilities to describe a flow in text and import a ChatGPT generated flow that are on the horizon!

### Flow Interpretation

When developing larger projects with multiple tabs, it’s important to understand what each tab contributes to the full project. This problem is compounded when the flows are developed by a team or the time between the flow was last updated is higher.

![ChatGPT Flow Interpretation](https://raw.githubusercontent.com/node-red-jp/node-red-contrib-plugin-chatgpt/main/infotab.png)

[Kazuhito-san](https://www.linkedin.com/in/kazuhitoyokoi/){rel="&#x22;nofollow&#x22;"} wrote a module for Node-RED to interpret the flow, nodes, and their order into a well structured documentation. Through a click of a button it's generated by the well-known OpenAI
model. This is especially interesting as it's thus able regenerate it when changes were made by the developers.

It’s a plugin that requires very little setup, and can be found in the [flow library](https://www.npmjs.com/package/node-red-contrib-plugin-chatgpt){rel="&#x22;nofollow&#x22;"}.

### Lots of plugins

The ecosystem of Node-RED has always been a fast adopter of new technology. There's
nodes for [ChatGPT](https://flows.nodered.org/node/node-red-contrib-chatgpt){rel="&#x22;nofollow&#x22;"},
[Google's Bard](https://flows.nodered.org/node/node-red-contrib-bard){rel="&#x22;nofollow&#x22;"}, and many
more. These plugins genernally let you build on top of these models, and don't
nessecairly improve the developer experience. It's however a great source of
inspiration!

### Further discussion

These were three examples of how generative AI is used in the Node-RED community. Please let us know if you're using ChatGPT or other AI models with Node-RED? And what would be the killer feature for Node-RED and AI?


# Community News September 2023

Welcome to the FlowFuse newsletter for September 2023, a monthly roundup of what’s been happening with FlowFuse and the wider Node-RED community.

## New Name

The big news this month is that [FlowForge is now FlowFuse](https://flowfuse.com/blog/2023/08/flowforge-is-now-flowfuse/). Yes, we have changed our name but we are still focus on delivering great products for the Node-RED community.

:product-update-note

## New Releases

- Node-RED 3.1 has been [released](https://nodered.org/blog/2023/09/06/version-3-1-released){rel="&#x22;nofollow&#x22;"}. Among the changes are Mermaid chart support, locking flows, and much more.
- Last week, FlowFuse 1.11 was released. This release included personal access tokens for FlowFuse API and new tiers for FlowFuse Cloud, including a new starter tier. Check out the details in our [announcement](https://flowfuse.com/blog/2023/08/flowfuse-1-11-release/).

## Upcoming events

### Celebrate 10 Years of Node-RED and What’s New in 3.1 and Beyond

Hard to believe that Node-RED was launched 10 years ago. We want to celebrate this great accomplishment and also show off the new Node-RED 3.1 release. Join Nick O'Leary for the 10 year celebration and here what is coming next.

[Sign-up today](https://flowfuse.com/webinars/2023/node-red-10-years/) to join us on September 21.

## From our Blog

- The Node-RED Dashboard 2.0 project is making excellent progress. Two updates were published in the last month. Make sure you check out the latest release and provide feedback.
  - [Dynamic Markdown, Tables & Notebooks with Dashboard 2.0](https://flowfuse.com/blog/2023/09/dashboard-notebook-layout/)
  - [Dashboard 2.0 - Community Update](https://flowfuse.com/blog/2023/08/dashboard-community-update/)
- [FlowFuse announces a Node-RED stack for Industry 4.0 applications on Bosch Rexroth ctrlX Automation](https://flowfuse.com/blog/2023/09/bosch-rexroth-announce/) - a fully supported Node-RED stack for Bosch customers.
- [FlowFuse is now available on the AWS Marketplace](https://flowfuse.com/blog/2023/08/aws-marketplace-announce/) - making it easier to run FlowFuse on the AWS cloud.
- [Our Open Source offering is a tier, not our competition](https://flowfuse.com/blog/2023/08/open-source-is-a-tier-not-competition/) - some insight from our CEO into our open source strategy.
- [Why the Automation Pyramid blocks digital transformation - The Role of Unified Namespace](https://flowfuse.com/blog/2023/08/isa-95-automation-pyramid-to-unified-namespace/) - some insight from the FlowFuse product manager into the role of a Unified Namespace.

## From the Community

- A new plugin for the generation of [Matter devices witin Node-RED](https://flows.nodered.org/node/@node-red-matter/node-red-matter){rel="&#x22;nofollow&#x22;"} has been published.

## Join Our Team

FlowFuse is expanding our team. Check out the current openings:

- [Contract Front-End Engineer – Node-RED Dashboard](https://boards.greenhouse.io/flowfuse/jobs/4911532004){rel="&#x22;nofollow&#x22;"}
- [Developer Relations Engineer - Manufacturing & Industrial Automation](https://boards.greenhouse.io/flowfuse/jobs/4958271004){rel="&#x22;nofollow&#x22;"}


# Dynamic Markdown, Tables & Notebooks with Dashboard 2.0

Whilst we're still busy backporting through the existing Dashboard 1.0 features, we did want to highlight some new features we've built in Dashboard 2.0 released this week.

In our v0.4.0 release, we've introduced a new "Notebook" layout, alongside a new Table widget.

The Notebook layout is designed to allow users to create Dashboards structured like a Notebook (most often seen with the likes of [Jupyter Notebooks](https://jupyter.org/){rel="&#x22;nofollow&#x22;"} or [ObservableHQ](https://observablehq.com/){rel="&#x22;nofollow&#x22;"}).

Here we will deepdive into the Notebook layout, and show how, alongside our new **Markdown Node** ([docs](https://dashboard.flowfuse.com/nodes/widgets/ui-markdown.html){rel="&#x22;nofollow&#x22;"}), **Table Node** ([docs](https://dashboard.flowfuse.com/nodes/widgets/ui-table.html){rel="&#x22;nofollow&#x22;"}) and others, it's becoming easier to create dynamic and interactive Dashboards.

*Note: If you're not familiar with Markdown, it's a simple markup language that allows you to format text. You can learn more about it [here](https://www.markdownguide.org/cheat-sheet/){rel="&#x22;nofollow&#x22;"}.*

## Dashboard Hierarchy

As a quick introductory note ahead of our below guide, each Dashboard is structured accordingly:

- **Widget**: An individual functional block, e.g. button, chart, slider
- **Group**: A collection of widgets that render together
- **Page**: A single page/tab in your Dashboard. Each page can have it's own Layout, in this case we'll use "Notebook"
- **UI**: Contains a collection of pages, deployed from Node-RED, provides the basic side navigation to switch between Pages.

## Building a Notebook

![Example Notebook created in Dashboard](https://flowfuse.com/blog/2023/09/images/db-notebook-example.png)

To get started, drop your first widget (in this case, we'll add a `ui-markdown`) onto the Node-RED canvas. This in turn will prompt us to create our first Group/Page/Dashboard which we can name and configure accordingly.

Let's add the following Markdown to our first widget:

```md
# Markdown Content

Here we can render dynamic Markdown content that is
easily _styled_.

We can inject `msg.payload`. For example, here is a
timestamp updating every second: {{ msg.payload }}
```

The joy of `ui-markdown` in Dashboard 2.0 is *dynamic* content, i.e. content that can be updated by passing messages to the `ui-markdown` node. We can wire an `inject` node, set it up to repeat every second, and connect it to `ui-markdown`. Now, our Markdown content will automatically update show this value.

![Screenshot to show how an inject node can drive content of a ui-markdown node](https://flowfuse.com/blog/2023/09/images/db-notebook-inject.png)

Resulting in:

:video{ariaLabel="Dynamic markdown with an updating timestamp every 1 second" autoPlay="true" height="318" loop="true" muted="true" playsInline="true" preload="none" width="1314"}

## Adding More Widgets

Because the Notebook is *just* a layout, we can still wire together any of the available widgets and existing nodes and display them accordingly.

Let's wire a `ui-button`, HTTP Request, and `ui-table` node. When we click the button, it will perform the HTTP request, and then render the response in the table.

For this, we're going to use the Random Jokes API, and in particular, a call to `https://official-joke-api.appspot.com/jokes/ten` which will return 10 random jokes.

![Screenshot showing a simple Button > HTTP Request > Table flow](https://flowfuse.com/blog/2023/09/images/generate-jokes-flow.png)

We can also re-order the widgets on the page using the Dashboard 2.0 sidebar (as you could in Dashboard 1.0).

![Screenshot to show how an inject node can drive content of a ui-markdown node](https://flowfuse.com/blog/2023/09/images/db-notebook-order.png)

The above effort results in the following output in our Notebook:

![Screenshot to show how an inject node can drive content of a ui-markdown node](https://flowfuse.com/blog/2023/09/images/db-notebook-jokes-table.png)

## What else is new in 0.4.0?

The above demonstrates just a few of the new features in the 0.4.0 Release, but we've also added [other fixes and improvements](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v0.4.0){rel="&#x22;nofollow&#x22;"}. In particular, I want to call out Steve's great work on implementing custom class injection, the first of our new ["Dynamic Properties"](https://dashboard.flowfuse.com/user/dynamic-properties.html){rel="&#x22;nofollow&#x22;"}, of which there will be more (e.g. visibility, disabled, etc.) to come.

As always, thanks for reading and your interested in Dashboard 2.0. If you have any feature requests, bugs/complaints or general feedback, please do reach out, and raise issues on our relevant [GitHub repository](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.

- [Dashboard 2.0 Activity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}
- [Dashboard 2.0 Planning Board](https://github.com/orgs/FlowFuse/projects/15/views/4){rel="&#x22;nofollow&#x22;"}


# Share & Preview Flows on flows.nodered.org

For years, Node-RED's website has provided functionality to share flows through [flows.nodered.org](https://flows.nodered.org){rel="&#x22;nofollow&#x22;"}

This week, we at FlowFuse have contributed a new feature to the site that allows users to visually preview those flows, and embed/share those flows in articles and on forum posts.

## Visual Flow Previews

A huge thank you for this work needs to go Gerrit Riessen's work published on his [Open Mind Map Blog](https://blog.openmindmap.org/){rel="&#x22;nofollow&#x22;"}. He recently open-sourced some great work to GitHub ([repo](https://github.com/gorenje/node-red-flowviewer-js){rel="&#x22;nofollow&#x22;"}), and with some adaptation and collaboration, we've been able to utilise this as a foundation for the functionality we've added into the flows site.

Adding this to [flows.nodered.org](https://flows.nodered.org){rel="&#x22;nofollow&#x22;"} will make it far easier to learn how others use Node-RED, and to share your own flows with others too. The embedding functionality should also make talking about Node-RED in your own articles & forums much easier.

### Example: Simple Flow

Here's a demonstration of a simple `Inject` > `Debug` node:

:iframe{allow="clipboard-read; clipboard-write" height="200px" src="https://flows.nodered.org/flow/500ee13719e54e42493c8ec96fa733b6/share?height=100" style="border: none;" width="100%"}

### Example: Subflows, Groups, Links & Switches

Here's a non-functional flow that just demonstrates how FlowViewer renders the range of node types available in Node-RED:

:iframe{allow="clipboard-read; clipboard-write" height="500px" src="https://flows.nodered.org/flow/82a8602b615740491d30c083e5292e5f/share" style="border: none;" width="100%"}

## Sharing & Embedding Flows

Any flow on [flows.nodered.org](https://flows.nodered.org){rel="&#x22;nofollow&#x22;"} now has a `Share Flow` option in the `Actions` section on the right side of the flows page. Clicking this will provide you with an iframe like:

```html
<iframe width="100%" height="100%"
    src="https://flows.nodered.org/flow/7c2dd3ccde70746a40ef8f5aa58c591c/share"
    allow="clipboard-read; clipboard-write" style="border: none;"></iframe>
```

Which you can paste/embed into any website or blog post. Nick has also [enabled the Node-RED forums to support these embeds too](https://discourse.nodered.org/t/previewing-flows-on-the-flow-library/){rel="&#x22;nofollow&#x22;"}, and is also how we've embeded the above flows too.

If you want more control over the sizing of the viewer, you can also include a `?height=` query parameter on the `src` value of the `iframe`. You may also need to hardcode the `height` property of the `iframe` itself to account for this change, depending on where you're embedding it to. For example:

```html
<iframe width="100%" height="250px"
    src="https://flows.nodered.org/flow/7c2dd3ccde70746a40ef8f5aa58c591c/share?height=100"
    allow="clipboard-read; clipboard-write" style="border: none;"></iframe>
```

We know it's still not perfect, and there's plenty more we can do with it, but hopefully this is a welcome contribution to the Node-RED community.


# Modernize your legacy industrial data

Industrial systems generate valuable data, but legacy protocols like Modbus or non-IIoT standards often make it hard to use. Bridging this gap is essential to connect traditional systems with the modern Industrial Internet of Things (IIoT).

Whether it’s Modbus registers, serial communication without a protocol, or standards like Siemens S7 and Mitsubishi MC-Protocol, the challenge lies in making sense of this raw information. With tools like Node-RED and the node-red-contrib-buffer-parser, you can turn complex, outdated data streams into usable formats that power IIoT innovation.

### Legacy Industrial Data: Modbus

Modbus is one of the most widely used industrial protocols. Originally developed in the late 1970s, it has been a popular choice for industrial communication ever since. However, its data format can be challenging to work with in the context of modern IIoT applications. Modbus typically represents data in 16-bit unsigned registers, making it necessary to convert this data into more usable formats like Signed integer, Float, Signed and Unsigned Long, String, or even individual bits.

### A short primer on data types

Before we dive into how to make sense of Modbus data, let's take a quick look at some of the common data types we have to deal with.

#### 16-bit unsigned

16-bit unsigned data is an integer that can only be positive. It can represent values from 0 to 65535. For example, the number 12345 is represented as `0x3039` in hexadecimal or `0011000000111001` in binary.

#### 16-bit signed

16-bit signed data is an integer that can be positive or negative. It can represent values from -32768 to 32767. For example, the number -12345 is represented as `0xCFC7` in hexadecimal or `1100111111000111` in binary.

#### 32-bit data

32-bit data, like 16-bit data can mean many things. It could be signed or unsigned, or even a floating point number. For example, the number 12345 is represented as `0x00003039` in hexadecimal or `00000000000000000011000000111001` in binary. Typically, 32-bit data is represented as two 16-bit registers. Therefore, when dealing with 32-bit data, you need to combine two 16-bit registers to get the full value.

#### Endianness

Endianness, particularly in the context of data communications, refers to the order of bytes and how they are stored or transmitted. There are two types of endianness: big-endian (BE) and little-endian (LE). In big-endian, the most significant byte is first, while in little-endian, the least significant byte is first. For example, the number 12345 is represented as `0x3039` in a big-endian word and `0x3930` in little-endian word. This can often cause confusion and complicate the process of converting Modbus data into more usable formats.

### Node-RED and node-red-contrib-buffer-parser to the rescue

Node-RED is an open-source flow-based development tool for visual programming. It's particularly well-suited for IIoT applications because of its versatility and extensive library of nodes. One such node, `node-red-contrib-buffer-parser`, provides a solution to the legacy data conversion challenge.

This powerful Node-RED module allows you to parse a Buffer of bytes or an Array of integer data (which, by no coincidence, the popular module `node-red-contrib-modbus` outputs), and convert it into various data types. It can output pretty much any data type, including byte-swapped data, WORD swapped data, masked/shifted/scaled data, and even individual bits.

Here's a quick overview of how it works:

1. **Data Parsing**: Start by setting up a Modbus READ node in Node-RED to retrieve data from your industrial device. Then, use the buffer parser node to parse the Modbus data.
2. **Data Conversion**: With the buffer parser, you can easily convert the 16-bit unsigned data into more meaningful formats. Whether you need to translate it into Float, Long, String, or even extract specific bits, this tool makes the process straightforward.
3. **Publishing to MQTT, influxDB, a dashboard, an IIoT system**: Once your data is in a usable format, Node-RED enables you to publish it to many places. MQTT (Message Queuing Telemetry Transport), a popular protocol for IIoT communication is a perfect example. This makes your data accessible to other IIoT systems and applications for further analysis and action.

### Unlocking the Potential of Legacy Data

By leveraging Node-RED and buffer parser, you can bridge the gap between legacy industrial protocols and the IIoT world. This means you can extract valuable insights from your existing infrastructure without the need for costly hardware upgrades or replacements.

In the era of the Industrial Internet of Things, making sense of your industrial data is no longer a daunting challenge. With the right tools approach, you can unlock the full potential of your legacy data and drive efficiency, productivity, and innovation in your industrial processes. Yey!

### 3 quick demos of Node-RED and the buffer parser node in action

Here are 3 quick demonstrations that barely scratch the surface of possibilities:

#### Example 1: Modbus to MQTT

Converting an array of 16-bit unsigned integers to String, Float and a scaled integer and passing them to an MQTT broker in 4 nodes!
:video{ariaLabel="Legacy data to MQTT" autoPlay="true" height="376" loop="true" muted="true" playsInline="true" preload="none" width="1575"}

#### Example 2: Modbus to InfluxDB

Converting an array of 16-bit unsigned integers to String, Float and a scaled integer for publishing to influxDB!
![Legacy data to influxDB](https://flowfuse.com/blog/2023/09/images/industrial-legacy-data-to-influx.png)![Legacy data to influxDB2](https://flowfuse.com/blog/2023/09/images/industrial-legacy-data-to-influx2.png)

#### Example 3: Modbus data on a dashboard

Converting an array of 16-bit unsigned integers to String, Float and a scaled integer for publishing to a dashboard!
![Legacy data to dashboard](https://flowfuse.com/blog/2023/09/images/industrial-legacy-data-to-dashboard.png)

### Simplify Your Node-RED Operations with FlowFuse

While Node-RED is a fantastic tool for data collection, transformation, and analysis, integrating it into a production environment can sometimes feel like navigating a maze. Whether you’re deploying Node-RED on a server, ensuring secure remote access for your team, or managing a sprawling network of thousands of instances, it’s easy to feel overwhelmed.

That’s where FlowFuse steps in to make your life easier. FlowFuse is designed to tackle these challenges head-on. It enhances Node-RED with features that simplify collaboration, strengthen security, and provide scalable deployment options. Imagine having a robust system that not only keeps your Node-RED applications running smoothly but also scales effortlessly with your needs. With FlowFuse, you gain access to a comprehensive suite of production-ready [features](https://flowfuse.com/platform/features/) designed to streamline your Node-RED workflows and boost overall performance.

**[Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now for a free trial and experience FlowFuse's features**

### Learn More

We will be publishing follow-up blog posts with more details, best practices and examples on how to use Node-RED to make sense of your industrial data. In the meantime, you can learn more about these tools by visiting the following links:

- [Node-RED blog posts](https://flowfuse.com/blog/node-red/)
- [Node-RED videos](https://www.youtube.com/playlist?list=PLpcyqc7kNgp09XeRx_cae1fEIOloPqM1C){rel="&#x22;nofollow&#x22;"}
- [Buffer Parser Node](https://flows.nodered.org/node/node-red-contrib-buffer-parser){rel="&#x22;nofollow&#x22;"}


# Modernize your legacy industrial data. Part 2.

In [part 1 of this series](https://flowfuse.com/blog/2023/09/modernize-your-legacy-industrial-data/), I introduced the topic of working with legacy industrial data from the likes of Modbus and older, non IIoT protocols and putting it to work in an IIoT world. We looked at some of the challenges and how Node-RED with `node-red-contrib-buffer-parser` node can help.

In this article, I will dive a little deeper into the topic and discuss some of the finer details. I hope to demonstrate a smarter approach that can make a huge difference to data accuracy, performance and maintainability while significantly reducing developer time. Not only that, ending with a no-code solution.

## Obtaining Industrial Data

In order to convert the legacy data to a format more suited to IIoT we first need to *grab* that data.

Node-RED has core nodes that can help you and many more contribution nodes exist that provide access to a wide range of industrial devices. To give you an idea, `node-red-contrib-modbus`, `node-red-contrib-s7comm`, `node-red-contrib-omron-fins`, `node-red-contrib-mcprotocol`, `node-red-contrib-df1` and `node-red-contrib-cip-st-ethernet-ip` are just some of the PLC data access nodes available.

But getting the data is just the beginning, it's the methods and considerations you need to make that can make the difference between success and failure. Read on...

## Data consistency

An often overlooked aspect of working with legacy industrial data is the consistency of the data being read. In the context of this article, consistency means that the multiple values that make up a related data set are read in a way that they are all valid to one another at the point in time it was read.

Let's take a look at a simple example. We have a process PLC recording production metrics and wish to get this data from its Modbus interface for reporting and decision making. The PLC has 5 values that we need to read:

| Register | Value | Description           | Data Type  |
| -------- | ----- | --------------------- | ---------- |
| 1, 2     | 10    | Part Count            | UINT32     |
| 3, 4     | 2.5   | Cycle Time (sec)      | UINT32/100 |
| 5, 6     | 30    | Production Time (sec) | UINT32/100 |
| 7, 8     | 20    | Run Time (sec)        | UINT32/100 |
| 9, 10    | 11    | Stoppage Time (sec)   | UINT32/100 |

In the above data sample, we can see the total production time is 30 seconds and the run time is 20 seconds. The expectation is that the Stoppage Time should be 10 seconds. However, as we can see, Stoppage Time in this sample is 11 seconds. That is because this data is not consistent.

### Why is the data inconsistent?

The most common reason for the data inconsistency is that the data is being read from the PLC while the PLC is running. The data is changing as it is being read.

Typically this happens when a developer, unfamiliar with the protocol or end device, begins by reading the data individually. Here is how this journey might look:

*Image 1: individual reads*![image showing 10 individual reads](https://flowfuse.com/blog/2023/09/images/industrial-legacy-data-pt2-demo1.png)

That is a lot of nodes and a lot of duplication!

What is worse, is that the developer continues down this path and begins converting the data ready for publishing to MQTT. Here is how this might evolve:

*Image 2: individual reads with data processing*:video{ariaLabel="Video showing 10 individual reads with data processing" autoPlay="true" height="684" loop="true" muted="true" playsInline="true" preload="none" width="1030"}

Yippie! We have the data, it works, we publish it to MQTT, job done. Right?

Unfortunately, no. The data is inconsistent.

### So whats the big deal?

Inconsistent data is not useful data and errors can get compounded over time. This leads to bad decisions being made and a loss of confidence in the data. Ultimately, this leads to the data being ignored and the opportunities to make improvements are lost. Loss of improvements means loss of money!

Not only that, from a developer or maintainers perspective, it has many problems:

1. Lots of error prone manual configuration (yes, I made several mistakes while creating the example)
2. Hard coded register addresses
3. Duplication
4. Inextensible - what if we need to read more registers?
5. Inconsistent data - as discussed above
6. Slow - each read takes time
7. Inefficient use of network bandwidth - each read requires a request and response packet

### How can we make the data consistent?

The most obvious solution is to stop the PLC before reading the data.
However, I am faily certain your boss will not be super pleased with stopping the manufacturing process.
The next best thing is for the PLC to sample and store the data in an internal memory buffer, waiting, unchanging, to be collected. Unfortunately, this too is not always possible either due to limited in-house skills, locked down PLCs or simply because the PLC does not have the memory to store the data.

The next best thing to do is to read relative data as quickly as possible and in one block.

### A quick side-bar (timing is ... everything)

In many protocols, including Modbus, data must be polled. Each poll, depending on many factors, can take a number of milliseconds.

Lets say, on a relatively quiet serial network, a single register poll takes 25 milliseconds (assume 9600 baud, 1 byte/ms, request packet size 8 bytes, response packet size 7 bytes, 10ms latency for the PLC to receive, process and respond to the request)

- If we read 10 registers individually, then the time taken to read the 10 registers is 250 milliseconds.
- If we actually needed a more realistic number of registers, say 32, then the time taken to read them individually is a whopping 800 milliseconds. In the world of PLCs, that is an eternity.

Now, lets look at that from a different approach. If we were to read the 32 registers in one go, the time taken based on the above constants would be 87 milliseconds. That is over 9 times faster than reading the registers individually. The improvements don't stop there either, the number of total bytes transferred on your network is reduced by 84% and, more importantly, the data is consistent since it was read from the same scan of the PLC scan.

*Image 3: A comparison of individual reads vs block reads*![A data table comparing polls vs block read](https://flowfuse.com/blog/2023/09/images/industrial-legacy-data-pt2-table.png)

OK, back to the topic at hand.

## Getting the data in a more consistent way

Here is the same example as above but this time we are reading the data in one go:

*Image 4: Getting data in one block*![image showing 1 read for 10 registers](https://flowfuse.com/blog/2023/09/images/industrial-legacy-data-pt2-demo1b.png)

Note how much simpler this is? Not only that, it is easier to maintain, faster, more extensible and most importantly, the data is consistent.

Great, lets move on.

## Processing the data in readiness for IIoT: MQTT

Now that we have good data, we need to process it in readiness for IIoT. In this example, we are going to publish the data to an MQTT broker as individual topics. This is a common approach as it allows the data to be easily consumed by other systems and applications. Using `node-red-contrib-buffer-parser` we can easily convert the data into more meaningful formats.

The first, instinctive approach is to fan out the data and process it individually:

*Image 5: block reads, individual processing*:video{ariaLabel="Video showing 1 modbus poll with individual processing" autoPlay="true" height="636" loop="true" muted="true" playsInline="true" preload="none" width="926"}

This may be fine for a handful of registers but it soon becomes unwieldy and unmaintainable.

But lets be smarter about this. We know that the data is consistent and we know that we can read it in one go. So, lets process it in one go too:

*Image 6: block reads, smart processing, no-code solution*:video{ariaLabel="Video showing 1 modbus poll with smart processing" autoPlay="true" height="621" loop="true" muted="true" playsInline="true" preload="none" width="886"}

## Node-RED in Production

Node-RED is a powerful tool widely used in IoT and IIoT industries, including manufacturing, automotive, textiles, and building management. It excels at collecting, transforming, visualizing, and analyzing data. While integrating Node-RED into production environments offers numerous benefits, it often involves complex tasks such as deploying the server, managing security, and ensuring scalability. These initial setup challenges can be overwhelming and time-consuming.

FlowFuse simplifies these tasks by providing a unified platform for managing all Node-RED instances. It enhances collaboration, ensures security, and supports scalability, making deployment and management more efficient. With features like [snapshots](https://flowfuse.com/docs/user/snapshots/), team collaboration tools, one-click deployment, and [multi-factor authentication](https://flowfuse.com/docs/user/user-settings/#security), FlowFuse streamlines the process and enhances the operational capabilities of Node-RED in production settings.

**[Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now for a free trial and experience FlowFuse's features**

## Wrap up

I hope this article has given you some food for thought and some ideas on not only simplifying your journey to IIoT but also the pitfalls to avoid along the way.

A parting thought, there are times when the data is not contiguous. There are ways to deal with this too but that is for another day.

P.S. I will post the flows used for the examples above in the comments below. If you have any questions or comments, please reach out there too.


# Updating our branding across GitHub, npm and Dockerhub

Following our rename to FlowFuse last month, we are about to take the next
set of steps to complete the rebrand. This time, focussed on the technical
assets we produce.

Rebranding a company isn't a small undertaking, especially when your company
name is also your product name. When we announced our [new name last month](https://flowfuse.com/blog/2023/08/flowforge-is-now-flowfuse/) we
prioritised updating the website, our documentation and social media presences.
All of the most visible things relating to the company name.

But we knew that wasn't the whole job done. The name `flowforge` still appears
in the technical resources we use and the artefacts we publish. Changing them
is not as simple a task as changing some words on a website, so it has taken a bit
more time to get our plans in place for this next step.

I wanted to highlight the set of changes we'll be making in the coming days to
complete this migration. For the vast majority of users, expecially those using
FlowFuse Cloud, these changes will be completely transparent.

However, if you are contributing to any of our open source components, or consuming
our npm or Docker packages directly, then please read on.

There are four areas we need to migrate.

### GitHub Organization

As a company everything we do revolves around our GitHub Organization. Our
source code, release planning, this website, and far more all live there.

Step one of our migration will be renaming the organization to `FlowFuse`, so instead
of `https://github.com/flowforge` we will now live at `https://github.com/FlowFuse`.

Renaming organizations on GitHub, whilst not something done lightly, is well catered
for. Many existing urls should get automatically redirected - so any existing
links will still work. We will, of course, do the work to update any urls in our docs.

### NPM package names

We publish a number of packages to the public Node.js Package Manager (npm) repository
under the `@flowforge` name.

After this week's release is done, we'll be updating all of our packages to publish
under the `@flowfuse` name and no longer updating the packages under the old name.

This will impact anyone who has installed any of our components directly from `npm`. For
example, the Device Agent or Node-RED Dashboard 2.0.

We will provide specific upgrade instructions for each of the affected components once
the move is done.

### Docker Images

We publish container images to Dockerhub under the `flowforge` name. Once
we've updated our npm package names, we'll also be updating our container tags
to use the new name.

If you are using our helm or Docker Compose projects, we'll have a new release that
will help get you moved over to the new image names. Likewise our Digital Ocean
and AWS Marketplace offerings will be updated - and instructions provided for existing
users to migrate over.

### FlowFuse Cloud

The final step we have to make is to move FlowFuse Cloud over to its new home
at `app.flowfuse.com`. We have to co-ordinate the update with all of our customers
who use SSO to login to ensure they can continue to access the platform.

Once that is done, it will be a seamless transition for everyone. Existing Node-RED
instances will continue to use the `*.flowforge.cloud` domain, but then all new
instances will use the `*.flowfuse.cloud` domain.


# Tulip Operation Calling Event Report

This week I attended the Tulip event called [Operations Calling](https://www.operationscalling.com/){rel="&#x22;nofollow&#x22;"} in Boston. Here are some quick observations from the event.

For those that might not know [Tulip](https://tulip.co/){rel="&#x22;nofollow&#x22;"}, they are a Boston based company focused on frontline operations in the manufacturing and industrial automation industry. They provide the software to help factory workers be more efficient at their job. Some people refer to this category as MES but Tulip avoids this term since MES can carry a lot of negative baggage from legacy MES vendors.

Some quick thoughts on the event:

- I would estimate about 300 people attended the event. It was held at Tulip’s office, which is actually in an old Ford factory. The offices and environment were very cool.
- There was a large emphasis on Tulip partners and the ecosystem. Tulip knows it needs to be open and play well with others. There were 27 different vendors showing in their partner pavillion. Pretty impressive given the size of Tulip.
- Tulip has a no-code environment for setting up their software. However, they realize you also need low-code, like Node-RED, for integrating hardware and software into Tulip. I attended two sessions that discussed how Node-RED is an important part of the Tulip integration and customization strategy. Node-RED was also being used in some of their demos stations.
- Tulip talks about ‘citizen developers’ and ‘composable apps’. This is the future of manufacturing. Organizations need to start thinking in terms of smaller applications that do a specific task that can also be rolled up into something bigger at a later time. These small applications need to be developed by the people closest to the problem, not the IT team or a system integrator.
- During the closing panel, it was stated that ‘Today, Excel is the most popular digital automation platform used in industry.’ There are a lot of spreadsheets being used to collect and visualize data. However, the industry needs to find a better way. Node-RED is an important part of the solution. The people who can run Excel spreadsheets can easily use Node-RED. However, using Node-RED will let them do even more than what Excel allows them to do.

Operation Calling was definitely an event worth attending and I hope to return next year.


# What are FlowFuse Blueprints?

Starting today, FlowFuse Blueprints are available on FlowFuse Cloud. Additionally, upon request, all our Teams and Enterprise Self-Hosted customers gain access to this collection. But what exactly are FlowFuse Blueprints?

## FlowFuse Blueprints

FlowFuse Blueprints aim to make the Node-RED experience more accessible for newcomers, while also offering a treasure trove of fresh ideas for seasoned Node-RED users. When setting up a new Node-RED instance, you now have the option to choose a blueprint tailored for specific use cases. For example, our "ANDON Operator Terminal" blueprint can be selected, and it will automatically configure the Node-RED instance, sparing you the need to start from scratch. While these templates are powerful out-of-the-box, they're also fully customizable, allowing you to tweak them to suit your unique requirements. Ultimately, blueprints speed up the learning curve for new users and expedite the solution-building process for experienced ones.

### How to use Blueprints?

All our FlowFuse Cloud users can select a Blueprint directly while creating a new Node-RED instance. Self-hosted customers can request access to our blueprints via a [support ticket](https://flowfuse.com/support/).

## The first three Blueprints

In the coming weeks, we'll be releasing a multitude of blueprints tailored for diverse use cases. However, we decided to start with with three foundational manufacturing applications designed with the [Node-RED Dashboard 2.0](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"}.

### ANDON Operator Terminal

The Andon Operator Terminal is designed to be at the start of an Andon process, allowing end-users to report any issues with the cell to a supervisor.
![ANDON Blueprint Screenshot](https://flowfuse.com/blog/2023/10/images/ANDON1.png)

### Performance Overview Dashboard

The Performance Overview Dashboard Blueprint provides a real-time snapshot of key performance metrics, delivering a comprehensive overview of manufacturing operations for a specific station or entire line.
![Performance Overview Screenshot](https://flowfuse.com/blog/2023/10/images/performance-dashboard.png)

### OEE Calculator

If automatic calculations are not feasible, the OEE Calculator Blueprint enables end-users to manually input production data to compute the Overall Equipment Effectiveness (OEE) for a given machine.
![OEE Calculator Screenshot](https://flowfuse.com/blog/2023/10/images/dashboard-data.png)


# What are Certified Nodes?

We are thrilled to introduce a new feature for our Teams and Enterprise Tier customers - **Certified Nodes for Node-RED**. This new offering is designed to reinforce your flows's robustness by granting you access to Node-RED nodes that stand up to our rigorous quality and security standards.

## What is a certified node?

A certified node is a module from the Node-RED library that undergoes a certification process, ensuring it adheres to standards that address three core pillars:

**Quality**

- Testing phases for each node.
- Operational reliability and compatibility.

**Security**

- Proactive resolution of potential vulnerabilities.
- Revocation of certification for nodes falling short on security, with prompt notifications to affected customers.

**Support**

- Ambitious aim towards effective issue resolution.
- Assistance for troubleshooting.

## How to use certfied nodes?

Accessing certified nodes is straightforward, they're integrated directly within your Node-RED palette manager, simplifying selection and implementation. All new instances since October 26, 2023, have automatic access to the catalogue. If you want to add Certified Nodes to one of your existing instances, just [contact us](https://flowfuse.com/support/).

![Node-RED palette manager](https://flowfuse.com/blog/2023/10/images/certified-nodes.png)

## What kind of Nodes are included?

Our initial roll-out includes a curated assortment of certified nodes. We're continuously expanding our library, with upcoming weeks bringing a wider array of options. Should you find a gap in your desired functionalities, we encourage you to [reach out](https://discourse.nodered.org/c/vendors/flowfuse/24/){rel="&#x22;nofollow&#x22;"}. Your feedback drives our journey forward, influencing the nodes we introduce next.

- Linting for Node-RED
- Enhanced debugging for Node-RED
- FlowFuse Snapshot Plugin
- Node-RED Dashboard 2.0
- E-Mail Communication
- Base64 converter
- Buffer Parser
- PostgreSQL
- InfluxDB
- Omron PLC
- MC Protocol (Mitsubishi PLCs)

### What will follow in the coming weeks?

- Siemens PLC
- Modbus
- Mssql
- Rockwell and Allen Bradley
- OPC-UA
- MongoDB
- MySQL
- WhatsAPP, Telegram, Slack


# Innovate from within - Why manufacturing must embrace Citizen Developers

In the early days when I was working as a solution architect, I found myself in a peculiar position, observing an intriguing relationship between Operational Technology (OT) and Information Technology (IT) departments. While OT departments struggled to develop digital solutions, the IT departments held an unspoken authority in this domain, leading to a paradoxical dynamic that often seemed to hinder rather than facilitate progress.

As a solution architect working within this environment, I found myself uniquely positioned to bridge the gap between these two groups while also helping them find common ground on which they could build successful projects together. To do so effectively, I needed to understand each group's perspective and determine how best they could collaborate without compromising either side's autonomy or objectives. This task was not always easy but ultimately proved rewarding once achieved successfully.

## A Tale of Shadow IT

In the best-case scenarios, IT departments considered themselves as vendors, and OT, the customers. However, the IT-driven, off-the-shelf solutions seldom proved to be the right fit for the problems at hand. This mismatch often led to the birth of shadow IT systems, solutions that were not sanctioned by IT, yet were deemed necessary to maintain operational efficiency.
In this realm of shadow IT, I've observed countless solutions running on desktop PCs, hidden from the eyes of IT departments, solving problems in manufacturing quickly, a situation born of necessity, with which no one could be satisfied. I cannot deny that Node-RED, an open-source low-code programming tool, has very often been one of these shadow IT systems, enabling data modification, lightweight HMI creation, and empowering the OT workforce.

However, this under-the-radar approach is fraught with dangers. With unprotected systems and without official oversight, the potential for security breaches is a real and present danger. I would wager that even today, a simple scan on port 1880 would reveal a multitude of open Node-RED environments. This double-edged sword of innovation and insecurity highlights the urgent need for a paradigm shift.

## Why are Citizen Developers Important in Manufacturing?

Citizen developers are individuals who create applications and software solutions for their organizations without any background in computer programming. These citizen developers leverage low-code platforms to build apps that automate tasks, streamline processes, and improve existing systems' user experiences. Citizen developers are a growing trend in the industry, serving as a key factor in harmonizing IT and OT interests. They bring an array of benefits that can make businesses more efficient and cost-effective. From reducing development costs to increasing productivity, citizen developers offer significant value to organizations seeking ways to stay competitive.

1. **Acceleration of Software Development:** Low-code platforms significantly expedite the software development process, enabling more efficient realization of business requirements. By quickening development, these platforms free up time and resources for design and innovation, leading to higher-quality software that better serves the business's needs.
2. **Crafting Bespoke Applications:** By empowering non-professional coders with the right tools and resources, organizations can democratize digital solutions. This not only facilitates the creation of custom systems that fit seamlessly into existing infrastructures but also enables rapid ideation and development, even for those without prior coding experience.
3. **Enhancement of Operational Processes and Customer Experiences:** With the automation capabilities of low-code platforms and the innovative solutions generated by citizen developers, operational processes can be optimized, and customer experiences significantly improved. The synergy between these elements can lead to efficiency gains through automation and the delivery of more effective, customer-centric solutions.

This shift toward embracing citizen development within manufacturing represents a unique opportunity where both sides benefit significantly; not only do OT departments gain access to custom applications tailored precisely for their needs, but IT teams can lead guidance for self-empowerment, resulting in greater efficiency through automation.

## Democratize Application Development with Node-RED

For the past decade, Node-RED has been a pioneer in low-code tools, democratizing application development in manufacturing. It provides powerful data collection, transformation, and visualization capabilities, simplifying the application-building process.
As an open-source tool with no associated costs or licensing fees, Node-RED is [increasingly popular](https://flowfuse.com/blog/2023/03/integration-platform-for-edge-computing/#the-standard-for-edge-computing-and-plcs) among manufacturers seeking to quickly develop custom applications without extensive coding knowledge or experience.
FlowFuse takes things one step further, offering organizations a way to officially incorporate and scale Node-RED, making it compliant, governed, and secure within the existing solution landscape.

## The Strategic Imperative of Citizen Development

For industry decision-makers, this is a call to action. It is imperative to nurture this growing community within your workforce, providing them with the tools, platforms, and, importantly, the organizational support they require. The empowerment of citizen developers could very well be the deciding factor in your organization's ability to stay competitive, agile, and innovative in a rapidly evolving market.

Looking to the future, the success of modern manufacturing lies in its people and their ability to solve problems with the right tools at their fingertips. Citizen development has the potential to break down the barriers. Organizations that recognize and invest in this potential will undoubtedly lead the charge.

[One large US manufacturing company has already made this bet](https://flowfuse.com/customer-stories/manufacturing-digital-transformation/), with its project leader describing Node-RED's low-code paradigm as a way to decentralize innovation and let subject matter experts build their own digital systems.


# Community News October 2023

Welcome to the FlowFuse newsletter for October 2023, a monthly roundup of what’s been happening with FlowFuse and the wider Node-RED community.

## Quicker Releases for FlowFuse Cloud and New Changelog

FlowFuse is committed to delivery new features to our customers and community as fast as possible. We are now rolling out new builds of FlowFuse to FlowFuse Cloud more regularly than the previous monthly release. This will allow FlowFuse Cloud users to benefit from the latest enhancements as they become available. The self-hosted version of FlowFuse will continue to have releases every 4 weeks.

To allow FlowFuse Cloud users to keep up to date on the new changes, we have started a [Changelog](https://flowfuse.com/changelog/) to announce newly deployed features.

## Recent Changelog Updates

- [DevOps Pipeline with action selection](https://flowfuse.com/changelog/2023/09/devops-actions/)
- [Usability improvements to Device Management](https://flowfuse.com/changelog/2023/09/snapshots-devices/)
- [Introducing the Enterprise tier](https://flowfuse.com/changelog/2023/09/introduction-enterprise-tier/)
- [API Endpoints for DevOps Pipeline](https://flowfuse.com/changelog/2023/09/pipeline-api/)
- [Private Node Support](https://flowfuse.com/blog/2023/10/use-private-custom-nodes-with-flowfuse/)

## Upcoming events

### Dashboard 2.0 - Where we are, and what’s next?

The next generation of the Node-RED dashboard is starting to mature. Development work on Dashboard 2.0 started earlier this year and amazing progress has been made already. Join Joe Pavitt, leader of the Dashboard 2.0 project, who will demonstrate the new dashboard project and discuss future plans during our October webinar.

[Sign-up today](https://flowfuse.com/webinars/2023/dashboard-20/) to join us on October 26.

## From our Blog

- [Custom Vuetify components for Dashboard 2.0](https://flowfuse.com/blog/2023/10/custom-vuetify-components-dashboard/) - the new dashboard project allows for custom UI components
- [Updating our branding across GitHub, npm and Dockerhub](https://flowfuse.com/blog/2023/09/rebranding-our-components/) - our GitHub, npm and DockerHub locations are now called FlowFuse, due to the rename from FlowForge.
- [How ChatGPT improves Node-RED Developer Experience](https://flowfuse.com/blog/2023/09/chatgpt-for-node-red-developers/) - lots of interest in ChapGPT in the Node-RED community. A quick review of different integrations.
- [Share & Preview Flows on flows.nodered.org](https://flowfuse.com/blog/2023/09/flow-viewer/) - A new way to visualize flows in web pages.
- [Charting REST API Data in a Dashboard](https://flowfuse.com/node-red/integration-technologies/rest/) - A short tutorial on how to gather data from a REST API for a dashboard.
- Modernize your legacy industrial data - Two part series on making sense of your industrial data.
  - [Part 1](https://flowfuse.com/blog/2023/09/modernize-your-legacy-industrial-data/)
  - [Part 2](https://flowfuse.com/blog/2023/09/modernize-your-legacy-industrial-data-part2/)

## Join Our Team

FlowFuse is expanding our team. Check out the current openings:

- [Contract Front-End Engineer – Node-RED Dashboard](https://boards.greenhouse.io/flowfuse/jobs/4911532004){rel="&#x22;nofollow&#x22;"}


# Custom Vuetify components for Dashboard 2.0

Vuetify is a library of UI components using Vue. This saves the developers of
Dashboard 2.0 a lot of time, but it can also help you, the end-user. As Vuetify
is now included, it can be used to include *any* of their components. So in this
post we're going to use a few of these to teach you how to use any of them.

Let's install the [Dashboard 2.0 package](https://dashboard.flowfuse.com/getting-started.html){rel="&#x22;nofollow&#x22;"} if you want to follow along. When that's done, let's figure
out how to build custom components on dashboards.

## Custom components

While going through the list of components on [Vuetify](https://vuetifyjs.com/en/components/all/){rel="&#x22;nofollow&#x22;"}
there's several examples that aren't natively implemented in Dashboard 2.0.
One example we'll use in a dashboard in this post is the
[Progress circular](https://vuetifyjs.com/en/components/progress-circular/){rel="&#x22;nofollow&#x22;"} to
build a count down timer.

The documentation explains which elements one can change, in this case the size and
width. Having set those to the values you'd want in your dashboard, the HTML is
generated for you, in my case it's:

```html
<v-progress-circular model-value="20" :size="128" :width="12"></v-progress-circular>
```

### Using the template node

Like the [template core node](https://flowfuse.com/node-red/core-nodes/template), the dashboard package
comes with [a template node of its own](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html){rel="&#x22;nofollow&#x22;"}.
If we take the HTML from the Vuetify docs pages and copy it in a template node
the spinner will show up on the dashboard.

!["Custom widget on Dashboard 2.0"](https://flowfuse.com/blog/2023/10/images/custom-element-dashboard.png "Custom widget on Dashboard 2.0")

## Dynamic templates

While a custom element on a page is cool, and shows you can inject arbitrary HTML
on a Dashboard, it's even better if we could make the element dynamic. So let's
start with a first dynamic element. The quickest way to get that done is have
an [`Inject`](https://flowfuse.com/node-red/core-nodes/inject) node output a random number every second.

So let's hook up an Inject, with `msg.payload`'s output being a JSONata expression
`$round($random() * 100)` to generate a random number. And let's make sure it
sends a message every second.

Then we need to update the template node to the following snippet:

```html
<v-progress-circular v-model="msg.payload" :size="128" :width="12"></v-progress-circular>
```

The difference is subtle, but important. Instead of hard-coding the `model-value`
to 20, the tag has changed name and it's set to `msg.payload`. The latter makes
the value dynamic.

Changing `model-value` to `v-model` is due to leaking implementation details of
Dashboard 2.0. It uses VueJS to provide, among other features, easy updating of
components. If components are dynamic, &#x2A;always use `v-model`*. This allows VueJS
to pick up changes made dynamically.

:video{ariaLabel="Progress spinner, random values" autoPlay="true" height="664" loop="true" muted="true" playsInline="true" preload="none" width="462"}

### Finishing the count down timer

This is mostly a programmers job, but it's not hard, so let's get to it. A button
would be great to reset the timer, and for the sake of this post we can hardcode
the deadline to 1m from the button press.

When dragging in a button node, connect it to a [change](https://flowfuse.com/node-red/core-nodes/change)
node. In the change node set the flow variable `flow.deadline` to the timestamp. The
Inject node from earlier needs updating to inject the `flow.deadline`. All that's
left is calculating how many seconds passed, and normalizing 60 seconds to the
range between 0-100.

The complete flow is:

::render-flow
```json
[{"id":"ce9bb8f74e3fc934","type":"ui-template","z":"24065a0aadb305e3","group":"8fa772a709ae3316","dashboard":"e5a3f4cdb11e5e3b","page":"5bedf7f49d5a6037","name":"Progress spinner","order":0,"width":0,"height":0,"format":"<v-progress-circular v-model=\"msg.payload\" :size=\"128\" :width=\"12\"></v-progress-circular>\n","storeOutMessages":true,"fwdInMessages":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":810,"y":80,"wires":[[]]},{"id":"8f3e6631414aa096","type":"inject","z":"24065a0aadb305e3","name":"Inject deadline","props":[{"p":"payload"}],"repeat":"1","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"deadline","payloadType":"flow","x":140,"y":80,"wires":[["293cd6f9d727fa02"]]},{"id":"bd9032719d24a53d","type":"ui-button","z":"24065a0aadb305e3","group":"8fa772a709ae3316","name":"","label":"Reset","order":0,"width":0,"height":0,"passthru":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","payload":"","payloadType":"date","topic":"deadline","topicType":"msg","x":170,"y":140,"wires":[["61ef83d8b06ff626"]]},{"id":"61ef83d8b06ff626","type":"change","z":"24065a0aadb305e3","name":"","rules":[{"t":"set","p":"deadline","pt":"flow","to":"","tot":"date"}],"action":"","property":"","from":"","to":"","reg":false,"x":350,"y":140,"wires":[[]]},{"id":"293cd6f9d727fa02","type":"change","z":"24065a0aadb305e3","name":"Secs since reset","rules":[{"t":"set","p":"payload","pt":"msg","to":"($millis() - msg.payload)/1000","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":340,"y":80,"wires":[["9742da7e74fd3cd2"]]},{"id":"9742da7e74fd3cd2","type":"range","z":"24065a0aadb305e3","minin":"0","maxin":"60","minout":"0","maxout":"100","action":"clamp","round":false,"property":"payload","name":"Seconds to percentages","x":570,"y":80,"wires":[["ce9bb8f74e3fc934"]]},{"id":"8fa772a709ae3316","type":"ui-group","name":"Group Name","page":"5bedf7f49d5a6037","width":"6","height":"1","order":"","disp":true},{"id":"e5a3f4cdb11e5e3b","type":"ui-base","name":"UI Name","path":"/dashboard"},{"id":"5bedf7f49d5a6037","type":"ui-page","name":"Page Name","ui":"e5a3f4cdb11e5e3b","path":"/","layout":"grid","theme":"8240fbe7c09bc81c"},{"id":"8240fbe7c09bc81c","type":"ui-theme","name":"Theme Name","colors":{"surface":"#ffffff","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"}}]
```
::


# Integrate your own widgets with Dashboard 2.0

With a new release, comes new features for Dashboard 2.0, and the focus of this release has been on improving the developer experience for those building third-party widgets for Dashboard 2.0.

Dashboard 1.0 had a hugely popular ecosystem of third party widgets (e.g. `ui-worldmap`, `ui-svg`) and something we've been keen to support is a platform where these widgets (and more) can be built and used within Dashboard 2.0 too.

Whilst we can't support the existing Dashboard 1.0 extensions directly (given that we're now VueJS-based, rather than AngularJS), we hope that the framework, documentation and this article, will help springboard the community to build new (and transfer over old) widgets for Dashboard 2.0.

## Building from `ui-template`

As with Dashboard 1.0, we've utilised the flexibility of our `ui-template` node here to enable third-party integrations.

If you're used the new `ui-template` in Dashboard 2.0 already, you'll know that you can provide raw Vue (HTML) content and it'll render that into your Dashboard. In 0.6.0, we've added *a lot* of new functionality to the guts of `ui-template`, which we can then extend with our third-party widgets.

This new functionality includes:

- **Custom Dependencies** - Injection of external widget dependencies (e.g. other JavaScript libraries) via `<head>`.
- **On Input** - `onInput` defines behaviour of the widget in Dashboard when it receives a message in Node-RED.
- **On Load** - `onMounted` defines functionality when a widget first loads in Dashboard.
- **Custom Functions** - Define general functions that can be called from within your widget at any point of your choosing
- **Extend Built-In Events** - Our built in `send` function can be called within your widget's template, and will send a message back to Node-RED, with any content of your choosing.
- **Custom SocketIO Event Handlers** - If you want to extend the communication between Dashboard and Node-RED, you can emit your own SocketIO events from Dashboard, and have respective handlers for those events in Node-RED.

We also have plans to expose more of this new functionality to the `ui-template` interface itself within Node-RED, but for now it's mostly available when developing third-party widgets.

## Useful Resources

If you're interested in building integrations, then we've also built a couple of resources to help you get started:

- [Widget Development Guide](https://dashboard.flowfuse.com/contributing/widgets/third-party.html){rel="&#x22;nofollow&#x22;"} - A guide for how to structure your own widgets, and
- [Example Integration (Repo)](https://github.com/FlowFuse/node-red-dashboard-example-node){rel="&#x22;nofollow&#x22;"} - We've open sourced a very simple `ui-example` node that demonstrates how you can build your own widget for Dashboard 2.0, that utilises all of the features highlighted above.

## What else is new in 0.6.0?

Whilst we focussed this article on the third-party integrations, we did also squeeze quite a lot more into the 0.6.0 release too with plenty [other fixes and improvements](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v0.6.0){rel="&#x22;nofollow&#x22;"}, including the separation of the Dash oard 2.0 nodes into a new "Dashboard 2" category in the Node-RED palette.

As always, thanks for reading and your interested in Dashboard 2.0. If you have any feature requests, bugs/complaints or general feedback, please do reach out, and raise issues on our relevant [GitHub repository](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.

- [Dashboard 2.0 Activity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}
- [Dashboard 2.0 Planning Board](https://github.com/orgs/FlowFuse/projects/15/views/4){rel="&#x22;nofollow&#x22;"}


# Embracing Innovation: Build vs Buy in MES

Manufacturing companies often struggle to choose between building custom MES solutions or buying ready-made software. Both options have their strengths, but they can fall short of providing the flexibility and control engineers need. A hybrid approach, combining the best of both worlds, is changing the game. In this article, we’ll explore how Node-RED and FlowFuse make it easier to create MES systems that are efficient, adaptable, and perfectly suited to your needs.

## The Hybrid Approach: A Best of Both Worlds Strategy

Much like the practice of outsourcing machine installation while specifying detailed requirements, a hybrid approach to MES systems leverages the expertise of SI companies while retaining control over critical aspects of system design. This approach recognizes that automation engineers possess valuable insights into the unique needs of their manufacturing processes. They can specify crucial details such as wire coloring schemes, downtime conventions, Andon board standards, PLC types, and even the code used on PLCs.

## Node-RED: The MES Code's Best Friend

Node-RED emerges as a game-changer in this paradigm. It is an open-source, flow-based development tool renowned for its ability to connect everything, from PLCs to relational databases to firewalls, empowering engineers to create MES system logic visually. Node-RED simplifies the process by enabling engineers to drag and drop nodes and wires to define the logic flow. This visual approach not only streamlines development but also enhances the transparency of the codebase.

## The Power of Standardization and Code Clarity

One of the primary reasons behind Node-RED's appeal is its ability to standardize code. Just as Ladder Logic and Function Block Diagrams have long been favored for their clarity, Node-RED fosters a coding environment where engineers can easily understand and build upon each other's work. This standardization ensures that MES systems remain in sync with the rest of the plant, making troubleshooting and maintenance more efficient.

## FlowFuse: Bridging the Gap to Deployment

When it comes to deploying MES systems, FlowFuse enters the scene as a vital companion to Node-RED. FlowFuse is a deployment platform that seamlessly integrates with Node-RED, allowing for effortless deployment of applications to a customer's environment. Its user-friendly interface makes it easy for automation engineers to manage and scale their MES systems.

## Pioneering the Future: The Strategic Adoption of Node-RED and FlowFuse

Embracing Node-RED and FlowFuse in MES system development is not just a technical choice; it's a strategic one. By adopting this hybrid approach, manufacturing companies position themselves as thought leaders in the industry. They demonstrate a commitment to innovation, transparency, and adaptability.

## Elevate Your MES Strategy: Embrace Node-RED and FlowFuse Today

In conclusion, the answer to the build vs. buy dilemma for MES systems is not one or the other, it's both. Node-RED and FlowFuse offer a dynamic partnership that empowers manufacturing companies to craft MES solutions that are tailored to their needs while harnessing the expertise of System Integration companies. The call to action is clear: Embrace Node-RED and FlowFuse as the catalysts for your manufacturing innovation journey.

For more information about FlowFuse and how it can revolutionize your MES system deployment, visit FlowFuse.com Start building MES systems that are not just efficient but also future-ready, and become a trailblazer in the world of industrial manufacturing.


# Service Disruption Report for October 11th, 2023

On October 11th, 2023, we had an issue where users were not able to access the
Node-RED editor, recieving a 'Access Denied' error message.
This post examines the issue that was hit, the timeline of events and
what we've done to resolve it.

## Summary

As part of our company rebranding, we planned a migration for our FlowFuse Cloud
platform from `app.flowforge.com` to `app.flowfuse.com`.

We applied this change in co-ordination with our customers using Single Sign On
as it required an update to their configuration to match.

This was done on Tuesday October 10th and all confirmed working with those customers.

On Wednesday October 11th we received two reports that separate users could not
access their Node-RED editors. We quickly identified the issue was related to
how the Node-RED editors authenticated users against the platform for non-SSO users.

A workaround was identified to ensure users were logged in via the new domain.

We then looked at options to mitigate this for other users. We could not roll
back the domain name migration as it would have required co-ordinated action with
multiple SSO customers - who were not otherwise impacted by this issue.

## Resolution

We tested various approaches of adding automatic redirection from one domain to
the other. Due to the fact all existing Instances and Devices had the old domain
name hardcoded into their settings, we were limited in what we could do here.

We ultimately applied a single redirect for `https://app.flowforge.com` to
`https://app.flowfuse.com` - without any redirecting of paths beneath either domain.

This URL is only accessed by real users when coming to log into the platform. By
redirecting at that point in time, it ensures they are logged into the new domain
and everything works as expected.

For users with active sessions on the old domain, a simple log out and log back in
will get them on to the new domain.

## Next Steps

Having resolved the immediate issue we looked at how this situation came to happen
and why it wasn't caught in our preparation for the migration.

We have a staging environment where we verify any changes before they get applied
to production. We all have SSO enabled in that environment and a small number of
test users without SSO enabled.

Our testing had focused on the SSO users which, by virtue of the SSO process, ensured
they ended up logged into the new domain.

The testing done with non-SSO users was more limited and didn't hit the right combination
of having existing log sessions on one or other of the domains to match the scenario
hit by our customers.

We also identified some items to follow up on around how the existing Instances
and Devices handle HTTP redirects. Currently, the Device Agent is not configured
to follow redirects. That is a change we have [added to the backlog](https://github.com/FlowFuse/device-agent/issues/182){rel="&#x22;nofollow&#x22;"}.

## Timeline

*All times are BST.*

**Tuesday October 10th**

We updated the platform's primary domain name to `app.flowfuse.com` whilst keeping `app.flowforge.com` active. This was done in co-ordination with our SSO customers who needed to make an update to their SSO configuration at the same time. Both customers reported success following the change.

Our own validation demonstrated we could login via our own SSO, access editors, and devices continued to work as before (in particular, device editor and snapshot gathering).

**Wednesday October 11th**

- **11:50** and **11:57** - we received two support request from a user getting an 'access denied' error when trying to access an editor.
- **12:09** - Workaround shared with both customers to login via the new domain first
- **12:30** - We applied a blanket redirect for `app.flowforge.com` to `app.flowfuse.com`.
- **12:50** - We then reduced the scope of the redirect so that devices would not be impacted
- **13:14** - A secondary issue with logging into the editor when logged in on the new domain was reported internally.
- **13:44** - Reverted all of the redirect handling whilst reviewing the problems with the previous redirects.
- **14:20** - We applied a redirect to just the root of the domain and documented for our support channel

No further reports were received after this time.


# How to Use Private Custom Nodes in FlowFuse?

With version 1.12 of FlowFuse, it is now possible to use your custom nodes. In this article, we'll explain how to do that.

::div{.blog-update-notes}
**UPDATE:** Since this article was published, we've made this even easier on FlowFuse!

Now, FlowFuse includes a private registry for all Team and Enterprise Tier customers, so there is no need to host and manage your own.

You can view our documentation on this feature [here](https://flowfuse.com/docs/user/custom-npm-packages/)
::

What do we mean by custom nodes? Typically, Node-RED nodes are hosted publicly on the npmjs registry, making them accessible to everyone for download and contribution. However, there are use cases where you may not want to share your developed nodes publicly. In such scenarios, it becomes necessary to run your own private Node-RED catalog and npm repository. This approach allows you to manage your custom nodes securely and efficiently.

## Step 1 - Setting Up a Private npm Repository

Before you can use custom nodes, you'll need a place to store them.

### Option 1 - Service Provider

Choose a public service provider, like [npmjs](https://www.npmjs.com/){rel="&#x22;nofollow&#x22;"}, that allows you to host private packages and upload your node module.

### Option 2 - Verdaccio

Another option is to use Verdaccio, a lightweight private npm proxy registry that allows you to run your own registry.

#### Installing Verdaccio

1. Install Verdaccio using npm:

```sh
npm install -g verdaccio
```

2. Run Verdaccio:

```sh
verdaccio
```

This will start Verdaccio on `http://localhost:4873`

#### Configuring Verdaccio

The default configuration supports scoped packages and allows any user to access all packages, although only authenticated users can publish.

If necesarry you can edit the Verdaccio configuration file, usually found at **\~/.config/verdaccio/config.yaml**.

Refer to the [documentation](https://verdaccio.org/docs/configuration/){rel="&#x22;nofollow&#x22;"} for all configuration options.

It is important that if you intend to use a private NPM registry with FlowFuse Cloud, the registry will need to be publicly exposed to the internet. Please make sure you understand how to secure it appropriately.

#### Publish your package

1. Create a user

```sh
npm adduser --registry http://localhost:4873/
```

2. Publish you package

```sh
npm publish --registry http://localhost:4873/
```

## Step 2 - Creating Your Private Node-RED Catalog

There are several ways to generate your own `catalogue.json`, which is necessary for Node-RED to understand which packages are available where. Below, we'll show you two of the many options to create and host a `catalogue.json`.

### Option 1 - Web App

To create and host a Node-RED catalog, we recommend the package [`node-red-private-catalogue-builder`](https://github.com/hardillb/node-red-private-catalogue-builder){rel="&#x22;nofollow&#x22;"}.

The container accepts the following environment variables:

- PORT - Which port to listen on (defaults to 3000)
- HOST - Which local IP Address to bind to (defaults to 0.0.0.0)
- REGISTRY - A host and optional port number to connect to the NPM registry (defaults to http\:/ registry:4873)
- KEYWORD - The npm keyword to filter on (defaults to Node-RED)

**It presents 2 HTTP endpoints**

- /update - a POST to this endpoint will trigger a rebuild of the catalogue
- /catalogue.json - a GET request returns the current catalogue

The `/update` endpoint can be used with the Verdaccio [notification](https://verdaccio.org/docs/notifications){rel="&#x22;nofollow&#x22;"} events to trigger the catalogue to automatically when nodes are added or updated.

```yaml
notify:
  method: POST
  headers: [{'Content-Type': 'application/json'}]
  endpoint: http://localhost:3000/update
  content: '{"name": "{{name}}", "versions": "{{versions}}", "dist-tags": "{{dist-tags}}"}'
```

### Option 2 - Node-RED

You can also use a FlowFuse Node-RED instance and the [`node-red-contrib-catalogue`](https://flows.nodered.org/node/node-red-contrib-catalogue){rel="&#x22;nofollow&#x22;"} package to generate and host your `catalogue.json` file.

:iframe{allow="clipboard-read; clipboard-write" height="100%" src="https://flows.nodered.org/flow/1f01a92fdbd4172c75fcb88b44e64954/share" style="border: none;" width="100%"}

## Step 3 - FlowFuse configuration

Next, you'll need to add all the details to your FlowFuse instance configuration.

1. Add the Catalog: Go to your **Instance** -> **Settings** -> **Palette**. Here, you'll have the option to add a catalogue.json. You'll need to provide the URL from which the catalogue.json can be accessed.

For example: &#x2A;*<https://catalogue.nodered.org/catalogue.json>{rel="&#x22;nofollow&#x22;"}**

It is import to remember that this URL must be accessible from the browser running the Node-RED editor and when used with FlowFuse (or any other Node-RED editor accessed via HTTPS) it must be served with HTTPS.

2. Modify the npmrc File: You'll need to configure where to find the packages from the catalog, possibly specifying a scope.

```text
# Set a new registry for a scoped package
@myscope:registry=https://mycustomregistry.example.org
```

If necessary, set authentication-related configurations. See the [documentaion](https://docs.npmjs.com/cli/v9/configuring-npm/npmrc#auth-related-configuration){rel="&#x22;nofollow&#x22;"} for details.

3. Save and Restart Your Node-RED Instance: The new npm modules should now be visible in the Node-RED Palette Manager.


# Integrate with ChatGPT Assistants with Node-RED

## Introduction to the World of GPTs and AI Assistants

In the ever-evolving landscape of artificial intelligence, Generative Pre-trained Transformers (GPTs) have emerged as groundbreaking tools. These advanced AI models, developed by OpenAI, are capable of understanding and generating human-like text, offering vast possibilities across numerous applications. GPTs learn from various internet texts, enabling them to respond to queries with human-like understanding.

Among the most intriguing developments in this field are AI Assistants. These are specialized applications of GPTs, accessible through an API, designed to enhance and streamline various tasks. Tasks that include code interpreter, functions, retrieval, and leveraging uploading files to interact with. Unlike traditional GPTs, which primarily focus on generating text, AI Assistants can interact, comprehend, and assist in real-time, making them invaluable in industries ranging from manufacturing to finance to healthcare.

[TLDR: Give me the Flows](https://flows.nodered.org/flow/073548c276832e804f037f3212014e60){rel="&#x22;nofollow&#x22;"}

## Node-RED and AI Assistants

The integration of Node-RED with AI Assistants brings a unique set of advantages. By leveraging Node-RED's user-friendly platform, developers and citizen developers can easily harness the power of AI Assistants. This integration allows for creation of bespoke solutions tailored to specific industry needs, ranging from automated customer service to advanced data analytics. The real-world impact is substantial – imagine a manufacturing line where real-time data is seamlessly integrated with a prescriptive AI-driven decision-making prompt, enhancing efficiency and reducing downtime. In healthcare, it provides patients with real-time updates to their personal data and provides contextual information, while in retail, it could enhance customer engagement through personalized interactions. The future shaped by these technologies is one where automation and intelligence converge, leading to unprecedented levels of efficiency and innovation in various sectors.

## Experience the Integration Firsthand

We invite you to explore the possibilities firsthand. Try out the flows we've created and share your feedback. This is your getting started package. In the provided flows, you can do the following:

![OpenAI Assistant integration on Node-RED](https://flowfuse.com/blog/2023/11/images/ai-flows.png)

1. **Create Assistant**: This flow creates a new assistant. It starts with an inject node that sets the assistant's name, instructions, tools, and model. The HTTP request node then sends a POST request to the OpenAI API to create the assistant. The assistant's ID is stored in the flow context for later use.
2. **List Assistants**: This flow lists all the assistants that have been created. It starts with an inject node that triggers the flow. The HTTP request node sends a GET request to the OpenAI API to retrieve the list of assistants. The results are then displayed in the debug node.
3. **Delete Assistant**: This flow deletes an assistant. It starts with an inject node that sets the assistant's ID. The template node constructs the URL for the HTTP request node, which sends a DELETE request to the OpenAI API to delete the assistant. The results are then displayed in the debug node.
4. **Adjust Assistant Instructions and Models**: This flow adjusts the instructions and model of an assistant. It starts with an inject node that sets the assistant's ID, new instructions, and new model. The change node prepares the payload for the HTTP request node, which sends a POST request to the OpenAI API to update the assistant. The results are then displayed in the debug node.
5. **Create Thread and Run**: This flow creates a new thread and runs it. It starts with an inject node that sets the assistant's ID and the message to be sent. The subflow node then handles the creation of the thread, sending of the message, and retrieval of the response. The results are then displayed in the debug node.

How do you envision leveraging this integration in your day-to-day operations or within your industry? Your insights are valuable in shaping the future of our industry. Begin your journey [here.](https://flows.nodered.org/flow/073548c276832e804f037f3212014e60){rel="&#x22;nofollow&#x22;"}

## Embracing the Future of AI and Automation

Integrating Node-RED with OpenAI's Assistants is a testament to the ever-evolving landscape of technology. It represents a step towards a future where powerful AI tools are within reach of a wider audience, enabling the creation of bespoke, flexible, and resilient applications across industries. By embracing this integration, we open doors to innovation and efficiency previously unimagined.

*Always consult with management before uploading company data to public services like ChatGPT.*


# Node-RED Builder a GPT (Alpha) by FlowFuse

When ChatGPT was first released, my expectations were quite low. I had grown accustomed to the usual industry buzz for AI and ML that often led to underwhelming solutions. Naturally, I approached ChatGPT with similar reservations. It wasn't until a few months after its announcement that I decided to give it a try. To my surprise, within just 10 minutes, I found myself so captivated that I decided to purchase the pro version.

On November 6th, OpenAI unveiled a new offering: GPTs. These function as custom ChatGPT environments, allowing the author to provide additional context, giving it a specific and focused purpose. With new content emerging daily for both Node-RED and FlowFuse, the ability to update and provide essential documentation became increasingly valuable.

ChatGPT is already a fantastic tool for building Node-RED flows, and if you haven't tried it yet, I highly recommend giving it a go. Now, let me introduce you to Node-RED Builder, a preconfigured environment where all the necessary prompts are already set up to ensure your success. Furthermore, the latest knowledge on Node-RED and FlowFuse is readily available within the GPT, allowing you to tap into the most up-to-date documentation for your prompts.

Node-RED Builder streamlines the development of Node-RED flows, making it more accessible, especially for those new to this environment. We've even provided context to emphasize the use of default nodes over function nodes. Imagine being able to simply drag and drop elements, connect nodes, and create functional flows without delving deep into complex coding. This is precisely what Node-RED Builder makes easier, effectively opening the doors of Node-RED to a wider audience.

[Access to the GPT - Node-RED builder by FlowFuse](https://chat.openai.com/g/g-V5Kyn4omE-node-red-builder-by-flowfuse-v1-0-2){rel="&#x22;nofollow&#x22;"}


# Community News November 2023

Welcome to the FlowFuse newsletter for November 2023, a monthly roundup of what’s been happening with FlowFuse and the wider Node-RED community.

## FlowFuse Team Summit - Barcelona by Grey

The first week of November in Barcelona, the FlowFuse team embraced a blend of culture, collaboration, and creativity at our biannual summit. As a global remote-first company, these gatherings are key to nurturing the camaraderie and clear communication that fuels our work.

My first summit was a vibrant tableau of wit and good-natured sarcasm, a perfect fit for my sense of humor. But it wasn't just about the fun; we delved deep into aligning our strategies to streamline communication with the vast community that recognizes the value of Node-RED.

From segway tours through historic streets to culinary competitions, we bonded and built memories. During the day, we crafted go-to-market strategies, fortified our team dynamics through board games, and honed our sales approaches. The latest dashboard visualizations and product roadmaps were discussed, with our shared vision to simplify the complex for companies worldwide.

**“The easy things should be easy, and the hard things should be possible.”**

Our goal remains steadfast: to enhance bidirectional communication with you, our valued community, and make Node-RED's power more accessible than ever.

![](https://flowfuse.com/blog/2023/11/images/IMG_6334.jpg){width="500"}

## Announcements TLDR

We're excited to share some significant enhancements that will elevate your experience with FlowFuse and Node-RED. We've announced that Dashboards 2.0 are in Beta version. Recent additions to Dashboards 2.0 include integrating Vuetify and Mermaid into Dashboard 2.0 unlocking a suite of custom UI components to enrich your dashboards. Our step-by-step guide will walk you through creating dynamic elements like countdown timers, leveraging the power of VueJS for seamless updates.

We're also thrilled to introduce FlowFuse Blueprints - a game-changer in building bespoke, flexible, and resilient manufacturing applications. Our initial set of Blueprints, including ANDON Operator Terminal, Performance Overview Dashboard, and OEE Calculator, provide preconfigured Node-RED applications that streamline your development process. Dive into the world of Blueprints and discover how they can accelerate your project's journey from concept to operational reality. Join the [webinar](https://flowfuse.com/webinars/2023/blueprints/) to find out more.

## Recent Changelog Updates

- [Integrate your own widgets with Dashboard 2.0](https://flowfuse.com/blog/2023/10/dashboard-integrations/)
- [Blueprints](https://flowfuse.com/changelog/2023/10/blueprints/)
- [Enhanced Snapshot Selection](https://flowfuse.com/changelog/2023/10/device-snapshot-selection/)
- [Device Agent path bug fix](https://flowfuse.com/changelog/2023/10/path-bug-fix/)
- [Resource Monitoring in Audit Log](https://flowfuse.com/changelog/2023/10/resource-alerts/)
- [Certified Nodes](https://flowfuse.com/changelog/2023/10/certified-nodes/)

## Upcoming events

### FlowFuse Blueprints: Your Pathway to Enhanced Manufacturing

Explore building manufacturing applications with FlowFuse Blueprints in our upcoming webinar. Blueprints make it easy to get started building applications with Node-RED.

[Sign-up today](https://flowfuse.com/webinars/2023/blueprints/) to join us on November 30th.

## From our Blog

- [Meet FlowFuse at SPS Nuremberg](https://flowfuse.com/blog/2023/11/meet-us-at-sps-nuremberg/) - Talk about Node-RED and how FlowFuse can help you operationalize your flows!
- [Install the FlowFuse Edge Agent on the Raspberry Pi 5](https://flowfuse.com/node-red/hardware/raspberry-pi-5) - Managing your Raspberry Pi 5 with Node-RED through FlowFuse is easy to set up
- [Innovate from within - Why manufacturing must embrace Citizen Developers](https://flowfuse.com/blog/2023/10/citizen-development/) - Empower your Operational Technology teams as Citizen Developers
- [Embracing Innovation: Build vs Buy in MES](https://flowfuse.com/blog/2023/10/mes-build-buy/) - Bridging the Gap: Uniting MES Development with Automation System Practices
- [What are FlowFuse Blueprints?](https://flowfuse.com/blog/2023/10/blueprints/) - Preconfigured Node-RED Applications
- [Integrate your own widgets with Dashboard 2.0](https://flowfuse.com/blog/2023/10/dashboard-integrations/) - With the 0.6.0 Release of Dashboard 2.0, we now support third-party widget integration. Read more in this deep dive.
- [What are FlowFuse Blueprints?](https://flowfuse.com/blog/2023/10/blueprints/) - Preconfigured Node-RED Applications

## Join Our Team

FlowFuse is expanding our team. Check out the current openings:

- [Contract Front-End Engineer – Node-RED Dashboard](https://boards.greenhouse.io/flowfuse/jobs/4911532004){rel="&#x22;nofollow&#x22;"}


# Chart Improvements & Migrating to Dashboard 2.0

It's been a little while since we've done an update, since we last posted we've moved into the 0.7.x releases for Dashboard 2.0. With these we're making big strides in improving the UX for charting your data, as well as starting to focus on migration paths from Dashboard 1.0 to 2.0.

## Package Name Changes

Firstly a bit of news regarding the `npm` package we publish. Inline with our own [company name change](https://flowfuse.com/blog/2023/08/flowforge-is-now-flowfuse), we've had to update Dashboard 2.0's npm package, and so, we've changed from `@flowforge/node-red-dashboard` to `@flowfuse/node-red-dashboard`.

In the short term, we'll be keeping @flowforge available on the Node-RED Palette Manager, but it will be removed soon, and the associated NPM Package will be put into a "deprecated" mode.

### NPM Package Migration

Unfortunately, this migration from `@flowforge/` to `@flowfuse/` requires a little bit of manual work, and isn't as easy as just clicking "update" in the Node-RED Editor.

In any case, there is no need to update your flow in this migration, you'll just need to uninstall `@flowforge/node-red-dashboard` and install `@flowfuse/node-red-dashboard` instead.

#### Running Locally

If you're running Node-RED locally, or in your own infrastructure, you'll need to manually uninstall the old package:

```bash
npm uninstall @flowforge/node-red-dashboard
```

and re-install the new one:

```bash
npm install @flowfuse/node-red-dashboard
```

#### Running in FlowFuse

Navigate to your Instance > Settings > Palette, and then change the `@flowforge/node-red-dashboard` entry to `@flowfuse/node-red-dashboard` (the latest version as of this post is `0.7.2`).

Restart your instance, and the new package will automatically install.

## Dashboard 1.0 to 2.0 Migration Guide

As part of our mission to ensure a smooth transition from Dashboard 1.0 to Dashboard 2.0, we have published a first draft of a [Migration Guide](https://dashboard.flowfuse.com/user/migration.html){rel="&#x22;nofollow&#x22;"}.

As a starting point, we have comprehesively covered the Dashboard 1.0 widgets and their associated properties. We've then detailed which properties are already supported, which have partial support, and where appropriate, we do not support and *why* (most of the time, it's just because we haven't got round to it yet!)

![Migration Guide Snippet](https://flowfuse.com/blog/2023/11/images/migration-guide-snippet.png)

We fully appreciate that the migration path is not yet complete, and we that we are missing some features and properties, but please know that we are working hard to ensure that as many of the features from Dashboard 1.0 are available in Dashboard 2.0. We will be updating this guide as we progress.

We will also be adding "event" and "dynamic properties" sections to the guide, to detail how you can update and control elements via runtime messages (e.g. dynamically change the label of a button), and how this differs (if at all) from Dashboard 1.0.

Whilst we aren't quite there yet, this guide offers a comprehensive breakdown on our progress in backporting all of the properties from Dashboard 1.0

### Automated Script

An ambitious plan that we have is to also provide a [Migration Script](https://github.com/FlowFuse/node-red-dashboard/issues/261){rel="&#x22;nofollow&#x22;"}. Any feedback, ideas or concerns are most welcome as comments on the issue.

Whilst this will never provide 100% perfect migration, we hope to be able to provide a script that can be run against your flows to automatically convert as much as possible from Dashboard 1.0 to 2.0. In most cases, as you can see in the Migration guide, we match most properties 1:1, so this should do a lot of the heavy lifting for you.

## Updates to UI Chart

### Key Mapping

One of the core purposes of Node-RED Dashboard has always been to provide low-code access to charting your data. With the 0.7.x releases we've made some big improvements to the UI Chart node to make it easier to use and more powerful.

In Dashboard 1.0, it was common place to have to regularly re-format your own data into `{x, y}` structure to be chart-friendly. In `0.7.0` we've introduced the concept of **key mapping**, where you can specify which keys in your data object should be used for the x and y axes. This means you can now pass in data in the format you want to use, and the chart will do the rest.

For example, when rendering a chart of our weekly npm downloads, we have a data structure:

```json
[{
    "day": "YYYY-MM-DD",
    "downloads": 128
}, {
    "day": "YYYY-MM-DD",
    "downloads": 256
}, {
    "day": "YYYY-MM-DD",
    "downloads": 512
}]
```

Rather than having to pipe this into a `function` node and re-map the properties to `{ x, y }`, we can now use the `ui-chart`'s key mapping properties:

![ui-chart-key-mapping](https://flowfuse.com/blog/2023/11/images/ui-chart-keymap-properties.png)

Resulting in the following chart:

![ui-chart-key-mapping](https://flowfuse.com/blog/2023/11/images/ui-chart-mapping.png)

### Multiple Lines

Note above, another new option has been added to define &#x2A;"Series"*. In Dashboard 1.0 this was fixed as `msg.topic` at all times, and defined which line/series data points rendered too. Now, this is configurable, and can even be set as a `key:` type too, whereby each data point being treated individually, and grouped based on a given key/property.

Another great new feature here is the type `JSON` for this property. We can provide a *list* of series labels, and the chart will render each value from a single data point as separate lines.

For example, if we consider the data:

```json
[{
    "day": "2023-10-23",
    "temperature": 28,
    "humidity": 16
}, {
    "day": "2023-10-24",
    "temperature": 26,
    "humidity": 19
}, {
    "day": "2023-10-25",
    "temperature": 27,
    "humidity": 24
}]
```

We can provide a series: `["temperature", "humidity"]` like so:

![ui-chart-key-mapping](https://flowfuse.com/blog/2023/11/images/ui-chart-series-property.png)

Which would result in the following plot:

![ui-chart-key-mapping](https://flowfuse.com/blog/2023/11/images/ui-chart-multipoint.png)

We appreciate this offers a new way of working with data in Dashboard, but hopefully, once you've tried it, you'll find it much easier to work with, and see the value it brings when working with your own data sets.

## What else is new in 0.7.x?

Whilst we focussed this article on the migration paths and new UI Chart features, we did also squeeze quite a lot more into the 0.7.x releases too with plenty other fixes and improvements:

- [Re-architecture of Server-side State Management](https://github.com/FlowFuse/node-red-dashboard/pull/279){rel="&#x22;nofollow&#x22;"}
- [Y Axis Min/Max Options](https://github.com/FlowFuse/node-red-dashboard/pull/327){rel="&#x22;nofollow&#x22;"}
- ["Focus" button for widgets added to Sidebar](https://github.com/FlowFuse/node-red-dashboard/pull/320){rel="&#x22;nofollow&#x22;"}
- [No more "blue screen" and improved error reporting](https://github.com/FlowFuse/node-red-dashboard/pull/310){rel="&#x22;nofollow&#x22;"}
- [Better route handling](https://github.com/FlowFuse/node-red-dashboard/pull/301){rel="&#x22;nofollow&#x22;"}

You can also read the more comprehensive release notes for each release here:

- [0.7.0 Release Notes](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v0.7.0){rel="&#x22;nofollow&#x22;"}
- [0.7.1 Release Notes](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v0.7.1){rel="&#x22;nofollow&#x22;"}
- [0.7.2 Release Notes](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v0.7.2){rel="&#x22;nofollow&#x22;"}

## Follow our Progress

As always, thanks for reading and your interested in Dashboard 2.0. If you have any feature requests, bugs/complaints or general feedback, please do reach out, and raise issues on our relevant [GitHub repository](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.

- [Dashboard 2.0 Activity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}
- [Dashboard 2.0 Planning Board](https://github.com/orgs/FlowFuse/projects/15/views/4){rel="&#x22;nofollow&#x22;"}


# Overhauling the Dashboard 2.0 Build Pipeline

As a developer, sometimes you have to hold up your hands and realise something you've spent two weeks building needs to be thrown away and restarted.

Having shipped the [third-party widget support for Dashboard 2.0](https://flowfuse.com/blog/2023/10/dashboard-integrations/) in line with Dashboard 1.0's approach, we then had the [feedback](https://github.com/FlowFuse/node-red-dashboard/issues/307){rel="&#x22;nofollow&#x22;"} that the way Dashboard 1.0 did things really wasn't good, and asking us to consider re-building the process to make the developer experience of working with Dashboard 2.0 far more seamless.

So, that's exactly what we've done with the `0.8.0` release, amongst a few other things.

::div
---
style: "background-color: #fff4b9; border:1px solid #ffc400; color: #a27110;
  padding: 12px; border-radius: 6px; font-style: italic;"
---
Reminder: all new releases of Dashboard are now under the `@flowfuse`{style="background-color: transparent;"} namespace, so you'll need to update to use `@flowfuse/node-red-dashboard`{style="background-color: transparent;"}, and not `@flowforge`{style="background-color: transparent;"}.
::

## Migrating our Build Pipeline

Without getting *too* technical, as part of this work in supporting third-party widgets, we overhauled our build pipeline for Dashboard 2.0. This pipeline is responsible for taking our source code, and compiling it into a format that then gets deployed by Node-RED when running Dashboard.

Previously, we used &#x2A;**Webpack**&#x2A;, but now, we've switched over to &#x2A;**Vite***. This is a newer build tool, and is much faster than Webpack. It's also what we've now updated out [Example Node](https://github.com/FlowFuse/node-red-dashboard-2-ui-example){rel="&#x22;nofollow&#x22;"} to use too.

So now, when working with a third-party widget, Vite builds up all of your code, wraps it into a single `umd.js` file, and Node-RED then serves that file up for Dashboard 2.0 to load in.

![Vite Build Process](https://flowfuse.com/blog/2023/11/images/dashboard-build.png)

We've also re-written our ["Building Third Party Widgets"](https://dashboard.flowfuse.com/contributing/widgets/third-party.html){rel="&#x22;nofollow&#x22;"} guide to reflect this change.

## Debugging Dashboard

A new feature we've added in `0.8.0` is also for those developing Dashboard's core and third-party widgets. You can now navigate to `/dashboard/_debug` to explore the full configuration that Dashboard receives from Node-RED.

This is particularly useful when you're trying to debug why a widget isn't loading, showing the correct data, or generally isn't behaving as you expect.

![Dashboard's Debug View](https://flowfuse.com/blog/2023/11/images/debug-view.png)

Note in the above example, where we can see that the `ui-dropdown` has had it's options overriden by `msg.options` on injection.

You can read more about the debugging view [here](https://dashboard.flowfuse.com/contributing/widgets/debugging.html){rel="&#x22;nofollow&#x22;"}

## What else is new in 0.8.0?

Whilst we focussed this article on the build pipeline overhaul, changes to third-party wdgets and debugging Dashboard, we did also squeeze quite a lot more into the 0.8.0 releases too with plenty other fixes and improvements:

- [Dynamic setting of msg.options for UI Dropdown](https://github.com/FlowFuse/node-red-dashboard/pull/345){rel="&#x22;nofollow&#x22;"}
- ["Date" type for UI Text Input](https://github.com/FlowFuse/node-red-dashboard/pull/346){rel="&#x22;nofollow&#x22;"}
- [Finer grain controls of Text Input event emissions](https://github.com/FlowFuse/node-red-dashboard/pull/365){rel="&#x22;nofollow&#x22;"}
- [Control over when UI Slider emits events](https://github.com/FlowFuse/node-red-dashboard/pull/367){rel="&#x22;nofollow&#x22;"}
- [Improved documentation for Bar Charts](https://github.com/FlowFuse/node-red-dashboard/pull/364){rel="&#x22;nofollow&#x22;"}

You can also read the more comprehensive release notes for the release here:

- [0.8.0 Release Notes](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v0.8.0){rel="&#x22;nofollow&#x22;"}

## Follow our Progress

As always, thanks for reading and your interested in Dashboard 2.0. If you have any feature requests, bugs/complaints or general feedback, please do reach out, and raise issues on our relevant [GitHub repository](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.

- [Dashboard 2.0 Activity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}
- [Dashboard 2.0 Planning Board](https://github.com/orgs/FlowFuse/projects/15/views/4){rel="&#x22;nofollow&#x22;"}


# Tracking Who Has Opened a Dashboard

As we continue to add features to the Node-RED Dashboard v2 one feature request that came in was to track which users had visited a Dashboard. Multi user support for the Dashboard is on the backlog but this could be solved with the parts that are currently available.

## FlowFuse Authentication

One of the features we offer on FlowFuse is the ability to protect HTTP endpoints and Dashboards using the same FlowFuse user authentication that protects access to the FlowFuse Application and the Node-RED instances.

We even offer a specific RBAC 'viewer' role that just allows access to these endpoints but not the FlowFuse application.

FlowFuse authentication can be enabled from the Instance Settings page on the Security tab

This can be used to secure access to a Dashboard hosted in a Node-RED Instance. At the moment the Dashboard while protected by this authentication, it is not aware of which user is accessing it.

But if we include an element in the Dashboard loaded via a HTTP-in/HTTP-response node we gain access to details of the authenticated user.

## Implementation

First we will create a HTTP-in/HTTP-response pair to serve up a single pixel SVG image. I chose SVG as it doesn't require creating a binary image file to load.

The following flow snippet includes both the HTTP-in/HTTP-response nodes and a change node to set the `msg.payload` to the SVG content and to set the HTTP headers to include the correct mime type.

There is also a second change node which extracts the user information.

::render-flow
```json
[{"id":"7f22dc81d8192d4d","type":"http in","z":"98c8d7ea66149291","name":"","url":"/tracker","method":"get","upload":false,"swaggerDoc":"","x":210,"y":460,"wires":[["7d36739c02cd04ec","5f4647c97917cce1"]]},{"id":"58fd30516a077e29","type":"http response","z":"98c8d7ea66149291","name":"","statusCode":"","headers":{},"x":630,"y":460,"wires":[]},{"id":"7d36739c02cd04ec","type":"change","z":"98c8d7ea66149291","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"<svg width=\"1\" height=\"1\"> <rect width=\"1\" height=\"1\" style=\"fill:rgb(255,255,255);stroke-width:3;stroke:rgb(0,0,0)\" /> Sorry, your browser does not support inline SVG.</svg>","tot":"str"},{"t":"set","p":"headers","pt":"msg","to":"{\"Content-Type\":\"image/svg+xml\"}","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":420,"y":460,"wires":[["58fd30516a077e29"]]},{"id":"5f4647c97917cce1","type":"change","z":"98c8d7ea66149291","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"req.session.user","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":420,"y":520,"wires":[["ddc02b4e9c30c807"]]},{"id":"ddc02b4e9c30c807","type":"debug","z":"98c8d7ea66149291","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":600,"y":520,"wires":[]}]
```
::

Next we need to add the SVG to the Dashboard, this can be done by adding a Template node with the following HTML content.

```html
<div>
    <object data="/tracker" height="1" width="1"></object>
</div>
```

This will load the image every time the Dashboard page loads and hence trigger the earlier flow allowing the user to be logged.

## Linking to SSO Users

With the release of FlowFuse v1.14.0 the session object will also include the users email address which is the shared identifier between FlowFuse and the SSO system. This will allow the logging to use a single unified identifier.


# Deploying the FlowFuse Device Agent via Balena

As part of the FlowFuse Staff Summit this year in Barcelona we met up with Marc Pous from [Balena Io](https://www.balena.io/){rel="&#x22;nofollow&#x22;"}. Balena is a platform for managing fleets of Edge Devices and it felt like the perfect fit for deploying the FlowFuse Device Agent.

To do this you install the Balena OS on the devices, this is a stripped down Linux distribution that includes a client that connects back to Balena's platform and creates a VPN tunnel. As well as the Balena client it includes Docker and users can select containers to push to the devices.

These Docker container are hosted on Balena's own container registry and are built by doing a git push to Balena's git server.

A GitHub repository with all the required files [has been published](https://github.com/FlowFuse/balena-device-agent){rel="&#x22;nofollow&#x22;"}, a one click deploy button to allow you to quickly try this out.

## Building FlowFuse Device Agent for Balena

We already build a FlowFuse Device Agent Docker container so it was pretty simple to modify the existing `Dockerfile` for Balena.

```docker
FROM balenalib/%%BALENA_MACHINE_NAME%%-alpine-node

RUN mkdir /opt/flowfuse-device
RUN npm install -g @flowfuse/device-agent

COPY entrypoint.sh /usr/src/entrypoint.sh

ENTRYPOINT ["/usr/src/entrypoint.sh"]

CMD ["flowfuse-device-agent"]
```

There were 2 main changes from the default Device Agent [`Dockerfile`](https://github.com/FlowFuse/device-agent/blob/main/docker/Dockerfile){rel="&#x22;nofollow&#x22;"}

1. Change the base image to Balena's image, this is because the `Dockerfile` is actually a template that can be used to build images optimized for all Balena's supported hardware platforms (We currently build the FlowFuse Device Agent containers for AMD64, ARMv7 and ARM64)
2. Adding a custom `entrypoint.sh`. This is to ensure that the hostname seen in the container matches the Balena device name, making it easier to match it up with what is seen in the FlowFuse application. It also generates the configuration file from the passed in environment variable (see [below](https://flowfuse.com/#configuring-devices))

As well as the `Dockerfile` there is also a `docker-compose.yml` because Balena applications can be made up of multiple services packaged as container. In this case we just need a single container but the compose file contains all the information about what ports to expose and what volumes need creating to persist state.

## Configuring Devices

The FlowFuse Device agent can be configured in 2 ways.

1. You can provide a configuration file that is provided by the FlowFuse application when you create a new Device. This file contains the unique identifiers for the Device and details of where to find the FlowFuse Application. This file can be provided to a Balena device by adding a device specific environment variable as described [below](https://flowfuse.com/#environment-variable).
2. You can provide a fleet of devices with a configuration file that contains details of where to find the FlowFuse application and a Provisioning token. Multiple Devices can all have the same Provisioning token and this will cause them to connect to the FlowFuse application on first start up and create a new Device bound to an existing team (and optionally an Application or Instance). This file can be passed to Balena devices by way of a Fleet wide environment variable as described [below](https://flowfuse.com/#environment-variable).
   You can create a Provisioning Token file under the Team -> Settings page on the Devices tab.

### Environment Variable

Because the `device.yml` file is multi line it needs to be base64 encoded, you can do this with the following

```bash
$ base64 -w 0 device.yml
```

You can then use the Balena console to create either a device specific or a fleet wide environment variable called `FF_DEVICE_YML`.

![balena-env-var](https://flowfuse.com/blog/2023/11/images/balena-env-var.png)


# Meet FlowFuse at SPS Nuremberg

FlowFuse is excited to be exhibiting at the SPS in Nuremberg next week. We will
be located in Hall 5 Booth 145.

At the SPS, we will be showcasing our latest FlowFuse platform, which is a
powerful and user-friendly tool for creating and managing Node-RED flows. There's
also an option to get a demonstration of how FlowFuse can be used to solve a
variety of industrial automation problems.

We are also keen to meet with Node-RED users and FlowFuse prospective customers
at the SPS. If you would like to book a meeting with us, please visit our
[contact us](https://flowfuse.com/contact-us/) page.

We look forward to seeing you at the SPS!

### About FlowFuse

FlowFuse is a software company that develops tools for creating and managing
Node-RED flows. Node-RED is a popular open-source platform for flow-based programming. FlowFuse makes it easy to create and manage complex Node-RED flows, even for users with no prior programming experience.

FlowFuse is used by a wide range of organizations, including manufacturers, utilities, and research institutions. FlowFuse is used to solve a variety of industrial automation problems, such as data acquisition, data enrichment,
and process monitoring.

### About SPS Nuremberg

SPS Nuremberg is the world's leading trade fair for electric automation. The fair takes place annually in Nuremberg, Germany. SPS Nuremberg is a showcase for the latest innovations in industrial automation.

We hope to see you at the SPS!


# Beyond Automation - AI Use Cases that are shaping the next manufacturing frontier

Are we standing on the brink of a Fifth Industrial Revolution? The manufacturing industry has been in a state of flux for some time, with the rise of automation and digital transforming the way factories operate. But today, we are witnessing something even more profound: AI is pushing manufacturing to a whole new level. Some have even referred to it as “the fifth industrial revolution” due to its potential for disruption.

But the question lingers for many plant managers and decision makers: in which AI-powered capabilities should one invest to bring about transformative changes in the manufacturing environment?

As we navigate this question, I want to focus on three AI uses that are not only ripe for investment but also pivotal in driving manufacturing success in this competitive market.

## Empowering Citizen Developer Strategy with AI

The concept of citizen development stands as one of the most significant fields in my opinion, a sentiment I've detailed in my [previous article](https://flowfuse.com/blog/2023/10/citizen-development/) about Citizen Developers. This approach is revolutionizing the manner in which applications are crafted and deployed across various industries. By empowering individuals, irrespective of their coding knowledge, to create applications, AI is dramatically hastening this process.

Investing in AI capabilities that bolster your citizen developer strategy can fast-track application development, offering intuitive, template-driven platforms that employ AI to navigate users through the creation process. As we've seen over recent months and years, AI can significantly assist in code generation, thereby granting your citizen developers an even smoother initiation into application development.

An excellent instance of this is the [article and Node-RED Node](https://flowfuse.com/blog/2023/09/chatgpt-for-node-red-developers/) describing the potential for integrating Node-RED with ChatGPT to assist you in building applications. This integration highlights the practical, user-friendly solutions made possible through AI, making the realm of app development accessible to a broader range of innovators.

## Refining Warehouse Management through AI-Driven Demand Forecasting

In an era marked by complexities in supply chains and customer demand, AI's role in warehouse management becomes a game-changer. AI algorithms analyze historical data and market trends to predict future demand with astonishing accuracy, a step beyond traditional forecasting methods.

For decision makers, investing in AI for demand forecasting means significantly minimizing overproduction or stock outs, optimizing inventory levels, and improving customer satisfaction. The advanced analytics offered by AI not only predict what products are in demand but also when and where they are needed, thereby facilitating strategic planning and resource allocation.

## Elevating Predictive Maintenance and Quality Control

Unplanned downtime and quality inconsistencies are two of the biggest profit drains in manufacturing. AI's predictive capabilities are setting new standards in both maintenance and quality control protocols. By continuously monitoring equipment performance and production processes, AI can predict and identify machinery failures before they occur and detect quality deviations in real-time, allowing for immediate correction. Investing here means less downtime, reduced maintenance costs, improved product quality, and ultimately, an enhanced bottom line.

## Your Digital Infrastructure & Architecture is key

While understanding where concrete Use Cases are is crucial, it’s equally important to ensure that your digital strategy and architecture can support and quickly adapt to these advanced AI implementations. See also [my article](https://flowfuse.com/blog/2023/08/isa-95-automation-pyramid-to-unified-namespace/) about the Unified Namespace. A flexible system that integrates a Unified Namespace is critical for seamless data exchange across various systems and applications. Moreover, fostering a citizen developer environment is fundamental in ensuring that these AI investments are maximally utilized, empowering your workforce to contribute actively to the company's innovation cycle.


# Building a Custom Video Player in Dashboard 2.0

Dashboard 2.0 just got *a lot* more powerful with our new updates to the `ui-template` node. New features added to the node include:

- Support for a full Vue component to be defined using the VueJS Options API.
- Running of raw JavaScript within `<script />` tags
- Loading of external dependencies through `<script />` tags

In this article we're going to deepdive into an example of how you can use this new functionality to build a custom video player.

We're going to aim for 3 key features:

1. Emit events into Node-RED when a user plays/pauses the video
2. Allow for the video to be played/paused from within Node-RED
3. Allow the user to seek to a specific point in the video from within Node-RED

::div
---
style: "background-color: #fff4b9; border:1px solid #ffc400; color: #a27110;
  padding: 12px; border-radius: 6px; font-style: italic;"
---
Reminder: all new releases of Dashboard are now under the `@flowfuse`{style="background-color: transparent;"} namespace, so you'll need to update to use `@flowfuse/node-red-dashboard`{style="background-color: transparent;"}, and not `@flowforge`{style="background-color: transparent;"}.
::

## Building a Vue Component

With Dashboard 2.0, we switched over our underlying front-end framework to VueJS. We're aware that not everyone coming into Dashboard 2.0 will be familiar with VueJS.

We have a more detailed guide [here](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html#building-full-vue-components){rel="&#x22;nofollow&#x22;"}, but we'll also give a quick overview of the elements from Vue "component" that we'll use here:

```html
<template>
    <!-- Our HTML content will go here -->
</template>

<script>
export default {
  name: 'MyComponent',
  methods: {
    // JS methods we want to use across our component will go here
  },
  mounted () {
    // Code we want to run when our component is loaded will go here
  },
  unmounted () {
    // Code we want to run when our component is unloaded will go here
  }
}
</script>

<style>
    /* We can define custom CSS here too */
</style>
```

Some quick gotchas to note:

- `<div>{{ msg }}</div>` - is an example of how you render variables into the HTML.
- `<div v-if="myVar"></div>` - lets you conditionally show/hide content based on a variable.
- `<div v-for="item in items"></div>` - lets you loop over an array of items and render them into the HTML.
- `<div @click="myMethod"></div>` - lets you bind a method to an event, in this case, when the user clicks on the div.
- `<div :class="{ 'my-class': isActive }"></div>` - `:` is a way to define a "bound" property. In this case, the class `my-class` will be applied when `isActive` is true.
- `console.log(this.myVar)` - when you're writing code inside the `<script />` tags, you can access Component variables and methods using `this`.

### Built-in Extras

In addition to building a component from scratch, we'll also utilize some built-in features of `ui-template` too. These will be:

- **Variables:**
  - `id` - The unique ID for this node in Node-RED
  - `msg` - The message that was most recently received into the node
  - `$socket` - The underlying SocketIO connection to Node-RED. Use this to listen to any incoming events, and send new ones back.
- **Functions:**
  - `send(payload)` - Send a message back to Node-RED

As above, we have more detailed documentation on these features [here](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html#built-in-functionality){rel="&#x22;nofollow&#x22;"}.

## Building the Video Player

### Defining the Content (HTML)

We're going to start by adding a basic HTML video player:

```html
<template>
    <video ref="my-video" style="width: 100%" controls @play="onPlay" @pause="onPause">
        <source src="http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4" type="video/mp4">
        Your browser does not support the video tag.
    </video>
</template>
```

A few things of importance to note here:

- `ref` is Vue's replacement for `document.getElementById()`. This is copied to each instance of the component, meaning we can call `this.$refs['my-video']` to access the video element, and this doesn't break when duplicating the widget multiple times in Dashboard.
- `style=""` is required here to ensure the video fills the group/wrapper that it is contained within.
- `@play=` is Vue's way of binding onto the standard `onplay` event listener available on HTML video players. We'll define the `onPlay` method in the next section.
- `@pause=` is our event listener for when the video is paused by the user. As with `onPlay`, we'll define this shortly.

With *just* the above defined, we end up with a standard video player rendered:

![HTML5 Video Player rendered in Dashboard](https://flowfuse.com/blog/2023/12/images/dashboard-video-1.png)

### Defining the Behaviors (VueJS)

Now we begin to build our Vue component. Referring back to our earlier set of features, we'll tackle these one at a time.

#### 1. Emitting Events to Node-RED on Play/Pause

We can use `methods` to define our `onPlay` and `onPause` functions that are called `@play`/`@pause` respectively.

```html
<script>
export default {
  name: 'MyVideoPlayer',
  methods: {
    capture (eventType) {
        // let's define our own function that can be called onPlay/onPause
        // this prevents duplicated code across the two methods

        // get the Video's DOM element
        const video = this.$refs['my-video']

        // send a msg to Node-RED using built-in "send" fcn
        this.send({
            // specify which action is taking place
            event: eventType,
            // use Vue's $refs to get the video's currentTime
            time: video.currentTime
        })
    },
    onPlay () {
        this.capture('play')
    },
    onPause () {
        this.capture('pause')
    }
  }
}
</script>
```

With this functionality in place, we can wire the `ui-template` node to a `debug` node, and see the following when we play/pause the video:

![Example debug output when our custom build video player is played/paused](https://flowfuse.com/blog/2023/12/images/dashboard-video-2.png)

#### 2. Remote control of play/pause from Node-RED

We can use the built-in `$socket` variable to listen for incoming events from Node-RED. When Dashboard 2.0's nodes receive a `msg` inside Node-RED, they send a `msg-input:<node-id>` event to the Dashboard client. We can listen for this event and then call the `play()` and `pause()` methods on the video element, depending on any properties of that message, in this case, the `msg.payload.event` value.

```html
<script>
export default {
  name: 'MyVideoPlayer',
  methods: {
    // ...
  },
  mounted () {
    // listen for incoming msg's from Node-RED
    // note our topic is "msg-input" + the node's unique ID
    this.$socket.on('msg-input:' + this.id, (msg) => {
        // get the Video's DOM element
        const video = this.$refs['my-video']

        // if the event is "play", call the video's play() method
        if (msg.payload?.event === 'play') {
            video.play()
        }

        // if the event is "pause", call the video's pause() method
        if (msg.payload?.event === 'pause') {
            video.pause()
        }
    })
  },
  unmounted () {
    // make sure we remove our listeners when the widget is destroyed
    this.$socket.off(`msg-input:${this.id}`)
  }
}
</script>
```

#### 3. Seeking to a specific point in the video from within Node-RED

With the `on('msg-input')` listener in place, we can now extend our handler to handle seeking to a specific point in the video.

```html
<script>
export default {
  name: 'MyVideoPlayer',
  methods: {
    // ...
  },
  mounted () {
    // ...
    this.$socket.on('msg-input:' + this.id, (msg) => {
        // ... other handlers

        // if the event is "seek", call the video's currentTime() method
        if (msg.payload?.event === 'seek') {
            video.currentTime = msg.payload.currentTime
        }
    })
  },
  unmounted () {
    // ...
  }
}
</script>
```

and with that, we now have a Dashboard 2.0 widget to display a video, that can be controlled from Node-RED, and logs details of user activity back into Node-RED.

Other features available with the UI Template are detailed in the online documentation, and include:

- [Loading External Dependencies](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html#loading-external-dependencies){rel="&#x22;nofollow&#x22;"}
- [Running raw JavaScript](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html#writing-raw-javascript){rel="&#x22;nofollow&#x22;"}

## Follow our Progress

You can also read the more comprehensive release notes for `v0.10.0` release here:

- [0.10.0 Release Notes](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v0.10.0){rel="&#x22;nofollow&#x22;"}

As always, thanks for reading and your interest in Dashboard 2.0. If you have any feature requests, bugs/complaints or general feedback, please do reach out, and raise issues on our relevant [GitHub repository](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.

- [Dashboard 2.0 Activity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}
- [Dashboard 2.0 Planning Board](https://github.com/orgs/FlowFuse/projects/15/views/4){rel="&#x22;nofollow&#x22;"}


# Run Node-RED as a service on Windows

FlowFuse's device agent allows you to manage and run your Node-RED instances on
your own hardware such as a Raspberry Pi or Windows computer. This can be very useful where an
application you've written needs to run flows with direct access to hardware sensors.

In this article, we're going to explain the steps to configure our device agent to run as a service in Windows
using the [nssm](https://nssm.cc/){rel="&#x22;nofollow&#x22;"} utility.

## Why run the device agent as a service?

The standard process for running FlowFuse's device agent is to start it on the
command line using the command `flowfuse-device-agent`. This works fine for testing
but for long-term installations it's useful to run the device agent as a service.
Once running as a service, the device agent will continue to run even if you
log off or the computer is restarted and no user is logged in.

## Summary

The aim of this how-to is to install the FlowFuse device-agent as a service on a Windows computer.

There will be two main parts to this:

1. Install the device-agent
2. Setup the device-agent to run as a Windows service

Additionally, two user accounts will be needed for this configuration:

1. A **user** account that will be used to run the device-agent (typically, non-admin account)
2. An **admin** account that can run elevated commands and will be used to setup the service

We will create a directory for the device-agent files and set the permissions on that directory so that the **user** account can read and write files in that directory.
&#x2A;This will be `c:\opt\flowfuse-device`*

To make the device-agent run as a service, we will (in this example), use [nssm](https://nssm.cc/){rel="&#x22;nofollow&#x22;"} but you are free to choose an alternative tool to run the device agent as a service.

Finally, we set the service to run under the **service** account.

*NOTE: The instructions in this how to were written on **Windows 11 Pro 22H2***

### TIP: Using domain accounts

If the account is a domain account, append the domain name to the **user** e.g. `user@domain` whenever the **user** name is used in the instructions below.

### TIP: Launching an elevated command prompt window (e.g. as the admin user)

```bash
powershell -Command "Start-Process 'cmd' -Verb runAs
```

:cta-image{alt="Power Workplace relies on FlowFuse for scalability, reliability and security audits - book a demo" cta="demo" src="https://flowfuse.com/images/cta/power-workplace-book-demo.png"}

### TIP: Launching an elevated powershell prompt window (e.g. as the admin user)

```bash
powershell -Command "Start-Process 'powershell' -Verb runAs
```

## Pre-requisites

### Install Node.js

The device-agent requires Node.js to be installed. You can download the latest version from <https://nodejs.org/en/download/>{rel="&#x22;nofollow&#x22;"}.

It is recommended to install the LTS version and to check the "Automatically install the necessary tools" option. This is especially important if you intend on using any nodes that require native modules (like serialport).

### Create a New Windows User

If you need to create a new **user** account follow these [instructions](https://support.microsoft.com/en-us/windows/create-a-local-user-or-administrator-account-in-windows-20de74e0-ac7f-3502-a866-32915af2a34d#:~\:text=Select%20Start%20%3E%20Settings%20%3E%20Accounts%20and,other%20user%2C%20select%20Add%20account.){rel="&#x22;nofollow&#x22;"}.

## Prepare the device-agent files directory

As the admin user, open an [elevated](https://flowfuse.com/#tip-launching-an-elevated-command-prompt-window-eg-as-the-admin-user) command prompt, create the files directory and setup access permissions.

```bash
# In an elevated command prompt
mkdir c:\opt
mkdir c:\opt\flowfuse-device
# grant full access to the service account that will run the device-agent
icacls c:\opt\flowfuse-device /grant "user":F /T
```

*where `"user"` is the service account (not the admin account)*

## Install nssm

`nssm` can simply be downloaded and executed from any path.
We will download it to the `c:\opt` directory, extract the files and copy the 64 bit version to the current directory.

### `cmd` version [elevated](https://flowfuse.com/#tip-launching-an-elevated-command-prompt-window-eg-as-the-admin-user) command prompt

```bash
# starting in the device-agent files directory
cd c:\opt
# download the nssm zip file
curl -LJO https://nssm.cc/release/nssm-2.24.zip
# extract the files
tar -xf nssm-2.24.zip
# copy the 64 bit version to the current directory
copy nssm-2.24\win64\nssm.exe .
# clean up
del nssm-2.24.zip
rmdir /s /q nssm-2.24
```

### `powershell` version [elevated](https://flowfuse.com/#tip-launching-an-elevated-powershell-prompt-window-eg-as-the-admin-user) powershell prompt

If you don't have `cURL` installed, then powershell can be used to download the file. Here is how to do it:

```powershell
# starting in the device-agent files directory
cd c:\opt
# download the nssm zip file
Invoke-WebRequest -Uri https://nssm.cc/release/nssm-2.24.zip -OutFile nssm-2.24.zip
# extract the files
Expand-Archive -Path nssm-2.24.zip .
# copy the 64 bit version to the current directory
Copy-Item -Path .\nssm-2.24\win64\nssm.exe -Destination .
# clean up
Remove-Item -Path nssm-2.24.zip
Remove-Item -Path nssm-2.24 -Recurse
```

### Manual download

If you prefer, you can download the nssm zip file manually from <https://nssm.cc/release/nssm-2.24.zip>{rel="&#x22;nofollow&#x22;"} and extract the files to the `c:\opt` directory. Then copy the 64 bit version to the current directory.

Ultimately, you should end up with a file named `nssm.exe` in the `c:\opt\` directory.

## Install and configure the device-agent

As the **service** account, to do so open a command prompt window and run the following and authenticate:

```bash
runas /user:{serviceuser} cmd
# e.g. runas /user:winserv cmd
```

*where `{serviceuser}` is the service account (not the admin account)*

### Check the users npm global path is set in the Users Environment Variables

NOTE: The recommended flowfuse-device-agent instructions will result in the flowfuse-device-agent being installed in the NPM global directory. And the instructions to launch the device-agent expect the NPM global directory to be in your user path. This section will instruct you to a) find the NPM global path, then b) check the user’s path setting and, if necessary c) add the NPM global path to your user path.

First, make a note of the path currently set for npm global. You can do this by running the following command:

```bash
npm config get prefix
```

Next, ensure the `Path` Variable under the "User variables for *user*" contains the npm global path that we obtained in the previous step.
Use the below command, to check the user’s `Path` setting. If it is not present, edit the path to include it.

```bash
# This commands opens the environment variables editor, 
# look for the "Path" variable under "User variables for user",
# and ensure it contains the npm global path
rundll32 sysdm.cpl,EditEnvironmentVariables
```

If you did have to add the npm path to the users `Path` variable, you will need to **restart** the command prompt for the change to take effect and relogin as **user**.

### Install the device agent

Note: you may have already installed the device-agent, however, **we strongly recommend** you do this step again as the service account and ensure that account has the latest version.

```bash
npm i -g @flowfuse/device-agent
```

### Link the device-agent to your flowfuse team

First, we must run the device-agent and link it to our FlowFuse team. This will generate a "device configuration" details that we will use to configure the device-agent.
Below is how to run the device-agent with the UI enabled. This will allow you to configure the device-agent via its web UI.

```bash
flowfuse-device-agent --ui --ui-port 8080 --ui-user admin --ui-pass admin -d c:\opt\flowfuse-device -p 1880
```

The device-agent will now be running and you can access the UI at <http://127.0.0.1:8080>{rel="&#x22;nofollow&#x22;"} with the user and password both "admin" (you can change these in the command line if required).
*NOTE: These credentials are temporary and only valid during the device setup*

Proceed to configure the device-agent and link it to your flowfuse team. Full instructions can be found [here](https://flowfuse.com/docs/device-agent/register).
Once you have linked the device-agent to your team, you can stop it by pressing `ctrl+c` in the command prompt window.

## Create the device-agent service

As the admin user, open an elevated command prompt see [TIP](https://flowfuse.com/#tip-launching-an-elevated-command-prompt-window-eg-as-the-admin-user) above

### Install device-agent as a service

```bash
cd c:\opt
.\nssm.exe install flowfuse-device-agent "flowfuse-device-agent.cmd"
.\nssm.exe set flowfuse-device-agent AppDirectory "c:\opt\flowfuse-device"
.\nssm.exe set flowfuse-device-agent Description "FlowFuse Device Agent"
# set the AppParameters (cli options) to tell the agent where its home directory is
# in our case, this is c:\opt\flowfuse-device and is set with the -d option
.\nssm.exe set flowfuse-device-agent AppParameters "-d c:\opt\flowfuse-device -p 1880"
```

### Check the service is installed

Run the following command to check the service is installed:

```bash
services.msc
```

(look for a service named \`flowfuse-device-agent').

Alternatively, you can use the `sc` command:

```bash
sc query flowfuse-device-agent
```

### Set the user account that will run the service

Some things are easier to edit in the UI, so we will edit the service via the NSSM UI.

```bash
nssm edit flowfuse-device-agent
```

![nssm editor](https://flowfuse.com/blog/2023/12/images/nssm_service_editor.png)

In the UI, you can edit the service name, description, startup type, etc.
The most important thing to check is the `Application` tab. This includes the path to the flowfuse-device-agent.cmd and its arguments.
Select the "Log on" tab, select "This account" and enter the service account name and password that will run the device-agent.
Click the "Edit Service" button to save the changes.

Now you have a service that will run the device-agent as the **service** account 🎉

### Controlling the service

You can start the service with the command:

```bash
sc start flowfuse-device-agent
```

You can check the current status with the command:

```bash
sc query flowfuse-device-agent
```

You can stop the service with the command:

```bash
sc stop flowfuse-device-agent
```

### Further reading

If you'd like to learn about windows services via the `sc` command you can access
the help text by running `sc` from a command prompt.


# Thank you for an incredible 2023!

At the end of the year there’s always an opportunity to review how the year went, and I'm gonna take this opportunity to share the review of 2023 for FlowFuse. It's been an incredible year for FlowFuse and we've achieved a lot with our team.

### FlowFuse branding

First off; in 2023 we were known as FlowForge. But, due to some trademark challenges, we went through a [rebranding phase](https://flowfuse.com/blog/2023/08/flowforge-is-now-flowfuse/) over the summer. It's been a bit of an adjustment, and you might still catch us – and even some of our customers – occasionally slipping up with the old name. But overall, we're really pleased with how smoothly everything's transitioned.

### Product adoption

On the product side: Growth in adoption of the FlowFuse platform has been tremendous, in many dimensions; revenue generated, customers onboarded, and how many users are now professionalizing their usage of Node-RED. Our development platform has been used by thousands of developers to acquire data from various sources and visualize it to build rich applications for their use cases. And at every step of the way we’ve been able to improve their experience.

Data acquisition was always possible without FlowFuse, however we’ve improved on the status quo through the [Certified Nodes](https://flowfuse.com/integrations/?certified=1) program. A nascent program that vets often used custom nodes from the community to ensure business readiness and validate nodes to ensure there’s no malicious code installed.

Further, this year we’ve started [Dashboard 2.0](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"}. The development of the successor of [node-red-dashboard](https://flows.nodered.org/node/node-red-dashboard){rel="&#x22;nofollow&#x22;"}, which is built on deprecated technology and effectively on life-support. The development of the new Dashboard technology has taken massive steps and it’s very stable. Feature parity is not yet achieved, though we’re happy with the adoption of Dashboard 2.0 and the community [reporting issues and improvements](https://github.com/FlowFuse/node-red-dashboard/issues){rel="&#x22;nofollow&#x22;"}.

With the product improvements to FlowFuse, we’ve empowered large audiences to try and adopt the product. We’ve seen adoption in many areas:

1. Process manufacturing – Mining, oil & gas, beverages.
2. Discrete manufacturing – Ranging from automotive to logistics use-cases.
3. Digital transformation – Digital only integration, from website back-ends to workflow engines for up-skilled employees.
4. Agriculture – From environment monitoring to controlling sprinklers, water-pumps, and more.
5. Education & Research – Hundreds of students have registered for FlowFuse to learn how IIoT works, start building solutions, and prepare themselves for employing these skills in their first jobs.

We’re always happy to [support you](https://flowfuse.com/contact-us/) in any of these or other industries where you may find value in how we streamline operations, manage your data acquisition logic and roll out, and remain compliant during your journey.

### Pricing changes

A driving force behind the horizontal nature of adoption of the FlowFuse development platform has been the introduction of product tiers earlier this year. We’ve introduced Team and Enterprise tiers.

A user can be promoted to the [Team or Enterprise tier](https://flowfuse.com/changelog/2023/09/introduction-enterprise-tier/) when they’re ready to further professionalize their adoption and have access to enhanced compliance, faster time to value for their developers, among other features.

### What 2024 will bring

FlowFuse will continue to support the Node-RED community at large. In 2024 we’re looking to further grow into the main development platform for low-code developers. While our main focus will remain around Node-RED, there’s more to be done to become the defacto low-code development platform. Core of which are a few pillars:

1. Time to value for developers
2. Empowering more employees to automate the software layer of the solution
3. Enhanced compliance and enforcement

We’re hoping to continue to serve our customers and grow the customer base in 2024!

### Holiday Season Support

Over the next couple of weeks (22nd December - 2nd January), most of our team will be taking some well deserved time off. Don't worry, we will still be available if you need emergency support. The best way to contact us is via our website's [support page](https://flowfuse.com/support/).


# Introduction to the Unified Namespace (UNS) – 2026 Updated Guide

As your organization is generating more data there’s key architectural
decisions to be made to ensure the full value can be unlocked and you’re
leveraging not just the tip of the iceberg. The [Unified Namespace (UNS)](https://flowfuse.com/use-cases/uns/)
provides a blueprint to allow data to be consumed by many data-consumers.
FlowFuse helps you manage this migration and the operationalization of your
data.

To facilitate a many to many connection between data producers and data consumers, there are two changes to be made to your architecture:

1. Data transport through a hub-and-spokes model
2. Set structure of the Data

## Hub and spokes model replaces Point to Point

Traditionally, for example web servers serving web pages, the client requests a
page from a server. This is a point to point connection between those two parties.

![Point to point graphic](https://flowfuse.com/blog/2023/12/images/uns-point-to-point.png "Point to Point connection")

For the same data to be transmitted to a new data consumer, the consumer needs
to make another request to obtain the data. This works great when you know what
data you need for building your solution, and if you know where to get it.

However, in manufacturing it’s not always possible to know up front who will
need your data. Some machines are built and placed years before another machine
would like to interact with the generated data. There might be many consumers
for the same data set. Lastly; consumers might not know when to fetch new data
points, and thus will try on a cycle or need another mechanism to understand if
new data is available. Also, there are many challenges in point-to-point connections.
For a deeper explanation, read [Why point-to-point connection is dead](https://flowfuse.com/blog/2024/11/why-point-to-point-connection-is-dead/).

This is why a hub and spoke model should be employed. For each data source or
data producer, a connection is made to a central hub; generally called a broker.

![Hub and spoke graphic](https://flowfuse.com/blog/2023/12/images/uns-hub.png "Unified Namespace Hub and Spokes communication")

## Structured data

When many producers are connected to many data consumers, but not directly,
the data producer needs to provide insight into what the events can be and will
contain. It cannot, nor should even if it could, tailor the event’s data structure
for a consumer so there’s decoupling on an architecture level. Structured data
makes information, without structure the consumer receives mere bytes.

This means that a schema for each event should be created and maintained. A
schema which both the producer and consumer can read and validate each event
against. As such a common Schema Definition Language (SDL) is chosen to provide
clarity of how the data is structured, how it can be parsed, and in some cases
also what it means for the developer.

## How Node-RED Fits In

Node-RED excels in implementing a Unified Namespace with its flexible and powerful capabilities. It can act as both a central hub and a data consumer within a hub-and-spokes model, simplifying the integration of various data sources and consumers. By leveraging Node-RED's extensive library of nodes and its easy-to-use flow-based programming interface, organizations can efficiently manage data ingestion, transformation, and distribution.

Node-RED also supports structured data through its support for JSON, XML, and other standard formats, allowing for clear and consistent data schemas. With its built-in nodes for MQTT, HTTP, and other protocols, Node-RED can seamlessly integrate with existing systems, enabling real-time data exchange and visualization. This makes it an ideal tool for operationalizing the Unified Namespace, ensuring that data flows efficiently and is readily available to all relevant stakeholders.

Read this article to learn how you can build your Unified Namespace using Node-RED and FlowFuse: [Building a Unified Namespace with FlowFuse](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/)

You can also watch this webinar that explores the core concepts of the Unified Namespace, explains why it is essential for Industry 4.0, and demonstrates how FlowFuse and HiveMQ can be used together to build a scalable Unified Namespace.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: z62O5RrOK8o
---
::

### How FlowFuse Can Help

While Node-RED is highly effective for implementing UNS, managing and deploying it can be complex. FlowFuse provides a unified platform that simplifies deployment with one-click operations, secure management, and scalable Node-RED applications. It also includes features that enhance collaboration, alongside offering centralized management of all Node-RED instances to ensure streamlined operations and increased efficiency.

**[Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now for a free trial and experience FlowFuse's features**


# Data Modeling for your Unified Namespace

In the realm of industrial manufacturing, the concept of a Unified Namespace (UNS) emerges as a pivotal instrument for enhanced communication within a manufacturing network framework. Predicated on an event-driven architectural model, this approach advocates for the universal accessibility of data, irrespective of the immediate presence of a data consumer.

This paradigm allows for a flexible role allocation within the network, where nodes can dynamically switch between being data producers and consumers, contingent upon the fluctuating requirements of the system at any specific juncture. For those unfamiliar with UNS, I recommend revisiting my [previous article](https://flowfuse.com/blog/2023/08/isa-95-automation-pyramid-to-unified-namespace/) on the subject.

This article aims to explain the process of data modeling for your UNS, highlighting the role of tools like the FlowFuse Team Library in schema management.

**Overview of Steps:**

1. [Connection to your Operational Technology (OT) equipment](https://flowfuse.com/#step-1-connection-to-your-operational-technology-ot-equipment)
2. [Structuring your payload](https://flowfuse.com/#step-2-structuring-your-payload)
3. [Building your Topic Hierarchy](https://flowfuse.com/#step-3-building-your-topic-hierarchy)
4. [Connection to your Unified Namespace](https://flowfuse.com/#step-4-connection-to-your-unified-namespace)

## Step 1 - Connection to your Operational Technology (OT) equipment

The journey begins with establishing connections to OT equipment, which may include Programmable Logic Controllers (PLCs), Historian databases, and sensors. It is essential to facilitate compatibility with a diverse array of protocols. In this context, Node-RED emerges as a pivotal tool, bolstered by its expansive community-generated catalog featuring over 4500 nodes.

In my example, the focus is on integration with a RevolutionPi. To achieve this, the FlowFuse Device Agent was deployed on a RevolutionPi (see our [documentation](https://flowfuse.com/docs/hardware/raspbian/)), and specific RevolutionPi nodes were installed. These nodes enable direct interaction with all interfaces of the PLC and are available through the [Node-RED library](https://flows.nodered.org/node/node-red-contrib-revpi-nodes){rel="&#x22;nofollow&#x22;"}. Subsequent steps involved acquiring temperature data directly from the PLC.

![](https://flowfuse.com/blog/2023/12/images/revpi_nodes.png)

For optimal data accuracy and integrity, it is recommended to timestamp data at the point of origin. In our scenario, the PLC outputs lack inherent timestamping. Consequently, I integrated a timestamp at the data acquisition stage within Node-RED, which runs on the same hardware.

A general recommendation is the imperative of maintaining data integrity during transmission from OT systems to the message broker. This is particularly salient in regulated sectors such as pharmaceuticals, where standards like GxP mandate the preservation of unaltered data during transfer to the UNS.

## Step 2 - Structuring your payload

The payload is the core of transmitted data. Transforming the payload for mutual intelligibility between sender and receiver, even within the same protocol, is sometimes necessary. Standardizing payload formats ensures consistent data storage and transmission. I recommend including schema type information with the data to cater to diverse use cases.

Utilizing FlowFuse and Node-RED can enforce schema consistency. Node-RED's template node lets you define JSON schemas for your flows, while the FlowFuse Team Library facilitates schema sharing and consistency across your organization.

In my example, I use a very simple JSON schema as a structure for measurements for `StationA`:

```json
{
    "$schema": "Enterprise/Site/Line1/StationA/measurements/_schema",
    "title": "Measurement Schema for StationA",
    "type": "object",
    "properties": {
        "value": {
            "description": "The actual value being measured",
            "type": "number"
        },
        "unit": {
            "description": "The unit of the measurement value",
            "type": "string"
        },
        "timestamp": {
            "description": "The timestamp of the measurement in ISO 8601 format",
            "type": "string"
        }
    },
    "required": [
        "value",
        "unit",
        "timestamp"
    ]
}
```

Example Data:

```json
{
    "value": msg.payload,
    "unit": "Celsius",
    "timestamp": msg.timestamp
}
```

![Node-RED template node](https://flowfuse.com/blog/2023/12/images/template_node.png)

The FlowFuse Team Library acts as my schema registry within my organization, allowing me to reuse my schemas and ensure consistency.

![FlowFuse Team Library](https://flowfuse.com/blog/2023/12/images/team_library.png)

## Step 3 - Building your Topic Hierarchy

Your topic hierarchy should reflect your physical plant structure or align with existing asset naming systems. This approach improves data visibility and eases navigation for OT engineers. Many enterprises opt for the [ISA-95 part 2](https://www.isa.org/products/ansi-isa-95-00-02-2018-enterprise-control-system-i){rel="&#x22;nofollow&#x22;"} model to structure their topics.

In our example, we follow the structure of: Enterprise/Site/Line1/StationA

![MQTT Topic Tree](https://flowfuse.com/blog/2023/12/images/mqtt_topic_tree.png)

## Step 4 - Connection to your Unified Namespace

Finally, transfer your data to the UNS, using protocols like MQTT or Kafka, depending on your UNS setup. While MQTT can handle up to 256 MB per payload, Kafka's default is 1MB, expandable to 10MB. These capacities suffice for most data types. In our example, we'll employ MQTT.

## Conclusion

In conclusion, implementing a Unified Namespace (UNS) with efficient data modeling is a transformative step for any industrial manufacturing setup. By leveraging tools like FlowFuse Team Library, Node-RED, and protocols such as MQTT or Kafka, organizations can achieve a harmonious data ecosystem where information flows seamlessly across various nodes. As illustrated through practical examples, including the integration with a RevolutionPi, the importance of standardizing data schemas, maintaining data integrity, and structuring topic hierarchies cannot be overstated. Embracing these practices not only enhances operational efficiency but also paves the way for more advanced analytics and machine learning applications.

### The complete Node-RED flow

:iframe{allow="clipboard-read; clipboard-write" height="225px" src="https://flows.nodered.org/flow/f6c783c6e9c1863145e0c63418eb5fe5/share?height=100" style="border: none;" width="100%"}


# Capture Data from edge devices with Node-RED

While cloud computing has revolutionized data access and analysis, not all data can be accessed from the cloud. In many scenarios, data collection from the edge – the location where data is generated – is essential for real-time decision-making or process observability.

FlowFuse enables data to be collected through Node-RED. Data can be processed locally on the edge or sent on to other services. FlowFuse doesn’t rely on continuous connections to the cloud, making it a good choice for locations with unreliable internet connectivity. Use cases like real-time monitoring of critical systems, proactive maintenance, and improved operational efficiency are now possible to implement.

## Installing the FlowFuse agent

To manage the capturing of data on the edge we’re going to first install the FlowFuse agent. It’s installed on your device to manage the communication between the edge device and the FlowFuse server, manage the installation of Node-RED, its execution environment, and facilitate communication between devices and the cloud.

The device agent can run anywhere you can run a Docker container or Node.JS runtime (version 16.0+) can be installed.

### Registering a device on FlowFuse

For the edge device to know what it’s supposed to do, it needs to listen to the FlowFuse commands. The agent's configuration is provided by a `device.yml` file from FlowFuse. Go to the team you’d like to add an edge device to, and select “Devices” on the left-hand menu, followed by the “Add Device” button.

![Setting up a FlowFuse agent](https://flowfuse.com/blog/2024/01/images/flowfuse-agent-setup.png "Setting up a FlowFuse agent")

FlowFuse will prompt you to add a name (required), and a type (not required). When you’ve clicked `Add` you’ll get a new dialog to download the required file.

![Configuration file for the FlowFuse agent](https://flowfuse.com/blog/2024/01/images/device-yml-flowfuse.png "The contents of a device.yml file")

### Install the FlowFuse agent through Docker

If your device supports it, the fastest way to run the FlowFuse agent is with containers. Assuming you’ve already got Docker installed, there are two steps to follow: first, move the device YAML file downloaded from FlowFuse to the edge device and save it in `/opt/flowfuse/device.yml`. Start the agent by running:

```text
docker run --mount type=bind,src=/path/to/device.yml,target=/opt/flowfuse-device/device.yml -p 1880:1880 flowfuse/device-agent:latest
```

Note that for production cases, ensure the container is restarted on reboot. Docker can do this for you, [please follow their guide](https://docs.docker.com/config/containers/start-containers-automatically/){rel="&#x22;nofollow&#x22;"}.

### Install the FlowFuse agent with npm

To install the agent through NPM, you’ll need a Node.JS version of 18.0 or later. Open a command prompt and run: `npm install -g @flowfuse/device-agent`.

This will install the FlowFuse Device Agent as a global npm module, making the flowfuse-device-agent command available in any directory on your system.

Once the installation is complete, you must configure the Device Agent to connect to your FlowFuse instance. In this guide, you’ve previously downloaded the `device.yml` file that’s needed now. On Linux or Mac, move the file to `/opt/flowfuse-device/device.yml`, and for Windows-based systems, move the file to `c:\opt\flowfuse-device\device.yml`.

Afterward, start the agent with: `flowfuse-device-agent`.

This will launch the Device Agent and connect it to your FlowFuse instance. The Device Agent will wait for instructions on which flows to run.

### Programming flows for the edge

Now the agent is running, the FlowFuse platform will show it has contacted back to the platform and is ready to do some work. First, add it to the application and start the developer mode. That enables the device editor and provides you secure access to the editor anywhere in the world for everyone in the FlowFuse team with the right access role.

When the development is done, be sure to create a snapshot of the developed flows to create a point-in-time backup, or to roll the snapshot out to many other devices later.


# Node-RED Dashboard 2.0 is Generally Available!

Back in [June 2023](https://flowfuse.com/blog/2023/06/dashboard-announcement/) we announced that FlowFuse would be investing into building out the next generation of Node-RED Dashboard, the most popular UI framework for Node-RED.
We followed this up with the [first release](https://flowfuse.com/blog/2023/07/dashboard-0-1-release/) (`0.0.1`) in July, just one month later, and today, we are pleased to announce that we have reached a major milestone in this journey, with the release of our first major version (`1.0.0`) of Node-RED Dashboard 2.0.

![Dashboard 2.0 Example showing weather data](https://flowfuse.com/blog/2024/01/images/dashboard-ga-example.png)

With our `1.0.0` release, you can now build your dashboards on a reliable and stable package, and we invite you to to start contributing your own third-party [widgets](https://dashboard.flowfuse.com/contributing/widgets/third-party.html){rel="&#x22;nofollow&#x22;"} and [plugins](https://dashboard.flowfuse.com/contributing/plugins/){rel="&#x22;nofollow&#x22;"}. We're excited to see what the community can contribute and build on top of this new Dashboard 2.0 framework, and we'll be continuing development to the core collection of widgets too.

With Node-RED Dashboard 2.0, we have re-built the original Node-RED Dashboard from the ground up. It is now extensible due to it being VueJS-based, completely responsive down to mobile, and we've made many quality of life improvements across the board to the existing widget collection, as well as adding a few new ones too.

## What's new in Dashboard 2.0?

We've shared plenty of updates since we started, detailing the feature parity with the original Node-RED Dashboard, as well as some of the new widgets and features we've added to the new Dashboard, such as Markdown, Mermaid Charts and new Layout Options, you can read more about those here:

- [Dynamic Markdown, Tables & Notebooks](https://flowfuse.com/blog/2023/09/dashboard-notebook-layout/)
- [UI Chart Improvements](https://flowfuse.com/blog/2023/11/dashboard-0-7/)
- [Building a Custom Video Player](https://flowfuse.com/blog/2023/12/dashboard-0-10-0/)

Furthermore, the most requested feature for the legacy dashboard has been implemented in Dashboard 2.0, the ability to hide charts and forms based on the user that's viewing the dashboard.

![Dashboard 2.0 Example showing personalised dashboard](https://flowfuse.com/blog/2024/01/images/multi-user-dashboard-user2.png)

Read more about it here:

- [Personalised Multi User Dashboards](https://flowfuse.com/blog/2024/01/dashboard-2-multi-user/)

If that wasn't enough, we also have [rich documentation](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"} for Dashboard 2.0 too, detailing all of the available nodes, details on how Dashboard 2.0 is built and how to contribute to the project too if you're that way inclined.

## Upcoming Webinar

If you're interested in learning more about Dashboard 2.0 and in particular, personalised multi-user dashboards, we're hosting a webinar on Thursday, 29th February. You can find out more information [here](https://flowfuse.com/webinars/2024/node-red-dashboard-multi-user/)

## Follow our Progress

We aren't stopping here, we'll continnue to push Dashboard 2.0 forward with future development, with a [new UI Gauge](https://github.com/FlowFuse/node-red-dashboard/issues/12){rel="&#x22;nofollow&#x22;"} next on the list. You can track that progress of that particular issue, and the rest of the work we have lined up on our GitHub Projects:

- [Dashboard 2.0 Activity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}
- [Dashboard 2.0 Planning Board](https://github.com/orgs/FlowFuse/projects/15/views/4){rel="&#x22;nofollow&#x22;"}
- [Dashboard 1.0 Feature Parity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/5){rel="&#x22;nofollow&#x22;"}

If you have any feature requests, bugs/complaints or general feedback, please do reach out, and raise issues on our relevant [GitHub repository](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.


# Personalised Multi-user Dashboards with Node-RED Dashboard 2.0!

This week has seen the release of the [first major version of Node-RED Dashboard 2.0](https://flowfuse.com/blog/2024/01/dashboard-2-ga), with it, we've made available a new FlowFuse-exclusive feature, personalised multi-user dashboards.

This new feature will allow you to build applications that provide unique data to each user, build admin-only views, and track user activity, to name but a few. We're really excited to see what the Node-RED Community and our FlowFuse customers can do with such a powerful and flexible framework.

## Personalised Multi User Dashboards

The original Node-RED Dashboard was built with a "single source of truth", no matter how many users interacted with the dashboard, each user would always see the same data. This is great for prototyping, or hobby projects, but as you scale up your Node-RED usage, you'll want to be able to have unique dashboard experiences for each user.

### Getting Started

To enable personalised multi-user dashboards, you'll need to be using FlowFuse, and complete two steps:

#### Step 1: Enable "FlowFuse User Authentication"

All instances on FlowFuse can be configured with &#x2A;"FlowFuse User Authentication"* in the "Security" Settings. This option requires any user that wants access to your Editor or dashboard to be authorized by FlowFuse first.

!["Screenshot of the 'Security' settings available for any Instances running in FlowFuse"](https://flowfuse.com/blog/2024/01/images/multi-user-dashboard-ffauth.png "Screenshot of the 'Security' settings available for any Instances running in FlowFuse"){dataZoomable=""}

**"Screenshot of the 'Security' settings available for any Instances running in FlowFuse"**

#### Step 2: Install FlowFuse's User Addon

##### FlowFuse Cloud

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

*Note: Every instance created from today onwards automatically comes with the necessary configuration. Already created instances need to be manually restarted.*

The Personalised Multi-User Dashboard plugin, `@flowfuse/node-red-dashboard-2-user-addon`, is available in our [Certified Nodes](https://flowfuse.com/integrations/?certified=1) catalogue, accessible to our Teams and Enterprise customers.

Once the "FlowFuse User Authentication" option has been enabled on your instance, you can then install our plugin, `@flowfuse/node-red-dashboard-2-user-addon`, through the "Manage Palette" option in the Node-RED Editor.

For your devices, we provide the necessary configuration and access token upon request, so that your Node-RED devices can also benefit from a Personalised Multi-user Dashboard.

##### FlowFuse Self-Hosted

For all our Teams and Enterprise Self-Hosted customers who also want to use the Certified Nodes and the Multi-User Dashboard, we provide all necessary configurations upon request to get started.

Alternatively, if you're looking to elevate your Node-RED infrastructure, [book in a chat with us](https://flowfuse.com/contact-us) to talk about how FlowFuse can help.

### Using the Plugin

Once enabled, any messages emitted by a Dashboard 2.0 node will contain a new `msg._client.user` object, e.g:

```js
{
    "userId": "",   // unique identifier for the user
    "username": "", // FlowFuse Username
    "email": "",    // E-Mail Address connected to their FlowFuse account
    "name": "",     // Full Name
    "image": ""     // User Avatar from FlowFuse
}
```

Then, when running Node-RED Dashboard 2.0 on FlowFuse, you'll have a new sidebar option in the Node-RED Editor, which allows you to control which node types allow for "client constraints".

![The new 'FF Auth' options available in Node-RED to allow for client constraints](https://flowfuse.com/blog/2024/01/images/multi-user-dashboard-ff-settings.png "The new 'FF Auth' options available in Node-RED to allow for client constraints"){dataZoomable=""}

**A screenshot of the new 'FF Auth' options available in Node-RED to allow for client constraints on different node types.**

In the original Node-RED Dashboard, this was *always* enabled for the `ui-notification` and `ui-control` nodes, whereby you could include `msg.socket` data and it would only then send that message to the specified client. For Dashboard 2.0 we've extended this concept so that as a Node-RED Developer, you can now include `msg._client.user` data in any message sent to a Dashboard 2.0 node. Under the covers, our FlowFuse-exclusive plugin will then automatically filter messages to only send to the relevant user's connection.

Utilising this feature, below you can see an example where we send data to a `ui-template` to render a custom table for each user. Under the covers this is a `ui-event` node (triggered on a page view), which then uses the `msg._client.user` object to make a REST API call to retrieve a list of todo items for that specific user. We then wire the response into the `ui-template`, which has been configured to "Accept Client Constraints", and so only sends this data to User 2's dashboard.

![Showing Admin Task View](https://flowfuse.com/blog/2024/01/images/multi-user-dashboard-admin-tasks.png "Showing Admin Task View"){dataZoomable=""}

**Example of a dashboard that displays user-specific content.**

Note too that we're also utilising the new [Teleport](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html#teleports){rel="&#x22;nofollow&#x22;"} option available in a `ui-template&#x60; which allows us to define content to show in the top-right of the dashboard, in this case, a little &#x2A;"Hi {username}"* message.

### Examples

#### Rendering Logged In User Data

In the previous example, you may have noticed that we're also displaying a welcome to the authenticated user on our dashboard, this means that we have access to the full User object within any `ui-template` that we render too.

![Showing User Unique Data](https://flowfuse.com/blog/2024/01/images/multi-user-dashboard-user2.png "Showing User Unique Data"){dataZoomable=""}

**The "Admin" view that is only made available to users registered as an "admin".**

Under the covers, we're appending our `user` object to the `msg` object, via the SocketIO `auth` option. We make the `socketio` object available via a computed `setup` variable, this means that we can access this data in any `ui-template` node, and render like so:

```html
<template>
    <div>
        <h1>Hi, {{ setup?.socketio?.auth?.user?.name }}!</h1>
    </div>
</template>
```

To enable custom user-by-user content in a `ui-template` though, we must allow it to "Accept Client Constraints". This means that if a `.msg._client.user` value is included in any messages sent to a `ui-template` node, then the underlying SocketIO message will be filtered to only send to the relevant user's connection, and no others.

#### Admin Only Views

With this new functionality we can also now show/hide content based on the authenticated user.

We recently introduced the option to [set default visiblity & interaction states](https://github.com/FlowFuse/node-red-dashboard/pull/484){rel="&#x22;nofollow&#x22;"}. This was partly introduced because it's a good practice to set the default "Visibility" option for any admin-only pages to "Hidden", and then use a `ui-control` node to show the content only to the relevant admins.

:iframe{allow="clipboard-read; clipboard-write" height="100%" src="https://flows.nodered.org/flow/2fe8e6f1e7002f1ff6a9195ad1a153b6/share" style="border: none; margin-bottom: 12px;" width="100%"}

Let's breakdown the above flow:

1. We wire a `ui-event` node (which emits each time a user views a page) into a switch node
2. Our switch node checks the `user.username` against a known list of admin users and branches "admin:" and "non-admin" users
3. For admin users, the `change` node defines a message for our `ui-control` node to dynamically show content, in this case an "Admin" page, when appropriate.

```json
{
    "pages":{
        "show": ["Admin View"]
    }
}
```

All events going into `ui-control` are automatically filtered based on the `msg._client.user` object, so only the Admin users will receive the message to show the "Admin View" page, resulting in:

![Showing Admin Only View](https://flowfuse.com/blog/2024/01/images/multi-user-dashboard-admin.png "Showing Admin Only View"){dataZoomable=""}

**The "Admin" view that is only made available to users registered as an "admin".**

Further extensions of this could also check `ui-event` in case a non-admin user tries to access the `/admin` page directly, in which case we can utilise `ui-control` to navigate the user away from the page immediately. See the [ui-control documentation](https://dashboard.flowfuse.com/nodes/widgets/ui-control.html#navigation){rel="&#x22;nofollow&#x22;"} for more details on this.

## Upcoming Webinar

If you're interested in learning more about Dashboard 2.0 and in particular multi-user Dashboards, we're hosting a webinar on Thursday, 29th February. You can find out more information [here](https://flowfuse.com/webinars/2024/node-red-dashboard-multi-user/)

## Follow our Progress

We aren't stopping here, we'll continue to push Dashboard 2.0 forward with future development, and you can track that progress on our GitHub Projects:

- [Dashboard 2.0 Activity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}
- [Dashboard 2.0 Planning Board](https://github.com/orgs/FlowFuse/projects/15/views/4){rel="&#x22;nofollow&#x22;"}
- [Dashboard 1.0 Feature Parity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/5){rel="&#x22;nofollow&#x22;"}

If you have any feature requests, bugs/complaints or general feedback, please do reach out, and raise issues on our relevant [GitHub repository](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.


# FlowFuse 2.0 Release

Following the release of FlowFuse 1.0 end of 2022, we're excited to release FlowFuse 2.0, marking a significant step in managing Node-RED remote instances, which we call Devices. FlowFuse already was the best place to operate Node-RED at scale in the cloud or on-premise, now it's able to manage Node-RED where ever it's run.

Many organizations position Node-RED instances on remote servers like edge or industrial devices. This way they can meet network requirement, interact with analog protocols, and overcome other infrastructure requirements. Management of remote instances is crucial for the overall success of closing the gap between IT and OT. A key enhancement was the introduction of Device Groups (from version 1.15) and the new feature to assign target snapshots. This allows for direct and streamlined management of Node-RED Device fleets, setting the stage for future advancements in device management capabilities.

For our FlowFuse users, this means it is no longer necessary or recommended to assign devices to an instance. Node-RED devices can be managed independently, and snapshots can be assigned via DevOps pipelines.

## Enterprise-Readiness

FlowFuse is committed to augmenting the enterprise-readiness of Node-RED with introductions like [Single Sign-On (SSO)](https://flowfuse.com/docs/admin/sso/), [Multi-Factor Authentication (MFA)](https://flowfuse.com/docs/user/user-settings/#two-factor-authentication), and [High Availability](https://flowfuse.com/docs/user/high-availability/) since version 1.0. Furthermore, we recently achieved [SOC2 Type 1 compliance](https://flowfuse.com/blog/2024/01/soc2/). With these advancements, Node-RED, in combination with FlowFuse, is genuinely ready for enterprise and production use.

## Enhanced Integration Capabilities

The Node-RED Flow Library has always been a cornerstone, offering over 4800 connectors (nodes) for various OT and IT protocols. Thanks to the community and the Node-RED library. Building on this foundation, FlowFuse introduced "Certified Nodes" and "Blueprints". These [Blueprints](https://flowfuse.com/blog/2023/10/blueprints/) are designed to provide an easier start with Node-RED, showcasing its full potential, while Certified Nodes ensure the security of the nodes used. Learn more about our new Certified Nodes [here](https://flowfuse.com/blog/2023/10/certified-nodes/).

## Developer Velocity

Node-RED team development is made possible with FlowFuse. Different development team members are able to share and collaborate on the same Node-RED instance. This makes for much easier collaboration between Node-RED developers. We've worked hard on maturing our [snapshot capabilties](https://flowfuse.com/docs/user/snapshots/) and introduced [DevOps Pipelines](https://flowfuse.com/docs/user/devops-pipelines/) that can be set up to stage Node-RED instances that have different development stages, e.g. test, development and production.

## Looking Ahead

At FlowFuse, our mission is to empower bottom-up innovation and enable organizations to transform their workflows into business-critical applications with unprecedented efficiency. As we move forward, we are excited to invite our users to actively engage with our future developments. Our [Roadmap](https://flowfuse.com/changelog/) lays out the advancements we're targeting, offering a glimpse into the features and enhancements that are on the horizon. We also encourage our users to stay informed and involved by checking out our latest updates in our detailed [changelog](https://flowfuse.com/changelog/). Your insights and feedback are crucial to us; they fuel our commitment to continuous improvement and innovation. We warmly invite you to [share your thoughts and suggestions](https://flowfuse.com/contact-us/), as your input is a vital part of our journey in shaping the next steps for FlowFuse.

## How to get started

You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running version 2.0.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

The version 2.0 release of the FlowFuse Helm Chart includes a breaking change for deployments making use of the `forge.localPostgresql` setting when upgrading. This is where the helm chart installs a dedicated PostgreSQL database instance.
With version 2.0 we have updated the version of the Bitnami PostgreSQL Helm sub-chart we bundle and the upgrade process will require some manual intervention to ensure things work correctly. A fresh install should not require any extra steps.

The steps are documented on the [Upgrade instructions](https://flowfuse.com/docs/install/kubernetes/#upgrade) page, please read them carefully before upgrading

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go to the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# Step-by-Step Guide to Deploying Node-RED with FlowFuse in balenaCloud

In a [recent webinar with balena](https://flowfuse.com/webinars/2024/balena/), we explored the dynamic capabilities of deploying FlowFuse to a fleet of devices using [balenaCloud](https://www.balena.io/cloud){rel="&#x22;nofollow&#x22;"}. This blog post serves as a practical guide to replicate that process, specifically tailored for those aiming to streamline their deployment of FlowFuse in an efficient and user-friendly manner.

## How to Implement FlowFuse with balenaCloud on a Fleet of devices

[![Deploying Node-RED with FlowFuse in balenaCloud](https://i.ytimg.com/vi/cKFu1ljUlKE/hqdefault.jpg)](https://www.youtube.com/watch?v=cKFu1ljUlKE "Deploying Node-RED with FlowFuse in balenaCloud"){rel="&#x22;nofollow&#x22;"}

### Preparation Steps

Before diving into the deployment process, it's crucial to familiarize yourself with key resources. We recommend reviewing our previous [blog post](https://flowfuse.com/blog/2023/11/device-agent-balena/) on deploying the FlowFuse Device Agent via balena. This post contains a vital link to the GitHub repository, essential for deploying FlowFuse with balena, laying the groundwork for the steps ahead.

### Creating a New Fleet in balenaCloud

1. Navigate to the [FlowFuse git](https://github.com/FlowFuse/balena-device-agent){rel="&#x22;nofollow&#x22;"} repository. Click on the **Deploy with balena** button.
2. Name your fleet.
3. Select your default device.
4. Click **Create and Deploy**.

### Adding Devices to the Fleet

Once your fleet is created, the next step is to add devices. To add a device to your fleet, follow these [instructions](https://docs.balena.io/learn/getting-started/var-som-mx6/rust/#add-a-device-and-download-os){rel="&#x22;nofollow&#x22;"}.

### Setting Up FlowFuse

Setting up FlowFuse correctly is essential for seamless operation:

1. Create a new instance within FlowFuse or use an existing one if you prefer. Follow these [instructions](https://flowfuse.com/docs/user/introduction/#creating-a-node-red-instance) to create a new instance.
2. Create a **Device Provisioning Token** by following these [instructions](https://flowfuse.com/docs/device-agent/register/#bulk-registration).
3. Ensure you add the FlowFuse Node-RED application you want the devices to provision. If left at default, devices will need to be manually added to applications.

### Using the Device Provisioning Token

1. First, convert the contents of the Device Provisioning Token to base64. Follow these [instructions](https://flowfuse.com/blog/2023/11/device-agent-balena/#environment-variable) to convert the file to base64.
2. Once converted, import this string into balena as a **Fleet** level variable, not a device level variable. Follow these [instructions](https://docs.balena.io/learn/manage/variables/#fleet-wide-variables){rel="&#x22;nofollow&#x22;"} to import the Fleet level variable with the Name `FF_DEVICE_YML`.
3. This action will provision any new device added to the fleet with the yaml file configuration, automatically adding the device to a FlowFuse instance.

### Deploying and Testing the FlowFuse Instance

Deploying the FlowFuse instance brings everything together:

1. Navigate to your FlowFuse application created earlier.
2. Go to your devices and you should now see your newly provisioned devices from balena.
3. If this is your first time setting up your fleet, the device will not have a snapshot. You will need to deploy a snapshot. Follow these [instructions](https://flowfuse.com/docs/user/snapshots/#create-a-snapshot) to do so. Ensure that you select **Set Target Snapshot**.
4. Once complete, the FlowFuse instance will deploy to your device(s).

## Integrating InfluxDB (Optional)

Integrating InfluxDB enables effective data storage and management:

1. Similar to the previous steps, navigate to this [Github repository](https://github.com/mpous/flowfuse-agent-influx-balena/tree/main?tab=readme-ov-file){rel="&#x22;nofollow&#x22;"} and click **Deploy with balena**.
2. This time, instead of creating a new fleet, select **Use an existing fleet instead**.
3. Choose your fleet for deployment and select **Deploy to fleet**.

### Data Generation and Management

For testing, we have created a flow to get you started. Follow this [link](https://flows.nodered.org/flow/66f37bb739b6cdb0c7ad3a4e2edd68ef){rel="&#x22;nofollow&#x22;"} and import it. There are four sets of flows for you to begin with. The first is for data generation. The second is a manual data generation flow. The third is key as it initiates the creation of a database, in this case, **mydb**. The last flow is a simple query that pulls data from InfluxDB.

1. Import the flows into your FlowFuse instance of Node-RED and deploy. Follow these [instructions](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-5/#_2-import-helpful-example-flows-provided-with-custom-nodes) for importing and exporting.
2. Return to Flowfuse, go to your instance, and create another [snapshot](https://flowfuse.com/docs/user/snapshots/#create-a-snapshot).
3. Ensure that you **Set Target Snapshot**.

### Finalizing and Testing the Setup

The final steps ensure that your setup is fully operational:

1. Once deployed, navigate to the device.
2. [Enable Developer Mode](https://flowfuse.com/docs/device-agent/deploy/#editing-the-node-red-flows-on-a-remote-instance-that-is-assigned-to-an-application).
3. Next, click the newly revealed button, **Open Editor**, to access the deployed Flow.

### Conclusion

Implementing FlowFuse with balenaCloud significantly enhances your device management and data processing capabilities. This guide provides a foundational approach, but don't hesitate to delve deeper into each step to tailor the setup to your specific needs.


# Import a File into Node-RED with Dashboard 2.0

Need to get a file into Node-RED, but don't want to over complicate things. This article outlines how you can leverage Dashboard 2.0 to import a file directly into Node-RED via a Dashboard.

## Why would you need to import a file to Node-RED?

Often times it is necessary to update lookup tables in a SQL database, but you don't necessarily want to give access to everyone to edit the database, nor do you want to have to do it all yourself. This can often be seen when new products are introduced into a manufacturing facility. It may not be often, but enough that it warrants its own application. This process will guide you in a way that will enable your teammates to upload the files to the system themselves.

Furthermore, on the management layer of most companies, Excel and Google Sheets are the go-to tools to perform data collection tasks. Getting management involved in processes might require you to build an import feature for them. Asking your manager to "Save as" CSV is much easier than teaching them SQL!

### Node-RED Dashboard (FlowFuse)

![csv dashboard](https://flowfuse.com/blog/2024/01/images/csv-dashboard.png)

This simple flow allows the user to visualize data from a CSV in the Node-RED Dashboard. The button then allows the user to initiate a request to send the data to the next step. This next step could be anything from loading into a SQL database to saving it.

### Instructions

1. Install Node-RED Dashboard 2.0. Follow these [instructions](https://flowfuse.com/blog/2024/03/dashboard-getting-started/) to install.
2. Import Flow - to import the flow into your Node-RED instance follow these [instructions](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-5/#_1-copy-and-share-your-flows-using-export-and-import).
3. Access Dashboard - To access the dashboard, navigate to the `https://<flowfuse-instance-name>.flowfuse.cloud/dashboard`.

This dashboard is currently configured to take in CSV files and transform them into a single message that is sent to the table for visualization. Simultaneously the data from the import is stored locally in the flow context. From there, the button can be used to trigger the sending of the data from the flow context to the next destination. In this case, it is a simple debug node.

:iframe{allow="clipboard-read; clipboard-write" height="225px" src="https://flows.nodered.org/flow/8c505039ac1b8dbed2bee1e22ee2975a/share?height=100" style="border: none;" width="100%"}

## Need to Send a File to Node-RED from another application or source?

Check out this [blog](https://flowfuse.com/blog/2024/01/send-a-file) on how to send a file from either a stand alone web application or use the sample python script to imbed it into your current application.


# AI and ChatGPT - Revolutionizing the Manufacturing Industry

The application of artificial intelligence (AI) in various industries, particularly in manufacturing, is a topic of growing interest. The evolution of technologies like ChatGPT is driving significant changes in this sector. For a more nuanced understanding, we reference four informative blog posts from our team members. The first post, ["AI Use Cases that are shaping the next manufacturing frontier"](https://flowfuse.com/blog/2023/12/ai-use-cases/), offers an insightful overview of AI's role in diverse areas. Following this, ["ChatGPT AI Assistants with Node-RED"](https://flowfuse.com/blog/2023/11/ai-assistant/) examines the specific impact of AI assistants. The third article, ["Node-RED Builder a ChatGPT GPT"](https://flowfuse.com/blog/2023/11/chatgpt-gpt/), discusses the capabilities of generative pre-trained transformers like ChatGPT. Lastly, ["How ChatGPT improves Node-RED Developer Experience"](https://flowfuse.com/blog/2023/09/chatgpt-for-node-red-developers/) explores ChatGPT's application in Node-RED development, an important aspect for many in manufacturing.

## How AI and ChatGPT are Impacting Manufacturing

AI and ChatGPT's integration into manufacturing indicates a shift in production process management. Here are some key impacts:

### Boosting Efficiency and Productivity

AI, especially ChatGPT, enhances manufacturing efficiency by analyzing data to improve production lines, predict maintenance, and aid in design and development.

### Automating Routine Tasks

AI is adept at handling repetitive tasks, speeding up manufacturing and allowing human workers to engage in more complex production aspects.

### Elevating Quality Control

AI algorithms consistently ensure high-quality standards, quickly identifying and fixing product defects or deviations.

### Enabling Customization and Flexibility

AI's learning and adaptability make it suitable for customizing production, allowing manufacturers to meet specific customer demands more efficiently.

### Transforming the Workforce

AI in manufacturing necessitates skilled workers to operate and maintain these systems, altering job roles and responsibilities.

## Pros and Cons of AI and ChatGPT in Manufacturing

### Pros

1. Boosted Productivity: AI-driven automation increases production efficiency.
2. Consistent Quality Assurance: AI ensures ongoing product quality.
3. Reduced Costs: AI optimizes resource use and minimizes waste.
4. Encouraging Innovation: AI facilitates new manufacturing methods and products.
5. Enhancing Safety: AI reduces human exposure to hazardous manufacturing conditions.

### Cons

1. Initial Investment Costs: AI technology implementation can be expensive.
2. Need for Skilled Labor: Demand for workers proficient in AI technologies is growing.
3. Job Role Changes: Automation might decrease the need for certain labor roles.
4. Security Concerns: AI systems can be susceptible to cyber threats.
5. Technological Dependence: Excessive reliance on AI could limit problem-solving abilities in workers.

## Frequently Asked Questions (FAQs)

1\. How is AI changing manufacturing?

:br&#x2A;*AI is altering manufacturing through automation, optimizing efficiency, and fostering production innovations.**

2\. What is ChatGPT's role in manufacturing?

:br&#x2A;*ChatGPT aids in data analysis, automates processes, and improves communication and documentation in manufacturing.**

3\. Are manufacturing jobs at risk due to AI?

:br&#x2A;*While AI may automate some repetitive jobs, it also creates opportunities for skilled labor in technology management and development.**

4\. Can AI enhance manufacturing product quality?

:br&#x2A;*Yes, AI's continuous monitoring and analysis significantly boost quality control.**

5\. What are the main challenges of integrating AI in manufacturing?

:br&#x2A;*Challenges include high implementation costs, the need for skilled labor, and transitioning to automated processes.**

6\. Is AI cost-effective in manufacturing?

:br&#x2A;*Despite high initial costs, AI can lead to long-term savings through improved efficiency and waste reduction.**

7\. How does AI affect manufacturing worker safety?

:br&#x2A;*AI reduces risk by taking over hazardous tasks, improving overall workplace safety.**

8\. Can small manufacturers benefit from AI?

:br&#x2A;*Yes, AI solutions are increasingly accessible for small-scale manufacturers.**

9\. What training is required for AI-enabled manufacturing workers?

:br&#x2A;*Training in AI system operation, data analysis, and potentially programming skills is needed.**

10\. What does the future hold for AI in manufacturing?

:br&#x2A;*The future suggests more integrated, intelligent, and adaptable manufacturing processes driven by AI advancements.**


# Send a File to Node-RED

Have you ever needed to send a CSV file to your Node-RED instance? This file can go on to populate a shift schedule, product specifications, or some other configuration file that is used. In this guide, we provide a couple of options to upload the data to your Node-RED for further processing and to organize the data to be sent on or used.

## Why would you need to send a file to Node-RED?

Often times it is necessary to update lookup tables in a SQL database, but you don't necessarily want to give access to everyone to edit the database, nor do you want to have to do it all yourself. This can often be seen when new products are introduced into a manufacturing facility. It may not be often, but enough that it warrants its own application. This process will guide you in a way that will enable your teammates to upload the files to the system themselves.

Furthermore, on the management layer of most companies, Excel and Google Sheets are the go-to tools to perform data collection tasks. Getting management involved in processes might require you to build an import feature for them. Asking your manager to "Save as" CSV is much easier than teaching them SQL!

## 2 Ways to send a file to Node-RED

There are many approaches that can be taken when solving this. We are going to go over 2 here.

1. [Simple Python Script](https://flowfuse.com/#simple-python-script) - Simple script that will be shared below. It is a simple Python application that allows the user to send a file with a simple command, but this might require a little more technical skills that the end user may not feel comfortable with.
2. [Stand Alone Web Application](https://flowfuse.com/#stand-alone-web-application) - A web-based application that allows the user to upload files to a browser with a selectable endpoint.

### Simple Python Script

This simple Python script sends a file to a Node-RED flow. The flow that will work with this script can be seen [here](https://flowfuse.com/#node-red-ingress).

The script requires **requests** and **Python 3.x**.

Install requests:

```bash
pip install requests
```

Create a file called run.py and paste the contents into the file.

```python
import requests

def send_file(nodered_url, file_path):
    # Open the file in binary mode
    with open(file_path, 'rb') as file:
        files = {'file': (file.name, file, 'multipart/form-data')}
        response = requests.post(nodered_url, files=files)

    return response

# Update the ip address and port of your Node-RED instance
nodered_url = 'http://localhost:1880/fileupload'

# Update the location of your file
file_path = 'C:/Users/myUser/Downloads/shiftSchedule.csv'

response = send_file(nodered_url, file_path)
print(f"Response Status Code: {response.status_code}")
print(f"Response Body: {response.text}")
```

Update the **nodered\_url** to the location of the Node-RED instance. Be sure to adjust the port if the default port of 1880 isn't being used.

Update the **file\_path** with the path to where the file to be uploaded will be located.

**Save**

To run:

```python
python run.py
```

### Stand Alone Web Application

![csv upload application](https://flowfuse.com/blog/2024/01/images/csv_upload_app.png)

This stand-alone web application can be run on either Windows or Linux, .bat for Windows, and .sh for Linux.

#### Installation

Clone the repository and navigate to the directory:

```bash
git clone https://github.com/gdziuba/FF_Send-File-to-NR.git && cd FF_Send-File-to-NR
```

#### Configuration

Edit the lines in the body of [index.html](https://github.com/gdziuba/FF_Send-File-to-NR/blob/21214f88c6c4536f49efb88cf5f84bf52071a88b/templates/index.html#L69){rel="&#x22;nofollow&#x22;"} to include the endpoints to which you would like to send the files.

```text
<option value="http://localhost:1880/fileupload">CSV File Upload</option>
```

### Operating Systems

#### Windows

Run the script:

```bash
.\start_app.bat
```

This will install if necessary, start the Flask Application, and take you to localhost:5000 on the browser.

#### Linux

Make the script executable by running running:

```bash
chmod +x setup_and_run.sh
```

Then run the application with:

```bash
./setup_and_run.sh
```

To access the application, open a browser to the **\<node-red-host-ip>:5000** of the running application.

#### Node-RED Ingress

:iframe{allow="clipboard-read; clipboard-write" height="225px" src="https://flows.nodered.org/flow/effb53752e5d6f767b3c7e5d41a4a6e8/share?height=100" style="border: none;" width="100%"}

Once we have a file ready to be sent, we now need to configure the receiving side in Node-RED. In this example, we are leveraging a CSV formatted file and then converting it to be used at a later time.

A link to the flow can be found [here](https://flows.nodered.org/flow/effb53752e5d6f767b3c7e5d41a4a6e8){rel="&#x22;nofollow&#x22;"}.

To import the flow, follow these [instructions](https://flowfuse.com/blog/2023/03/3-quick-node-red-tips-5/#_1-copy-and-share-your-flows-using-export-and-import).

A Simple HTTP In node can be used in the form of a Post, ensuring the configuration allows for a file.

## Wanna import it directly into your Node-RED instance via a Dashboard?

Check out this [blog](https://flowfuse.com/blog/2024/01/import-a-file) on how to directly import a file into a Node-RED instance via Dashboard 2.0.


# Sentiment Analysis with Node-RED

Have you ever built a sentiment analysis system to extract insights from text content? If yes then I don’t think you'll need an explanation of how complex it is to build. In this guide, we will build a sentiment analysis system with Node-RED using Dashboard 2.0 in a few easy steps.

## What exactly is sentiment analysis?

Sentiment analysis is a context-mining technique used to understand emotions and opinions expressed in text, often classifying them as positive, neutral, or negative. There are many real-world applications of this technique.

- **Analysing Feedback:** Customers, or other stakeholders like employees, are periodically requested to fill out a feedback form. Analysis of such feedback is the most widespread application of sentiment analysis.
- **Campaign Monitoring:** Another use case of sentiment analysis is a measure of influence which is crucial in any marketing campaign.
- **Brand Monitoring:** Brand monitoring is another great use case for sentiment analysis. Companies can use sentiment analysis to check the social media sentiments around their brand from their audience.

## Building a Form in Dashboard 2.0

In this system, we will analyse the sentiment of text content obtained from the user. For this we are going to build a user interface using Dashboard 2.0 and Node-RED.

1. Install Node-RED Dashboard 2.0. Follow these [instructions](https://flowfuse.com/blog/2024/03/dashboard-getting-started/) to install.
2. Drag a ui form widget to the canvas and select the created group.
3. Add an element in the form widget and give it a name and label, select the type as multiline, and set the number of rows according to your need.

!["Taking user input for Sentiment analysis using form"](https://flowfuse.com/blog/2024/01/images/sentiment-analysis-form.png "Taking user input for Sentiment analysis using form")

## Normalizing the data

We need to normalize the payload before sending it to the next node because the form widget always returns an object containing the property of values of form elements.

1. Drag a change node to canvas.
2. Set `msg.payload.$FORM_ELEMENT_NAME` to `msg.payload`, replace the `$FORM_ELEMENT_NAME` with the name of the form element that you have added to the form to obtain user input.
3. Connect the UI form nodes output to the change node’s input.

!["Normalizing the payload using change node"](https://flowfuse.com/blog/2024/01/images/sentiment-anlaysis-change-node\(1\).png "Normalizing the payload using change node")

## Installing custom node

Now it’s time to install a custom node that can perform sentiment analysis for us. In this guide, we will use the `node-red-node-sentiment` which is a Node-RED node that uses the AFINN-165 wordlists for sentiment analysis of words. It returns a sentiment object containing a score and other properties but we will only use the score property. Score property typically ranges from -5 to 5.

1. Install the `node-red-node-sentiment` package by the Node-RED palette manager.
2. Drag a sentiment node to canvas.
3. Connect the change nodes output to sentiment node input.

## Calculating percentage

Why do we need to calculate the percentage? We will show the final result with the help of a circular progress bar and three different emojis. Ideally we should show the progress bar based on a percentage of score instead of negative values.

1. Drag another change node to canvas.
2. set `msg.payload` to `((msg.sentiment.score - (-5)) / (5 - (-5))) * 100` as a JSONata expression, it will calculate the percentage of the score.

!["Calculating the percentage based on the score using the change node"](https://flowfuse.com/blog/2024/01/images/sentiment-analysis-change-node\(2\).png "Calculating the percentage based on the score using the change node")

## Displaying result on Dashboard 2.0

Finally, we are going to display the result on Dashboard 2.0 with the help of the Vuetify circular progress bar and emojis. To do that we will build a Vue component by using our ui template widget.

1. Drag a ui template widget to canvas and create another group for it.
2. Paste the below Vue component snippet into the template widget.

We're aware that not everyone coming into Dashboard 2.0 will be familiar with VueJS. We have a more detailed guide [here](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html#building-full-vue-components){rel="&#x22;nofollow&#x22;"}, but we'll also give a quick overview of the component that we'll use to display the result:

```html
<template>
  <div>
    <v-progress-circular :rotate="360" :size="245" width="20" :width="15" :model-value="msg.payload" color="rgb(0,255,0)">
      <img v-if="msg.payload <= 33.33" src="https://i.ibb.co/VHKZ8sn/imgbin-smirk-emoji-face-emoticon-smile-png.png" width="240" height="240" alt="sad emoji">
      <img v-else-if="msg.payload <= 66.66" src="https://i.ibb.co/nMnybLJ/imgbin-emoji-computer-icons-emoticon-smiley-png.png"  width="240" height="240" alt="neutral emoji">
      <img v-else src="https://i.ibb.co/TK12RrH/Smile-Emoji-Face-PNG-Download-Image.png" width="240" height="240" alt="happy emoji">
    </v-progress-circular>
  </div>
</template>
```

- v-progress-circular is a Vuetify component to display a circular progress bar, for a detailed guide refer to our blog on [Custom Vuetify components for Dashboard 2.0](https://flowfuse.com/blog/2023/10/custom-vuetify-components-dashboard/).
- `rotate` is an attribute that lets you specify the rotation angle of the progress bar.
- `size` and `width` allow you to set the size of the circular progress bar, and another `width` attribute allows you to set the stroke width of the circular progress bar.
- v-if, v-else-if, and v-else, allow dynamic rendering of elements based on specified conditions, in this component we are rendering emojis based on percentages calculated by score.

Your final flow should look like this:

!["Node-RED flow to do sentiment analysis"](https://flowfuse.com/blog/2024/01/images/sentiment-anlaysis-flow.png "Node-RED flow to do sentiment analysis")

## Deploying the Flow

!["Deploying Sentiment analysis Node-RED flow"](https://flowfuse.com/blog/2024/01/images/sentiement-analysis-flowfuse-editor.png "Deploying Sentiment analysis Node-RED flow")

Finally, we have successfully built our sentiment analysis system. Now it's time to deploy the flow, to do that click on the red deploy button which you can find in the top right corner. After that go to `https://<your-instance-name>.flowfuse.cloud/dashboard`

:video{ariaLabel="Sentiment analysis on Text using Node-RED Dashboard 2.0" autoPlay="true" height="306" loop="true" muted="true" playsInline="true" preload="none" width="600"}

## Conclusion

In this post, a sentiment analysis system is built with Node-RED in which the user has a form field to paste text content. After submitting the form, it calculates the percentage based on the output score, which ranges from -5 to 5. The output will be displayed on dashboard 2.0 by a circular progress bar and three different emojis based on percentage.


# FlowFuse is now SOC 2 Type 1 Compliant

FlowFuse achieved SOC 2 type 1 compliance! SOC 2, governed by the American Institute of Certified Public Accountants (AICPA), is a crucial framework for organizations handling customer data.
An independent audit assessed that FlowFuse's controls are effectively designed and operationally applied. Achieving SOC 2 Type 1 compliance validates our practises as an business and provides our customers assurances we apply the highest standards to ensure their data is protected.

## Improving Our Security Posture

At FlowFuse, we understand that professionalizing Node-RED deployments for our clients means adhering to the highest standards, including SOC 2 requirements. This commitment is at the core of our security philosophy. In a world rife with cybersecurity threats and data breaches, taking information security seriously isn't just an option, it's a critical necessity. Our SOC 2 audit was far more than just a procedural step. It represented a comprehensive, independent third-party validation of our robust controls and processes. We believe in transparency and accountability, which is why we document our policies in our open handbook, inviting scrutiny from vendors and reinforcing trust with our customers. Providing this level of independent audit not only serves our customers better and more efficiently but also offers FlowFuse valuable insights into enhancing our security measures and identifying any gaps in our policies. This proactive approach ensures we continue keeping your data safe and secure at all times.
As we continue to grow and evolve, ensuring the security of our systems and data becomes ever more critical. The next step on FlowFuse's journey to provide independant proof we're on the right track: We're currently in the observation phase of the SOC2 type 2.

SOC 2 Type 1 assesses the design of an organization's security controls at a specific point in time, while SOC 2 Type 2 evaluates the effectiveness of those controls over a period of time, typically three to twelve months.

## FlowFuse's Journey to SOC 2 Compliance

### Compliance Partners

The independent audit was performed by Advantage Partners. Their expertise played a large role in our successful attainment of this certification. Before the audit was performed the company went through an extensive process to uncover what policies were missing, required updating, or were already in place. Further, lots of tribal knowledge has been written down and is now enforced by internal policies. For example

1. [Data Management Policy](https://flowfuse.com/handbook/company/security/data-management/#data-management-policy)
2. [Access Control Policy](https://flowfuse.com/handbook/company/security/access-control/#access-control-policy)
3. [Incident Response Policy](https://flowfuse.com/handbook/company/security/incident-response/#incident-response-plan)
4. [Human Resources Security Policy](https://flowfuse.com/handbook/company/security/human-resources/#human-resources-security-policy)

It's been a team effort from engineering to updated HR polices!


# Speech-Driven Chatbot System with Node-RED

Have you ever wanted to integrate speech recognition and synthesis into your Node-RED project and thought it was too complex? Often it has required external services or APIs. However, in this guide, we show you how you can use speech recognition and synthesis in your Node-RED projects without needing an external service or API.

In addition, we make things more interesting by building a system that can listen to us and respond like humans using the Chat-GPT API.
Let's get started!

## What exactly is speech recognition and synthesis?

Speech recognition is a technology where a device captures spoken words through a microphone, checks against grammar rules and vocabulary, and returns recognized words as text. On the other hand, speech synthesis converts app text into speech and plays it through a device's speaker or audio output. There are many benefits and real-world applications of this technology.

- **Hands-Free Operation:** Using speech recognition technology is often used today to perform tasks such as making calls, sending messages, or controlling smart home devices without the need for physical interaction.
- **Accessibility:** It allows individuals with visual impairments to access digital content through spoken words and as discussed above, to control devices without physical interaction.
- **Efficient Content Consumption:** It allows us to listen to information instead of reading. For example, in the audiobook industry by using speech synthesis technology they create audio versions of books which helps users to be more productive.

## Installing Dashboard 2.0

Install Dashboard 2.0. Follow these [instructions](https://flowfuse.com/blog/2024/03/dashboard-getting-started/) to get up and running.

## Building Speech-to-Text Vue component

In this section, we will build a Vue component that will perform a speech-to-text conversion operation using Web speech API, and display results on the dashboard. While we did say previously that we won't need any external API for speech recognition, this [Web Speech API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API){rel="&#x22;nofollow&#x22;"} is not an external API.
This will process your speech locally as it is a JavaScript API that allows us to use speech-related functionalities, such as speech recognition and synthesis, in a web browser directly. It is widely present in modern browsers (except Firefox) which eliminates the need for external APIs to implement these features. Let's now start to build that component.

1. Drag a ui template widget to canvas and select the created group.
2. Paste the below Vue snippets into the template widget step by step.

If you are unfamiliar with Vue, we have added comments that will help you to understand the code better.

We are going to start by pasting a user interface’s snippet which will allow us to interact with our system. This snippet adds a button that triggers our system to listen, an Icon, and a paragraph to display speech recognition results on the dashboard.

```html
<template>
  <div style="display: flex; flex-direction: column; justify-content: center; align-items: center;">
    <!-- Button triggers recording when clicked -->
    <button @click="startRecording">
      <!-- Microphone icon inside the button -->
      <img alt="Microphone" style="height: 62px; width: 62px" :src="microphoneIcon">
    </button>
    <!-- Displaying speech recognition results -->
    <p> <strong>You:</strong> {{ results }}</p>
  </div>
</template>
```

Now paste the below script right after the HTML in the template widget, This script adds functionality of speech recognition in our system.

```html
<script>
export default {
 data() {
   return {
     // Initial data properties
     buttonText: 'Speak',
     microphoneIcon: 'http://icons.iconarchive.com/icons/blackvariant/button-ui-requests-15/512/Microphone-icon.png',
     recognition: null,
     results: '',
   };
 },
 methods: {
   // Method to start recording
   startRecording() {
     this.buttonText = 'Recording';
     this.recognition.stop();
     this.recognition.start();
   },
   // Method to process the speech recognition results
   processSpeech(event) {
     let results = Array.from(event.results).map(result =>   result[0].transcript).join('');
     this.results = results;
     this.$emit('speak', results);
     //Sending result to next node as payload
     this.send(results);
   },
   // Method to handle the start of recognition
   handleRecognitionStart() {
     this.microphoneIcon = 'https://upload.wikimedia.org/wikipedia/commons/0/06/Mic-Animation.gif';
   },
   // Method to handle recognition errors
   handleRecognitionError(event) {
     this.microphoneIcon = event.error === 'no-speech' || event.error === 'audio-capture'
       ? 'https://i.ytimg.com/vi/9YQU797Oy0Y/hqdefault.jpg'
       : this.microphoneIcon;
   },
   // Method to handle the end of recognition
   handleRecognitionEnd() {
     this.microphoneIcon = 'http://icons.iconarchive.com/icons/blackvariant/button-ui-requests-15/512/Microphone-icon.png';
   },
   // Method to set up the SpeechRecognition object
   setupRecognition() {
     this.recognition = new webkitSpeechRecognition();
     this.recognition.continuous = false;
     this.recognition.interimResults = false;
     this.recognition.onresult = this.processSpeech;
     this.recognition.onstart = this.handleRecognitionStart;
     this.recognition.onerror = this.handleRecognitionError;
     this.recognition.onend = this.handleRecognitionEnd;
   },
 },
 mounted() {
   // Initialize SpeechRecognition when the component is mounted
   this.setupRecognition();
 },
};
</script>
```

## Adding an Environment variable

Why do we need to add an environment variable? In this guide, we will build a speech-driven chatbot that involves integrating the Chat-GPT AI model. For this we need openAi’s API key. An API key is a form of private data that needs to be protected from being exposed. That is why we need the environment variables. It provides a secure way to store and access the API key without revealing it directly in the flow. For more details see [Using Environment Variables in Node-RED](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/)

1. Navigate to the instance's setting and then go to the environment section.
2. Click on the `add variable` button and add a variable for Chat-gpt API.

!["Setting environment variable for Chat-gpt token"](https://flowfuse.com/blog/2024/01/images/speech-driven-chatbot-environment-section.png "Setting environment variable for chat-gpt token")

## Setting msg property

Now let’s set that added environment variables as msg's property.

1. Add a change node to canvas.
2. Set environment variable to ms.token property.
3. Connect the change node’s input to the template widget’s output.

!["Setting msg's property for Chat-gpt token"](https://flowfuse.com/blog/2024/01/images/speech-driven-chatbot-change-node.png "Setting msg's property for Chat-gpt token")

## Installing and configuring custom node

In this section, we will install a custom node that will allow us to interact with the Chat-gpt AI model.

1. Install `@sumit_shinde_84/node-red-contrib-node-gpt` by pallet manager, you can use other nodes according to your preference.
2. Drag a ChatGPT node to canvas.
3. Connect the ChatGPT node’s input to the change node’s output.

## Building Text-to-Speech Vue component

We will build a Vue component that converts text received from ChatGPT into speech.

1. Drag another template widget to canvas and select the added group, alternatively, you can create a separate group for this component according to your preference.
2. Paste the below Vue snippets into the template widget.
3. Connect the template widget’s input to the ChatGPT node’s output.

Paste the below snippet in the template widget which displays chat-gpt response on the dashboard

```html
<template>
  <div>
    <strong> Chat-gpt: </strong> {{textToSpeech}}
  </div>
</template>
```

Paste the below snippet right after the HTML, This snippet adds the functionality of text-to-speech into our system, which triggers when msg received by the previous node.

```html
<script>
  export default {
  data() {
    return {
      // Data property to store the text to be spoken
      textToSpeech: '',
    };
  },
  methods: {
    // Method to trigger text-to-speech
    speakText() {
      // Check if there is non-empty text to speech
      if (this.textToSpeech.trim() !== '') {
        // Create a SpeechSynthesisUtterance with the text to be spoken
        const utterance = new  SpeechSynthesisUtterance(this.textToSpeech);
        // Use the SpeechSynthesis API to speak the provided text
        window.speechSynthesis.speak(utterance);
      }
    },
  },
  mounted() {
    // Event listener for receiving messages    
  
     this.$socket.on('msg-input:' + this.id, (msg) => {

      // Update the textToSpeech property with the received message payload
      this.textToSpeech = msg.payload;
     
      // Trigger text-to-speech with the received message
      this.speakText();
    });
  },
};
</script>

<style scoped>
  textarea {
    width: 100%;
    height: 100px;
    margin-bottom: 10px;
  }
</style>
```

Your final flow should look like this:

!["Speech Driven Chatbot system flow"](https://flowfuse.com/blog/2024/01/images/speech-driven-chatbot-flow.png "Speech Driven Chatbot system flow")

## Deploying the Flow

!["Deploying Sentiment analysis Node-RED flow"](https://flowfuse.com/blog/2024/01/images/speech-driven-chatbot-flowfue-editor.png "Deploying Sentiment analysis Node-RED flow")

We have successfully built our Speech-Driven Chatbot System. Now it's time to deploy the flow, to do that click on the red deploy button which you can find in the top right corner. After that go to `https://<your-instance-name>.flowfuse.cloud/dashboard`

:video{ariaLabel="Speech Driven Chatbot using Node-RED Dashboard 2.0" autoPlay="true" height="400" loop="true" muted="true" playsInline="true" preload="none" width="648"}

## Conclusion

In this guide, we have built a Speech-Driven Chatbot System which allows us to understand how we can add speech recognition and synthesis features into our project without any external API or custom node. It also provides a brief overview of how we can integrate chat-gpt into our system.


# Selecting a broker for your Unified Namespace

When starting to roll out a new data distribution architecture for the unified namespace (UNS), one of the first questions you'll ask is, "What broker should I select for my UNS? The broker must implement a publish-subscribe (pub-sub) pattern, though that leaves plenty of options.

## Technology selection

### Two protocols frontrunners

Currently, there are two protocols that are front runners for becoming the de facto data transfer choice in (industrial) IoT: [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/) or [Kafka](https://flowfuse.com/blog/2024/03/using-kafka-with-node-red/). They’ve been designed for different use cases and have different properties. At this time, MQTT is more often deployed as a broker in the unified namespace and is generally the best choice when starting to implement a unified namespace, it also features better support from hardware vendors.

First and foremost, MQTT has been designed to enable IoT use cases. The main design objectives were to be lightweight to enable low-bandwidth communication, enable low-power devices, and handle unreliable networks. MQTT enables a large number of data producers and consumers to collaborate.

Kafka is designed as an event streaming platform. Its initial adoption was mostly for data brokers between microservices all part of the same web backend for large sites like LinkedIn. When communicating data between servers or just a few data centers around the world, there’s less of a concern around the reliability of the connection or to enable constrained devices to participate in the shift towards a unified namespace.

Generally, MQTT is more often seen deployed in practice as data distribution architecture.

### The Cloud route

Cloud message queue brokers like AWS Kinesis and GCP Pub/Sub offer a high level of convenience. Scaling the infrastructure for real-time data processing and communication is their concern, the customer is mostly concerned about paying the bill. These brokers are fully managed, meaning they are maintained and updated by the cloud provider, reducing the burden on developers.

However, this convenience comes with the tradeoff of vendor lock-in. When selecting these brokers, the cloud vendor has usually adapted their technology to support many protocols, and these offerings are usually jack-of-all-trades solutions – master of none. It creates a situation where the unified namespace implementation will change in subtle ways to accommodate the vendor instead of the other way around. An organization might become so reliant on a particular vendor's products or services that they are unable to easily switch to another vendor or protocol that serves their business objectives better. The cost of changing is exacerbated by having to train personnel on new and open-source protocols.

In addition to vendor lock-in, cloud message queue brokers also introduce reliance on the network to the cloud providers. Network reliability for (industrial) IoT is a major concern due to the physically distributed nature, adding external dependencies creates more variability.

### Exotic options

RabbitMQ is a widely used open-source message broker that’s mostly used as an event message bus for web applications. It can also function as a hub in a unified namespace. The broker primarily supports the [AMQP](https://flowfuse.com/node-red/protocol/amqp/) (Advanced Message Queuing Protocol), considered the industry standard for high-performance messaging systems. It also supports STOMP (Streaming Text Oriented Messaging Protocol) and MQTT (MQ Telemetry Transport), catering to various messaging needs.

NATS, short for Network Agnostic Messaging System, is another open-source message broker that is designed for simplicity and reliability. NATS implements its own protocols, making it harder to be interoperable with hardware and software previously purchased. NATS has requirements on message structure too, which creates another barrier to adoption for IoT use cases.

## How Node-RED Helps

Node-RED provides a powerful and flexible way to integrate with various brokers, supporting protocols such as [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/), [Kafka](https://flowfuse.com/blog/2024/03/using-kafka-with-node-red/), and [AMQP](https://flowfuse.com/node-red/protocol/amqp/). It allows you to build and manage workflows that interact with your chosen broker, seamlessly connecting different data sources and systems.

However, using Node-RED alone in production environments requires additional considerations, such as server deployment, instance management, security implementation, and scalability. This is where FlowFuse enhances Node-RED's capabilities by adding production-ready features. FlowFuse simplifies managing and deploying Node-RED applications, providing essential functionalities like scalability, robust security, and efficient collaboration tools.

**[Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now for a free trial and experience how FlowFuse can streamline your Node-RED deployments and management.**

## Conclusion

An MQTT broker is currently recommended as a broker solution for your unified namespace. There are many different implementations of the protocol available. At FlowFuse, we’re using [Mosquitto](https://mosquitto.org/){rel="&#x22;nofollow&#x22;"}, due to its efficiency on resources and flexible authentication layer. Further, our customers are reporting to be happy with [EMqX](https://www.emqx.io/){rel="&#x22;nofollow&#x22;"}, which is written in Erlang – itself a messaging-oriented programming language – and has been put through its paces in practice. If you’re dipping your toes into the unified namespace, either of those or another MQTT broker is currently recommended.

Note that it’s recommended to allow yourself flexibility in the broker, and treat it as a message-passing system, and your organization will be able to easily swap it out later if any other broker is a better fit later on.


# Unified Namespace: When to Use It, and When to Choose Something Else

At FlowFuse, we're convinced of the Unified Namespace (UNS) architecture for IoT cases. It's a powerful tool that can make information much more readily available and easy to consume. However, as with any architecture, there are times when it's not the best choice. In this blog post, we'll discuss when to use the UNS and when to consider other options.

### Latency sensitivity

When automating strictly digital tasks, there's generally no or very lenient requirements on latency. Requesting APIs from another server, normalizing data, and sending it towards another service takes very little time, though it hardly matters if you’re 100ms later than usual. In industrial automation or other cases where physical safety is safeguarded, there’s a requirement for low latency to ensure that data is transmitted and processed quickly enough to maintain real-time control of processes.

Extending this beyond the UNS – For controlled use cases, use specialized software and do not rely on third parties to broker the information correctly.

However, while control was used as an example here, the general case here is not the UNS for real-time, low-latency communication.

### Large files or binary data

Sending large blobs of binary data, such as pictures and archives, through UNS is not recommended due to several drawbacks. First, UNS is optimized for small, mostly text-based communication, and sending binary data through it can significantly increase message size and processing overhead. As the sender of the data, there’s also generally no control over the number of receivers of the data, so if you send a large file to the broker once, it might need to be copied many times for every receiver.

To overcome these limitations, it is more efficient and practical to store binary data elsewhere, such as on a shared storage location or a cloud service. Once the data is stored externally, a reference to its location can be sent through UNS.

### Data security and data access

The UNS becomes more useful the more hubs are connected, and it stands to reason that better business outcomes are achieved when everything is connected. Not just the sensor data (Level 1 of the [automation pyramid](https://flowfuse.com/blog/2023/08/isa-95-automation-pyramid-to-unified-namespace/#automation-pyramid-visualization) *except actuators*), but also the customer-facing systems like your ERP (Level 4 or the automation pyramid), and even your CRM, Customer Relationship Management. This would allow better insight and communication with the customer when, for example, their car is done with production and will be shipped to them. The CRM contains personal details about the customer. Publishing what a customer ordered might thus disclose personally identifiable information (PII).

Connecting a CRM is certainly possible, and could streamline the supply chain, but PII shouldn’t be published. Consider if there’s a unique ID for the customer instead to use. Does your CRM, for example, keep a customer ID? If not, mask the information instead. Use strong hashing algorithms like SHA-512 to hash their email addresses. This way, other systems can cross reference messages received in the UNS, without ever knowing the customer PII. Another venue to explore is topic-based authentication for data receivers, which most data brokers provide. However, stripping and masking PII is still highly recommended either way.

### In Conclusion

The Unified Namespace is a powerful architecture that can make IoT data more accessible and easier to consume. However, it's not always the best choice for all applications. When considering whether to use the UNS, be sure to weigh the benefits against the potential risks. If you need low latency, strong data security, or fine-grained control over data access, you may need to adjust your architecture pattern or instantiate point-to-point connections through REST or other interfaces.


# Connect Node-RED to KepserverEX OPC server.

KepserverEX, often referred to as Kepware, is an OPC server that has been the important tool many manufacturing companies have used on their digital transformation journey. It plays an important role for many to extract data from PLCs, Programmable Logic Controllers, without having to directly interact with them.

## PTC's KepserverEX

PTC's [KEPServerEX](https://www.ptc.com/en/products/kepware/kepserverex-ppc){rel="&#x22;nofollow&#x22;"} is a versatile connectivity platform designed to securely manage, monitor, and control diverse automation devices and software applications. Central to its functionality is the OPC standard, which enables universal communication across industrial hardware and software, facilitating data exchange. This makes KEPServerEX particularly valuable in a variety of use cases, such as real-time data monitoring, machine-to-machine (M2M) communication, and industrial Internet of Things (IIoT) applications. It serves as a critical bridge in the automation and controls engineering space, offering a robust solution for integrating disparate systems, thereby enhancing operational efficiency and enabling data-driven decision-making. Integrating KEPServerEX with Node-RED extends this functionality, by allowing bidirectional communication for sending, storing, and or manipulating data.

### Scope

The goal of this blog is for a quick start guide on the configuration for collecting data from a KepserverEX OPC server. We are going to be leveraging the [node-red-contrib-opcua](https://flows.nodered.org/node/node-red-contrib-opcua){rel="&#x22;nofollow&#x22;"} node. We will assume that you already have [KepserverEX](https://www.ptc.com/en/products/kepware/kepserverex-ppc){rel="&#x22;nofollow&#x22;"} install and ready for the integration. We will be using Basic256Sha256 security in this guide with anonymous authentication. Assumptions of the installation include allowing Default configuration of the installation of KepserverEX 6.15 and allowing dynamic tag addressing.

### Configure Connection from Node-RED to Kepserver

#### Step 1: KepserverEX

The first thing we need to do is check our **OPC UA Configuration Manager** for the security requirements for our environment. In the tray at the bottom, click on the KepserverEX symbol and select **OPC UA Configuration**

![kepware tray](https://flowfuse.com/blog/2024/02/images/kepserverex-tray.png)

If your Node-RED instance lives on the same server that your KepserverEX is on, pick accordingly or click add if you need to define by ip address. This is for setting different credential requirements for localhost vs remote host access. Also note, that if you have multiple network adapters, make sure to select the adapter that is in use.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

![kepware endpoint definition](https://flowfuse.com/blog/2024/02/images/kep-endpoint-definition.png)

We are testing locally on the server, so we will use the one selected for loopback addressing. We will be leaving the OPC server port as default and select **Basic256Sha256** with **Sign and Encrypt**.

Click **OK**.

#### Step 2: Node-RED

Next, navigate to your Node-RED instance and install the [node-red-contrib-opcua](https://flows.nodered.org/node/node-red-contrib-opcua){rel="&#x22;nofollow&#x22;"} node if you haven't already done so.

Import the flow below into your Node-RED environment.

:iframe{allow="clipboard-read; clipboard-write" height="225px" src="https://flows.nodered.org/flow/04a84fe5b0db7cda9e74ba811e7b0ca5/share?height=250" style="border: none;" width="100%"}

Next, let's configure the **OPC UA Client**. Click the **pencil** to add a new OPCUA-Endpoint.

![kepware node-red encrypted opc ua node](https://flowfuse.com/blog/2024/02/images/opcua-endpoint-node-red-encrypted.png)

For the endpoint, **copy** the endpoint definition from the KepserverEX OPC UA Configuration Manager. In our example, it is `opc.tcp://127.0.0.1:49320`, and paste it into the Endpoint. For SecurityPolicy select **Basic256Sha256**. For SecurityMode, select **Sign\&Encrypt**. Lastly, we will be selecting **Anonymous**. Click **Update**, then **Deploy**.

Trigger the flow by **clicking** on the inject node. The server may not connect at this time, and it is expected.

![kepware node-red invalid endpoint](https://flowfuse.com/blog/2024/02/images/node-red-opc-ua-invalid-endpoint.png)

#### Step 3: KepserverEX

Moving back over to KepserverEX, Click on the tray again in the bottom of the screen and select **Configuration**, then select **Edit** from the file menu, then **Properties**. Next, Select **OPC UA** and ensure that **Allow Anonymous login** is set to **Yes**. Click **OK**.

![kepware node-red anonymous login](https://flowfuse.com/blog/2024/02/images/node-red-kepware-anonymous-login.png)

Select the tray at the bottom of the screen again, and select **OPC UA Configuration**. Select the **Trusted Clients** tab.

![kepware node-red trusted client before](https://flowfuse.com/blog/2024/02/images/kepserverex-trusted-client-before.png)

Now select the **NodeOPCUA-Client** and then **click*&#x2A; Trust. &#x2A;**If you don't have the client option, trigger the inject node again from the Node-RED flow and check the logs***

![kepware node-red trusted client after](https://flowfuse.com/blog/2024/02/images/kepserverex-trusted-client-after.png)

#### Step 4: Node-RED

Lastly, Navigate back to Node-RED and **trigger** the inject node. This node will now browse the project from the KepserverEX and display all of the existing tags.

![kepware node-red browsed tags](https://flowfuse.com/blog/2024/02/images/kepware-opc-browsed-tags-node-red.png)

### Read Tags

We will be leveraging the default Simulated Examples for reading tags from KepserverEX. Let's move on to the next set of flows.

![kepware node-red read tags](https://flowfuse.com/blog/2024/02/images/node-red-kepware-read-tag.png)

Edit the OPCUa-Item node and note the item.

```text
ns=2;s=Simulation Examples.Functions.Ramp1
```

Let's break down the syntax, ns stands for namespace that will coincide with the project. In this case, it is namespace 2. Once the namespace has been selected, we are use **Dynamic Addressing** to select the tag through the variable **s**, which stands for string type of NodeId. **Click** Done. Now let's **trigger** the Read inject node and view the debug output.

The debug node is set to show a complete msg object. Note the payload as the value of the variable.

![kepware node-red read tags output](https://flowfuse.com/blog/2024/02/images/node-red-debug-output-opc.png)

### Write Tag

Writing a tag is a similar process. The only difference is that a variable is set in the **OPCUa-Item** node and the **OPCUa-Client** action is set to Write.

In this example, we created a new variable in KepserverEX under **Simulation Examples > Functions** called myInt of Date Type Long.

![kepware node-red write tags](https://flowfuse.com/blog/2024/02/images/node-red-kepware-write-tag.png)

View the OPCUa-Item node and note the item.

```text
ns=2;s=Simulation Examples.Functions.myInt
```

**Click** Done and **Deploy**

Open up the **Quick Client** within KepserverEX and navigate to the address of **Simulation Examples.Functions** and look for myInt. It should by default, be 0. **Trigger** the inject node within Node-RED to see the Value change within the Quick Client.

![kepware node-red write tags output](https://flowfuse.com/blog/2024/02/images/node-red-debug-output-write-opc.png)![kepware node-red quick client](https://flowfuse.com/blog/2024/02/images/kepware-quick-client.png)

### Conclusion

This guide was designed to help you easily connect your Node-RED instance to KepserverEX with security. For more examples of how to do more advanced configuration, please watch the past [webinar](https://flowfuse.com/webinars/2023/getting-started-opcua-node-red/) going over these [examples](https://github.com/mikakaraila/node-red-contrib-opcua/tree/master/examples){rel="&#x22;nofollow&#x22;"} in detail.


# History of Node-RED

In January 2013, I could have never foreseen that my fun little proof-of-concept project would become Node-RED, an open source low-code environment with millions of deployments in IoT and automation.

Long before IoT became the ubiquitous term it is today, I was working in IBM’s Emerging Technology Group playing around with capturing data from devices and doing interesting things with it. The team focused on very fast-paced, short, proof-of-concept projects and was afforded time to learn new skills, innovate and work on side projects.

My background working with the MQTT protocol space before it was known outside of IBM led me to a side project: I wanted some way to visualize mapping messages on an MQTT infrastructure to see how they come in on one topic and get sent out on another.

Using it as an excuse to also start playing the relatively new Node.js runtime, I spent a day or two putting together a little demo of an application that would connect to an MQTT broker and visualize the topic mappings in a web browser.

Showing it to my colleague, Dave Conway-Jones, I mentioned it wouldn't take much to make it more interactive; to let you draw the mappings and apply them. He sent me on my way to do just that and, 24 hours later, I had a simple browser-based application that could define and apply mappings between MQTT topics.

It very quickly became useful.

![](https://flowfuse.com/blog/2024/02/images/history-nr-screenshot.png)

An early screenshot of Node-RED

The projects Dave and I were working on became rich sources of requirements; each project needing to access data from some other source such as a device plugged into a serial port, or being able to modify the data with a bit of JavaScript code.

I spent a few days redesigning the code to make it easier to write in new nodes, unlocking the ability to quickly add in the function node, change node, and switch node, which became the basic building blocks of the tool.

The utility of the application was clear, and more colleagues started making use of it - all grounded in real client projects. But it was still a tool largely known only to our team.

### Going Open Source

As we considered how best to move the project forward, we essentially had two choices; keep it to ourselves and see if we could get an IBM product group to back turning it into a fully-fledged product, or to go the open source route. In my mind, the OSS route was the natural fit and that is what we ultimately chose to do, getting it published in late 2013.

I demoed Node-RED in late 2013 at a London IoT meetup and word spread among my peers in that community. A week later, I was at an open source hardware conference and attended a workshop on home automation. I was surprised to see Node-RED on everyone’s screens! The facilitator had seen Node-RED and reworked his workshop so that people didn’t have to worry about writing lines of code and were able to do useful things much more quickly.

![](https://flowfuse.com/blog/2024/02/images/history-ibm-lab.jpg)

The IBM Emerging Technology Demo Lab - many of the demos were built on Node-RED

### Building an audience

A key step forward was when IBM was preparing to launch its new IBM Cloud service. In the months before the launch, they were looking for innovative ideas that could help expand the offering. We put forward a proposal to use this tool we'd created as a way to visualise the mapping of web services within the cloud.

This generated some great interest from a wider audience within the company, and whilst that concept didn't ultimately come to anything, we had gotten our project noticed.

Over time, we started seeing Node-RED being picked up by more than just the OSS community. Companies started using it with their own hardware devices and online services.

By this time, IBM Cloud had launched, and from our previous conversations with them, we got Node-RED included as one of the 'starter applications' in the catalogue that gave users a one-click option for getting Node-RED running in the cloud.

![](https://flowfuse.com/blog/2024/02/images/history-cloud-catalog.png)

Node-RED in the original IBM Cloud catalog

### Moving to a Foundation

As we saw the project grow, discussions were had around the longer-term future of the project. Some companies voiced a concern about it being a single-vendor open source project. This also came at a time when IBM was actively working with the Node.js project to help relaunch the Node Foundation (which has since become the OpenJS Foundation). This culminated in Node-RED joining the foundation as one of its founding projects, alongside other well-established projects such as Node.js itself, jQuery and many others.

Having an independent governance structure around the project gave companies more confidence to get involved, knowing they had an equal voice in its development. Hitachi became big supporters of the project and had a team dedicated to working on it.

For software developers, time spent writing boilerplate code is not time adding value to the application they’re building. With low-code, Node-RED abstracts all that boilerplate so they can focus on the business problem.

Device manufacturers paid attention when Node-RED was installed on the Raspberry Pi image, with its low-code accessibility attracting a broad range of people from systems engineers building automations to IoT hobbyists.

Now with millions of deployments, Node-RED continues to collect, transform, and integrate data through visualized dashboards. And, as this open source community grows it remains rooted in the two pillars of its low-code user experience, and its extensibility.


# Node-RED: The perfect adapter and middleware for your UNS

Digitalization is at the inflection point where it’s been adopted enough that the additional investments provided better and better ROIs for organizations. The next bump in ROI will be achieved through the UNS. A torrent of information is more useful when structured and adapted for new use-cases. Either a [performance dashboard](https://flowfuse.com/blueprints/manufacturing/performance-overview/), Artificial Intelligence, or station metrics – each is built faster when the data is readily available and well structured? As a company started around Node-RED, we’ve not spoken a lot where FlowFuse fits into the picture, which is what this post is about.

## Adapting legacy machines to the UNS

The digitalization effort in traditional industries like manufacturing, agriculture, and beyond, has additional challenges due to the high capex assets that need to join in the effort. As these assets will not be replaced, the only way is to adapt them. Adaptation will require tooling that can interact with sensor data regardless of the protocol, data format, and data structures.

Node-RED bridges the gap between analog and digital data acquisition by seamlessly integrating with a vast array of protocols including serial bus support, Modbus, MQTT, and OPC-UA. Its format agnostic nature allows it to handle diverse data formats, from parsing binary data, to JSON, Protobuf (Sparkplug B), making it a versatile tool for extracting and manipulating data from various sources. With its widespread adoption, Node-RED ensures compatibility with almost every protocol, enabling users to connect and process data from a wide range of devices and applications.

## Contextualisation of the data

When data is captured and parsed, it needs to be contextualized. For example; in a UNS the topic hierarchy on which to publish and subscribe to is based on location – that is; context. Furthermore, a raw sensor reading might miss details like the unit of measurement, what message version is required, or doesn’t supply the information in a proper type. All these minor niggles are actual blocking issues for adopting all sensors to the UNS. In some cases makes and models of the sensor might influence the tolerances of readings, it’s a good idea in those cases to include that information in the message.

## Filtering and preprocessing

Not all messages are created equal, which was discussed in [an earlier post](https://flowfuse.com/blog/2024/01/unified-namespace-when-not-to-use/.). In two of the three examples provided in that post, Node-RED can preprocess or filter information before sending it to the UNS. In the case of big files or binary data, Node-RED can store it in S3 or a network attached storage layer, or even store it locally through a REST interface. The distribution of the event that created the binary data is still published through the UNS though.

Filtering of data is also a great use-case for Node-RED, generally just a `change` node and the data is ready to be published. The flexibility to do virtually anything with captured data is what makes Node-RED such a strong partner for your UNS.

## Continuous improvement

While it would be ideal if data schemas were stable, changes are frequent and unpredictable. It’s a non-obvious requirement for your UNS edge to be adaptable. Message structures can change, to add or remove data from them. Though also the format, from JSON to Sparkplug B, or maybe to XML. Not to say that standardization of messages will continuously require updates to leverage the UNS for higher business value.

A swiss-army knife as both data sender and receiver is not just a nice-to-have, it’s a requirement.

## Scalable operations

While there are other tools available that can adapt to a few protocols, or parse a handful of data formats, there’s no alternative for Node-REDs breadth and depth of integration level. This is why many organizations have already adopted Node-RED for their edge cases, which their current standard solution doesn’t handle.

There’s no situation where a vendor provided, off-the-shelf solution handles protocols and formats across vendors, modern and legacy OT, that also satisfies the IT requirements unless the extensibility is handled through an Open-Source community, with compliance and security controls from a professional entity surrounding the open source project.

### How FlowFuse Enhances Node-RED

While Node-RED is powerful for implementing UNS, its management and deployment can be complex. FlowFuse simplifies this process with a unified platform that offers one-click deployment, secure management, and scalability for Node-RED applications. It enhances collaboration through centralized management of all Node-RED instances, ensuring streamlined operations and increased efficiency.

**[Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now for a free trial and explore how FlowFuse can transform your Node-RED experience.**


# Node-RED in a Unified Namespace Architecture

As we embark on the journey toward a more interconnected industrial environment, the emergence of a Unified Namespace (UNS) as the fundamental framework for facilitating communication among various systems and devices has become a focal point of discussion. I've often been queried about the role of Node-RED in a UNS architecture. To illuminate this, let's delve into an exemplary UNS architecture, underlining the classic use cases for Node-RED within this framework.

In this Article: [Node-RED: The perfect adapter and middleware for your UNS](https://flowfuse.com/blog/2024/02/node-red-perfect-adapter-middleware-uns/), where classic use cases for Node-RED are delineated. Building upon that foundation, this discussion aims to present a tangible architectural example, showcasing the practical implementation of these use cases.

## Simplifying Complexity: The Two-Layered Approach

For ease of understanding, consider the architecture split into two principal layers: the Shopfloor layer and the Service layer.

**The Shopfloor Layer**
This is where the physical assets dwell, requiring connectivity through a network layer, which in our example, is the UNS. It acts as the foundation for data flow from the operational technology (OT) on the shop floor to the information technology (IT) in the Service layer.

**The Service Layer**
Here resides the applications and software that analyze data, transforming raw metrics into actionable insights. It's where the data becomes meaningful through analytics, dashboards, and decision-support tools.

## The Roles in UNS Architecture

Within this bifurcated architecture, we have two general categories of actors: Indirect Consumer/Producers and Direct Consumer/Producers.

**Indirect Consumer/Producers**:
These actors cannot natively communicate with our UNS broker. The communication barrier could be due to protocol differences, such as not using MQTT, or payload structures incompatible with your UNS's schema. This is a common challenge in manufacturing, especially in "brownfield" scenarios where legacy machines and equipment from various eras must be integrated.

In such cases, Node-RED shines as a middleware for protocol conversion and data contextualization. Take, for example, the topic hierarchy in UNS based on location for context. A raw sensor reading might lack necessary details like measurement units or message versions. Node-RED steps in to enrich this data, ensuring compatibility with the UNS. In our [concrete architecture example](https://flowfuse.com/blog/2023/12/unified-namespace-data-modelling/), we have an indirect PLC producer. With Node-RED, we can convert and contextualize the data from this PLC for the UNS, ensuring smooth communication and effective integration.

**Direct Consumer/Producers**:
Contrastingly, direct actors can interact with the UNS out of the box. Modern industrial equipment usually falls into this category, equipped to speak the language of the UNS directly. However, the challenge remains not just in protocol communication but also in data contextualization. Merely speaking the same language is not enough; the data must also carry the correct context to be fully understood and utilized.

![Example Architecture](https://flowfuse.com/blog/2024/02/images/unified-namespace-architecture.png)

## Harnessing Node-RED for Actionable Insights

Node-RED's prowess extends beyond middleware capabilities; it can also derive actionable insights. Our example architecture includes Dashboards for both the Human Machine Interface on the Shopfloor and an OEE Dashboard in the Service Layer. These dashboards engage with the UNS, calculating KPIs directly within Node-RED. For manufacturing applications, our [Blueprint Library](https://flowfuse.com/blueprints/) serves as a robust starting point, offering one-click deployment to your Node-RED managed instance.
Node-RED emerges not just as a translator between machines and UNS but as an interpreter and analyst, generating real-time insights that drive decision-making and operational efficiency. The role of Node-RED in UNS architecture, therefore, is not ancillary; it is central to realizing the vision of a connected, intelligent industrial ecosystem.

![Andon Live Dashboard](https://flowfuse.com/img/ANDON-Screenshot-D4DBvWieJZ-650.avif)


# Should You Invest in Professional Services for Your Node-RED Development?

Professional services come in many different forms. Anything from setup and configuration, flow development, to node development. In this article, we will cover a few examples of how you can leverage professional services for your Node-RED applications.

## Should You Invest in Professional Services for Your Node-RED Development?

Node-RED is multifaceted, and Professional Services (PS) can apply to many use cases. We will break it down into three categories that will help identify whether PS (Professional Services) is right for you. Those categories will be setup, flow development, and node development. Each takes a different skill set and has different levels of complexity.

Before we jump into things, we need to understand the value proposition of Node-RED. Why Node-RED? Node-RED is a tool that makes Citizen Development a reality. It should be treated that way throughout the development journey regardless of Professional Services or not. Following standard procedures that minimize complexity, for example: reducing the use of function nodes when other nodes would be more ideal. Don’t overcomplicate things that don’t need to be or better said by this quote.

> Easy things should be easy, and hard things should be possible.
> -Larry Wall

### Setup

It is often recommended to use PS for the setup and installation of products,
and Node-RED and FlowFuse aren't different. This becomes especially true if you
desire to professionalize your Node-RED instance. The reason for this is that PS
teams focus on minimizing the risk of application failure, security compromise,
and data/ip loss. This is an area of PS that can easily be overlooked, mainly
there aren't any negative consequences in the short term. The work these teams focus on prevents catastrophic issues in the future. With Node-RED and FlowFuse, these teams will focus on installing FlowFuse based on system requirements and prerequisites, migrating existing Node-RED instances, securing your environment, and integrating with your existing ecosystem of applications.

### Flow development

Oftentimes, many think of Flow development when they think of PS for Node-RED. There will be a process flow that needs to be accomplished, but it is leveraging standard nodes built within the Node-RED platform. Occasionally, there will be a need to install a custom node from the pallet manager, but the complexities in the development are adhering to a process and or visualization. There may be complex data translation, but for the most part, access to the command line of the Node-RED instance is unnecessary. Professional services may be used in situations like this where knowledge of specific systems that Node-RED is integrating into is complex. For example, a complex backend database for specific industry-wide used applications.

### Node Development

At the core of some integration projects lies a critical requirement: the need for specific integrations that align precisely with your application's demands. This is where Node-RED's open-source nature becomes its most significant asset. Node-RED allows for the development of custom nodes, catering to specialized protocols unique to your organization or to serve niche applications. Such node development isn't just another feature; it represents the foundational element of Node-RED, embodying the platform's core value proposition.

Whether addressing the need for custom integration with internal systems or expanding functionality to include less common applications, node development stands as the pivotal mechanism for enabling these capabilities. This critical development can be undertaken in-house, leveraging your team's expertise, or through PS specialized in node development.

#### Conflating Flow and Node Development

It is important when scoping out a project to identify all of the potential nodes needed and identify any potential missing ones. The skills for developing Nodes and Flow development, while similar, are often different skill sets. Having these identified will help prevent scope creep and setting expectations on timelines.

## Conclusion

As we've explored throughout this article, Professional Services for Node-RED can significantly enhance the efficiency, security, and scalability of your automation and integration projects. From the initial setup and configuration to the intricacies of flow and node development, the expertise PS teams offer can be invaluable. The decision to engage with Professional Services should be informed by your project's specific needs, internal capabilities, and strategic priorities. Whether it's leveraging PS for the foundational setup of your Node-RED instance, outsourcing flow development to expedite project timelines, or seeking expert assistance for node development, the goal is the same: create a coding environment that is conducive to citizen development.

If you are interested in professional services or consultation, [please reach out](https://flowfuse.com/professional-services/).


# Bringing Software Development practices to Node-RED

I'm always thinking about how we can continue to improve the Node-RED experience. One area I like to explore is to make sure we learn the right lessons from the Software Development world.

In this post, I'm going to look at some of the common practices in modern Software Development and show how they translate to the Node-RED world.

### Linting

Linting is a way of examining some code and automatically spotting things that need attention. This can range from stylistic errors ("Use tabs, not spaces") to real bugs that will prevent the code from working as intended.

This is all about spotting problems *before* the code runs. It also helps ensure consistency when you have multiple people contributing to the code.

Having code that is consistently formatted and free of syntactic mistakes makes it much easier to maintain.

Applying this concept to Node-RED, we have the [`nrlint` tool](https://github.com/node-red/nrlint){rel="&#x22;nofollow&#x22;"}. This is a linting tool that can run either on the command-line or within the editor directly to spot potential problems with the flows.

On the stylistic side, for example, it can highlight nodes that aren't properly aligned to the grid. Whilst this doesn't have any bearing on the runtime operation of the flow, it encourages keeping the flows tidy and orderly.

It can help identify potential infinite loops in flows, and highlight Debug nodes without a name set.

![](https://flowfuse.com/blog/2024/02/images/node-red-linter.png)

### Debugging

Whether you are writing lines of code or not, eventually you will need to figure out why your application isn't doing what you think it should.

In Software Engineering there are two typical approaches. One is to add debug statements through the code to print out bits of information as the program runs. Then, depending on what output you got, you'd move the debug statements around, add some more, print out different bits of information - all until you'd nailed down the problem. This is the Debug node approach in Node-RED; adding nodes at different points of your flow to capture some piece of information and then iterating as you go.

This is probably how most Node-RED users go about it today. The downside is you end up leaving the Debug nodes in place, capturing information long after it is needed.

The alternative approach is Step-by-Step debugging. This is why you are able to pause the program and then step it forward one statement at a time - examining the state at each point. But what's the equivalent for low-code? Pretty much exactly that when you have the [Node-RED Debugger plugin](https://flows.nodered.org/node/node-red-debugger){rel="&#x22;nofollow&#x22;"} installed.

This allows you to set 'breakpoints' on any node input or output that are triggered when a message arrives at that point of the flow. The Debugger will then pause the whole runtime and shows you all of the queued up messages in the flow.

You can then examine those messages and tell the Debugger to 'release' them one at a time - seeing how the flow progresses.

![](https://flowfuse.com/blog/2024/02/images/node-red-debugger.png)

### Testing

Testing code is a critical part of developing software. You want to make sure it does what you want. But it's more than just manually testing it once and then letting it go; you want to have tests you can run regularly, whenever you make changes, to ensure you don't break something that was working previously.

In the Software Development world, there are all sorts of testing methodologies and techniques; unit testing individual components, system testing larger sections, stubbing out components to simulate different conditions, integrating test suites into the whole development process.

They each have their own place in the process of software development. The question is, how does this apply to Node-RED?

Most Node-RED users today will of course be testing their flows whilst developing them - iterating until the flow does what is needed. It's far less common to have a set of repeatable tests including the flows.

That is certainly achievable with Node-RED today, albeit with some limitations. For example, a typical test will be to verify that, given a set of particular inputs, the outputs look correct. This can be done using Inject nodes to quickly trigger messages with different values, and use Debug nodes to examine the results.

That isn't ideal as you end up littering your flows with these extra Inject nodes, and it still requires manually verifying the results. It also doesn't work well if your flows need to interact with external systems - such as saving values to a database. You don't want to pollute your system with test data.

So what would be the ideal workflow? This is something the project has spent some time exploring in the past, and the start of a design was put together.

The concept would be to introduce a Testing sidebar to the editor. Within that, you can define a set of test cases. Then for each test case, you can customise the behaviours of individual nodes. For example, a test case may disable an MQTT node at the start of a flow, and tell the runtime to inject a message in its place. For each subsequent node in the flow, the test case would then be able to either to bypass it (to avoid interacting with external systems), or to add checks on what the node outputs. Each test case would then define some criteria for what it means to pass the test.

As with the Debugger plugin, the Test Runner would be disabled by default - so the 'production' flows aren't modified in anyway. When the Test Runner is enabled, it would then take care of running each test in return and reporting back the results.

The main challenge is providing a user experience that makes it easy to create these tests in a way that is consistent with the low-code nature of Node-RED.

Whilst this is very much a future roadmap item for Node-RED, it is one I hope we can start moving forward soon. Having a good, repeatable, testing strategy in Node-RED will make it stand-out from many of the other low-code tools and platforms available today.

### Low-Code vs Lines-of-Code

The low-code nature of Node-RED means it is easily accessible to a wide range of users. You don't need to be a seasoned software engineer to get started.

If you have a task to solve, and understand it well enough to break it into the right set of steps, translating that into a Node-RED flow can be much easier than having to write all of the corresponding code from scratch.

Just because you aren't writing code in Node-RED, it doesn't mean you shouldn't be able to benefit from ways of working that are proven to improve the end result - whilst keeping true to the low-code nature of the project.

### FlowFuse Cloud

Both `nrlint` and Node-RED Debugger are already pre-installed in all [FlowFuse Cloud](https://app.flowfuse.com){rel="&#x22;nofollow&#x22;"} hosted instances. You can start using them today via the sidebar menu.

![](https://flowfuse.com/blog/2024/02/images/node-red-sidebar.png)


# Storing Data: Getting Started with Node-RED

It's quite straightforward to pass plenty of useful data with each message (msg) in your flows. Not only can you store information in msg.payload, but you can also place information in any other named object, for instance, msg.store.

In this article, we will explore some of the better solutions for storing and retrieving transactional information in your flows.

#### Storing data outside of msg.payload

In this example, we have data in msg.payload as well as in msg.later.

:video{ariaLabel="Storing data outside of msg.payload" autoPlay="true" height="362" loop="true" muted="true" playsInline="true" preload="none" width="1040"}

If you want your debug to display the full content of the message, change the output to 'complete message object' as shown above.

You can import the flow using this code.

::render-flow
```json
[{"id":"aaa1e17e5f158004","type":"inject","z":"67746003c844dbc4","name":"Inject the message","props":[{"p":"payload"},{"p":"later","v":"A string I want to be able to use later in my flow","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"Hello World","payloadType":"str","x":690,"y":140,"wires":[["bce1bf09736125b7"]]},{"id":"bce1bf09736125b7","type":"debug","z":"67746003c844dbc4","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":880,"y":140,"wires":[]}]
```
::

Storing data outside of msg.payload can be very useful when you need access to that data later in your flow. You may notice that many nodes overwrite the content of msg.payload, so putting your data elsewhere is essential otherwise, it will be overwritten and lost.

#### Tidying your messages

You may also want to remove data you don't need from your messages to optimize the speed of your flows.

It's easy enough to remove data you don't need, wherever it sits within your messages using the Change Node. In this example, we are going to delete the content of msg.other while leaving the rest of the message to be passed to the next Node.

:video{ariaLabel="Deleting data from msg.other" autoPlay="true" height="344" loop="true" muted="true" playsInline="true" preload="none" width="1136"}

The Change Node is configured as follows.

![Change Node configuration](https://flowfuse.com/blog/2024/02/images/delete.png "Change Node configuration")

You can import the flow using this code.

::render-flow
```json
[{"id":"1ac51e71153f7c1f","type":"inject","z":"67746003c844dbc4","name":"Inject the message","props":[{"p":"payload"},{"p":"other","v":"We don't need this string anymore","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"Hello World","payloadType":"str","x":530,"y":100,"wires":[["5d3a978ad9eab443","cd7609101328caa2"]]},{"id":"5d3a978ad9eab443","type":"debug","z":"67746003c844dbc4","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":700,"y":60,"wires":[]},{"id":"cd7609101328caa2","type":"change","z":"67746003c844dbc4","name":"","rules":[{"t":"delete","p":"other","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":730,"y":100,"wires":[["be2f7f68dee570be"]]},{"id":"be2f7f68dee570be","type":"debug","z":"67746003c844dbc4","name":"debug 3","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":900,"y":100,"wires":[]}]
```
::

#### Storing data outside of msg.payload so you can access it later in your flows

Storing data outside of msg.payload allows you to access it later in your flows. In this example, we inject geographical coordinates and use an API to get the sunset time for each location. We can then output the result as a sentence.

As the HTTP Node, which we are using to interact with the weather API, overwrites msg.payload with the response, we will store the submitted city name and coordinates in msg.store for later use.

You can see the flow working below.

:video{ariaLabel="Example flow which gets the sunset time for a given location" autoPlay="true" height="448" loop="true" muted="true" playsInline="true" preload="none" width="1142"}

You can import the flow using this code.

::render-flow
```json
[{"id":"809cc8f4678767b7","type":"inject","z":"67746003c844dbc4","name":"London","props":[{"p":"payload.city","v":"London","vt":"str"},{"p":"payload.lat","v":"51.5072","vt":"str"},{"p":"payload.lng","v":"0.1276","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":170,"y":80,"wires":[["6b5a6a2ef7a64f1a"]]},{"id":"b86d2d558eebbd7e","type":"inject","z":"67746003c844dbc4","name":"Washington DC","props":[{"p":"payload.city","v":"Washington DC","vt":"str"},{"p":"payload.lat","v":"38.9072","vt":"str"},{"p":"payload.lng","v":"77.0369","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":140,"y":160,"wires":[["6b5a6a2ef7a64f1a"]]},{"id":"aaecc81a2de233d6","type":"debug","z":"67746003c844dbc4","name":"debug 4","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":820,"y":160,"wires":[]},{"id":"6b5a6a2ef7a64f1a","type":"change","z":"67746003c844dbc4","name":"","rules":[{"t":"set","p":"store","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":320,"y":120,"wires":[["273ee743f8d1a5f1","af43cea5866e11f5"]]},{"id":"273ee743f8d1a5f1","type":"template","z":"67746003c844dbc4","name":"create the URL","field":"url","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"https://api.sunrisesunset.io/json?lat={{store.lat}}&lng={{store.lng}}","output":"str","x":500,"y":120,"wires":[["52e8913233f379eb","1d94053c790791ee"]]},{"id":"af43cea5866e11f5","type":"debug","z":"67746003c844dbc4","name":"debug 5","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":480,"y":160,"wires":[]},{"id":"52e8913233f379eb","type":"http request","z":"67746003c844dbc4","name":"","method":"GET","ret":"obj","paytoqs":"ignore","url":"","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":670,"y":120,"wires":[["aaecc81a2de233d6","a245b322ade3a7e9"]]},{"id":"1d94053c790791ee","type":"debug","z":"67746003c844dbc4","name":"debug 6","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":660,"y":80,"wires":[]},{"id":"a245b322ade3a7e9","type":"template","z":"67746003c844dbc4","name":"Create the sentence","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"The sun will set at {{payload.results.sunset}} in {{store.city}}.","output":"str","x":860,"y":120,"wires":[["3e4b2d3644845f91"]]},{"id":"3e4b2d3644845f91","type":"debug","z":"67746003c844dbc4","name":"debug 7","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1040,"y":120,"wires":[]}]
```
::

Using this technique, we can build the content of message.store (or any other name you'd like to use) and then output the content at the end of a flow, even if you use msg.payload to interact with APIs and other custom nodes.

#### Why not store the values in context?

Where possible, it's more robust to store all the information related to a particular message within the message rather than saving it to context and retrieving it later. Using context risks a [race condition](https://en.wikipedia.org/wiki/Race_condition#:~\:text=A%20race%20condition%20or%20race,to%20unexpected%20or%20inconsistent%20results){rel="&#x22;nofollow&#x22;"} within your flow that could result in data corruption.

In this example, we simulate how a race condition can make context a bad choice for transactional data storage. The flow passes in the name and age of two people then moves the age to context. The flow then adds a random delay for each message so that, in some cases, the messages do not reach the debug in the order they were created. After the delay, the age is pulled back from context and added to each msg.payload.

:video{ariaLabel="Example of how a race condition can make context a bad place to cache data" autoPlay="true" height="356" loop="true" muted="true" playsInline="true" preload="none" width="1042"}

If there is a race condition in play, we should intermittently see Rob and John's stored ages being assigned to the wrong person. We can see in the image above that Rob is showing the incorrect age.

You can import the flow using this code.

::render-flow
```json
[{"id":"7ac4e7165d99f041","type":"inject","z":"67746003c844dbc4","name":"Rob","props":[{"p":"payload.name","v":"Rob","vt":"str"},{"p":"payload.age","v":"46","vt":"str"}],"repeat":"2","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":570,"y":840,"wires":[["1e0575bd662f9277"]]},{"id":"e9c0baba4f50b0b2","type":"inject","z":"67746003c844dbc4","name":"John","props":[{"p":"payload.name","v":"John","vt":"str"},{"p":"payload.age","v":"29","vt":"str"}],"repeat":"2","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":570,"y":880,"wires":[["1e0575bd662f9277"]]},{"id":"d5f688682206d316","type":"change","z":"67746003c844dbc4","name":"","rules":[{"t":"set","p":"age","pt":"flow","to":"payload.age","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":850,"y":860,"wires":[["d56225e59bde93cf"]]},{"id":"d56225e59bde93cf","type":"change","z":"67746003c844dbc4","name":"","rules":[{"t":"delete","p":"payload.age","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1050,"y":860,"wires":[["d5a119b311bf8377"]]},{"id":"e3ec11b4e038e564","type":"debug","z":"67746003c844dbc4","name":"debug 8","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1080,"y":940,"wires":[]},{"id":"d5a119b311bf8377","type":"delay","z":"67746003c844dbc4","name":"","pauseType":"random","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"0","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":720,"y":940,"wires":[["b329d7f2685d0ed6"]]},{"id":"b329d7f2685d0ed6","type":"change","z":"67746003c844dbc4","name":"","rules":[{"t":"set","p":"payload.age","pt":"msg","to":"age","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":940,"wires":[["e3ec11b4e038e564"]]},{"id":"1e0575bd662f9277","type":"delay","z":"67746003c844dbc4","name":"","pauseType":"random","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"0","randomLast":"1","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":700,"y":860,"wires":[["d5f688682206d316"]]}]
```
::

#### Conclusion

Storing transactional data in msg rather than context in Node-RED offers advantages in modularity, scalability, simplicity, and also helps prevent race conditions. By using msg, data transfer between nodes becomes more seamless, allowing for independent node reuse across flows without additional configuration. This approach ensures scalability by avoiding the imposition of large datasets on the global context. Moreover, storing data outside of msg.payload within the msg object enhances flexibility. It separates metadata and other relevant information from the main payload, promoting a cleaner and more organized structure. This practice not only aligns with Node-RED's visual programming paradigm but also improves code readability. Steering clear of context for transactional data, while also organizing it within the msg object, provides a comprehensive and reliable solution within the Node-RED framework.

Thanks to [SunriseSunset](https://sunrisesunset.io/){rel="&#x22;nofollow&#x22;"} for creating the useful API we've used in this article.


# Citizen Development: Unleashing Domain Experts

Citizen development has taken the spotlight recently, but the concept itself isn't entirely new. Remember the era of "hackers"? They weren't malicious actors, but individuals who tinkered with technology, pushing boundaries and creating solutions. Today, these same problem-solving personas have evolved into "[citizen developers](https://www.gartner.com/en/information-technology/glossary/citizen-developer){rel="&#x22;nofollow&#x22;"}" – business users empowered to build applications without relying solely on professional coders.

## Why Now?

While the drive for user-friendliness has always been present in programming languages, several factors have converged to push citizen development to the forefront:

- Democratization of Technology: Cloud computing and advancements in low-code/no-code platforms have lowered the barrier to entry, making development tools accessible to individuals with minimal technical expertise.
- Business Agility: The need for rapid innovation necessitates solutions that bypass lengthy IT backlogs. Citizen developers can bridge the gap, creating applications and internal tools quickly and efficiently.
- Domain Expertise: Business users possess deep insights into specific processes and challenges. By giving them the tools to build solutions, organizations can tap into a new knowledge source by putting domain experts into the driver's seat.

### Beyond Spreadsheets: Platforms of Empowerment

Reports and Dashboards are often created by a BI teams that have to take information from specialists to create custom visualizations that may or may not come out to be exactly what they asked for. Queue old faiful, spreadsheets, where a domain expert can create their own reports that suit their needs. Spreadsheets are powerful for analysis, but they often lack the real-time secure connectivity needed for enterprise applications. Transform the knowledge created in a spreadsheet into a personalized real-time visualization. To do that, you must first select a citizen development platform and those platforms should offer:

- Visual Interfaces: Drag-and-drop functionality and pre-built components eliminate the need for complex coding, allowing users to focus on logic and functionality.
- Integration Capabilities: Seamless connection with existing data sources and systems ensures that citizen-built applications integrate seamlessly into the overall workflow. Plus, the ability to create custom integrations.
- Governance and Security: IT governance establishes guardrails while empowering users, ensuring data security and application stability through features like Role Based Access Control and SSO integration.
- Collaboration Tools: Built-in collaboration features enable teams to share ideas, iterate on solutions, and ensure knowledge transfer.
- Reseliency: Backup management.

### Citizen Developers: Not Rube Goldberg Machines, But Value Creators

The key to successful citizen development lies in empowerment, not abdication. By providing the right tools, training, and governance, organizations can avoid creating complex, fragile solutions. Instead, citizen developers become powerful problem-solvers, building value-driven applications that address specific needs and contribute to overall business goals.

## Lean In

Remember, citizen development isn't about replacing professional developers. It's about creating a collaborative environment where everyone can contribute their unique skills and perspectives. By removing the coding barrier, we unleash a wider pool of innovators, accelerating progress and driving organizational success.


# Getting Started with Node-RED Dashboard 2.0

With our latest release of Node-RED Dashboard 2.0, we've made some big improvements to the onboarding experience.

We're seeing over 2,000 people download Dashboard 2.0 per week, and are seeing a great buzz in the community of brand new Node-RED users, experienced Node-RED users that haven't explored a UI solution previously and existing users migrating from Dashboard 1.0.

So, with that in mind, we wanted to offer a new "Getting Started" guide that will help you get up and running with building custom user interfaces and data visualizations in Node-RED.

## How to Install Node-RED Dashboard 2.0

### Step 1: "Manage Palette"

![Screenshot to show where to find the "Manage Palette" option in Node-RED](https://flowfuse.com/blog/2024/03/images/dashboard-getting-started-manage-palette.png){dataZoomable=""}

Screenshot to show where to find the "Manage Palette" option in Node-RED

1. Click the Node-RED Settings (top-right)
2. Click "Manage Palette"

### Step 2: Search & "Install"

![Screenshot to show where to find the "Install" tab, and how to find @flowfuse/node-red-dashboard](https://flowfuse.com/blog/2024/03/images/dashboard-getting-started-search-install.png){dataZoomable=""}

Screenshot to show where to find the "Install" tab, and how to find @flowfuse/node-red-dashboard

1. Switch to the "Install" tab
2. Search for &#x2A;"@flowfuse/node-red-dashboard"*
3. Click "Install"

## Adding your first widgets

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

With the nodes installed, getting started is as easy as choosing a node from the Palette (the left-hand side list of nodes) in Node-RED, and dropping it onto your canvas.

:video{ariaLabel="Screen recording to show how easy it is to deploy your first Dashboard 2.0 application." autoPlay="true" height="460" loop="true" muted="true" playsInline="true" preload="none" width="800"}

Screen recording to show how easy it is to deploy your first Dashboard 2.0 application.

In this case, we drop in a `ui-button`, click "Deploy" and then can see the button running live in our user interface.

Notice too that Dashboard will automatically setup some underlying configurations for you (visible in the right-side menu):

- `ui-base`: Each instance of Node-RED that uses Dashboard 2.0 must have a single `ui-base` element (we're hoping to add support for multiple in the future). This element contains all of the global settings for your Dashboard instance.
- `ui-page`: A single Dashboard (`ui-base`) can consist of multiple pages, and can be navigated to using the left-side sidebar. Each page is then responsible for displaying a collection of `ui-group` elements.
- `ui-group`: Each group contains a collection of widgets, and can be used to organize your Dashboard into logical sections.
- `ui-theme`: Each `ui-page` can be assigned a given theme. Your "Themes" provide control over the aesthetic of your Dashboard like color, padding and margins.

## Configuring your layout

Dashboard 2.0 adds a dedicated sidebar to Node-RED to provide a centralized view of your pages, groups and widgets. From here you can add new pages and groups, modify existing settings, and re-order content to your liking.

![Screenshot showing the Dashboard 2.0 sidebar in the Node-RED Editor.](https://flowfuse.com/blog/2024/03/images/dashboard-getting-started-sidebar.png){dataZoomable=""}

Screenshot showing the Dashboard 2.0 sidebar in the Node-RED Editor.

When defining your layout options, we break the choice into two sections:

- **Page Layout:** Controls how the `ui-groups`'s are presented on a given page in your application.
- **Navigation Sidebar:** Defines the left-side navigation style, defined at the `ui-base` level.

![Example of a "Grid" page layout, with "Collapsing" sidebar navigation.](https://flowfuse.com/blog/2024/03/images/dashboard-getting-started-layout.png){dataZoomable=""}

Example of the "Grid" page layout, with "Collapsing" sidebar navigation.

### Page Layout

Currently, we have three different options for page layout:

- **Grid:** ([docs](https://dashboard.flowfuse.com/layouts/types/grid.html){rel="&#x22;nofollow&#x22;"}) This is the default layout for a page, and uses a 12-column grid system to layout your `ui-groups`. Widths of groups and widgets define the number of columns they will render in. So, a "width" of 6" would render to 50% of the screen. Grid layouts are entirely responsive, and will adjust to the size of the screen.
- **Fixed:** ([docs](https://dashboard.flowfuse.com/layouts/types/fixed.html){rel="&#x22;nofollow&#x22;"}) Each component will render at a *fixed* width, no matter what the screen size is. The "width" property is converted a fixed pixel value (multiples of 48px by default).
- **Notebook:** ([docs](https://dashboard.flowfuse.com/layouts/types/notebook.html){rel="&#x22;nofollow&#x22;"}) This layout will stretch to 100% width, up to a maximum width of 1024px, and will centrally align. It's particularly useful for storytelling (e.g. articles/blogs) or analysis type user interfaces (e.g. Jupyter Notebooks), where you want the user to digest content in a particular order through scrolling.

### Navigation Sidebar

Dashboard 2.0 offers various options on the appearance of the navigation sidebar:

- **Collapsing:** When the sidebar is opened the page content will adjust with the width of the sidebar.
- **Fixed:** The full sidebar will always be visible, and the page content will adjust to the width of the sidebar.
- **Collapse to Icons:** When minimized, users can still navigate between pages by clicking on the icons representing each page in the sidebar.
- **Appear over Content:** When the sidebar is opened, the page is given an overlay, and the sidebar sits on top.
- **Always Hide:** The sidebar will never show, and navigation between pages can instead be driven by [`ui-control`](https://dashboard.flowfuse.com/nodes/widgets/ui-control.html){rel="&#x22;nofollow&#x22;"}.

### Define Your Layout

In our example, we're going to switch to a "Notebook" layout, with a "Collapse to Icons" sidebar:

![Example of the "Notebook" layout and "Collapse to icons" sidebar](https://flowfuse.com/blog/2024/03/images/dashboard-getting-started-example.png){dataZoomable=""}

Example of the "Notebook" layout, with "Collapse to Icons" sidebar navigation.

## Adding More Widgets

Now, we're going to build a quick example to demonstrate how we can wire nodes together, and visualize the output from a `ui-slider` onto a `ui-chart`.

### Adding a Group

In the Node-RED Editor's Dashboard 2.0 sidebar, we're going to then do the following things:

1. Edit "My Group" and rename it to "Controls"
2. Create a new "Group" in your existing page called "Data Visualization"

You'll now see the two groups listed under "Page 1". "Controls" with a single `ui-button` and "Data Visualization" with no widgets.

![Screenshot of the modified and newly added groups](https://flowfuse.com/blog/2024/03/images/dashboard-getting-started-new-group.png){dataZoomable=""}

Screenshot of the modified and newly added groups

### Connecting New Nodes

Then, we're going to add two new widgets:

- UI Chart
- UI Slider

Which we can do by dropping them from the left-side Palette and onto our canvas.

We'll need to double-click each new node and confirm which "Group" we want to add this node to. In this case, we'll add the `ui-slider` to the "Controls" group, and the `ui-chart` to the "Data Visualization" group.

We're also going to connect the output from both the `ui-slider` and `ui-button` to the input of the `ui-chart`:

![Screenshot of the Node-RED Editor, showing the ui-slider and ui-button connected to our ui-chart](https://flowfuse.com/blog/2024/03/images/dashboard-getting-started-flow.png){dataZoomable=""}

Screenshot of the Node-RED Editor, showing the ui-slider and ui-button connected to our ui-chart

Now, when we view our Dashboard, we can see the `ui-slider` output is def straight into our `ui-chart`:

![Screenshot of the Dashboard with all three widgets rendered](https://flowfuse.com/blog/2024/03/images/dashboard-getting-started-final.png){dataZoomable=""}

Screenshot of the Dashboard with all three widgets rendered

The final step we're going to make is to modify our `ui-button`. We're going to rename it to "Clear", and configure it's "Payload" option to send a JSON payload of `[]`, which, when sent to the `ui-chart` will clear the chart of all data.

![The ui-button configuration after setting it's payload and label](https://flowfuse.com/blog/2024/03/images/dashboard-getting-started-btn-config.png){dataZoomable=""}

The ui-button configuration after setting it's payload and label

With all of this together, we have the following functional Dashboard:

:video{ariaLabel="Short animation showing the final functional dashboard" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

Short animation showing the final functional dashboard.

## Next Steps

Whilst this is just a simple introduction of Node-RED Dashboard 2.0, we do have many other articles and documentation that can help you get started with more advanced features.

- [FlowFuse Dashboard Articles](https://flowfuse.com/blog/dashboard/) - Collection of examples and guides written by FlowFuse.
- [Node-RED Dashboard 2.0 Documentation](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"} - Detailed information for each of the nodes available in Dashboard 2.0, as well as useful guides on building custom nodes and widgets of your own.
- [Node-RED Forums - Dashboard 2.0](https://discourse.nodered.org/tag/dashboard-2){rel="&#x22;nofollow&#x22;"} - The Node-RED forums is a great place to ask questions, share your projects and get help from the community.
- [Beginner Guide to a Professional Node-RED](https://flowfuse.com/ebooks/beginner-guide-to-a-professional-nodered/) - A free guide to an enterprise-ready Node-RED. Learn all about Node-RED history, securing your flows and dashboard data visualization.
- [FlowFuse - Book a Demo](https://flowfuse.com/contact-us) - FlowFuse provides a complete platform to scale your production Node-RED applications, increase developer velocity, and enhance security in order to accelerate innovation.

## Follow our Progress

New features and improvements are coming to Node-RED Dashboard 2.0 every week, if you're interested in what we have lined up, or want to contribute yourself, then you can track the work we have lined up on our GitHub Projects:

- [Dashboard 2.0 Activity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}
- [Dashboard 2.0 Planning Board](https://github.com/orgs/FlowFuse/projects/15/views/4){rel="&#x22;nofollow&#x22;"}
- [Dashboard 1.0 Feature Parity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/5){rel="&#x22;nofollow&#x22;"}

If you have any feature requests, bugs/complaints or general feedback, please do reach out, and raise issues on our relevant [GitHub repository](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.


# FlowFuse and Gallarus Announce Strategic Partnership to Accelerate Industry 4.0 Adoption

FlowFuse, a leading provider of the low-code end-to-end development platform for industrial applications, and Gallarus Industry Solutions Limited, the leading industry 4.0 integrator in Europe dedicated to digital transformation through the deployment of the Unified Namespace (UNS) digital architecture, today announced an exciting strategic partnership. This collaboration aims to empower businesses with advanced solutions for Industry 4.0 transformation and optimized operational efficiency.

Powered by Node-RED, FlowFuse enables teams of all sizes to harness low-code capabilities to build robust applications with unparalleled scalability, and security. FlowFuse’s collaborative environment and scalable architecture ensure that teams can build securely and together for continuous development and operational success. Gallarus, with its extensive experience in digital transformation projects and industrial technology integration, will leverage its expertise in high-quality project implementation, support, and maintenance. Together, they offer a comprehensive solution for businesses seeking to digitally transform their operations.

“We are pleased to announce this strategic alliance with Gallarus,” said Zeger-Jan van de Weg, CEO at FlowFuse. “This partnership signifies a significant step forward in providing businesses with the tools they need to excel in the current digital landscape. By combining our expertise, we are confident in delivering exceptional value to our customers.”
“This partnership with FlowFuse perfectly aligns with our mission to empower businesses with transformative industry 4.0 solutions,” said Patrick Mc Carthy, COO at Gallarus Industry Solutions Limited. “FlowFuse's low-code development platform, combined with our expertise in UNS architecture and integration, will provide a powerful solution for organizations of all sizes to move away from an Industry 3.0 mentality and embrace Industry 4.0, streamlining operations to unlock new levels of efficiency not seen before.”

This combined expertise will address the complexities of digital transformation for businesses by:

- Facilitating data access, transformation, and visualization across any protocol.
- Breakdown data silos enabling organization-wide data availability via the UNS.
- Enable citizen developers to build extremely useful industrial applications.

For more information about FlowFuse and Gallarus Industry Solutions Limited, please visit their respective websites at [flowfuse.com](https://flowfuse.com) and [gis.ie.](http://gis.ie){rel="&#x22;nofollow&#x22;"}


# FlowFuse Open Source Tier Resource Limits

Today, with the latest FlowFuse release, an important change was made that
updates the resource limits for our open-source, self-managed FlowFuse server
tier. This change does not affect FlowFuse Cloud users in any way.

## New Open Source Tier Resource Limits

The new limit for the number of Node-RED runtimes on the Open Source tier is 5.
These 5 instances can be distributed across a maximum of 5 teams. This revised
structure allows for the development of your initial FlowFuse and Node-RED
solutions, providing a clear understanding of how FlowFuse can enhance your
organization's workflows. Upgrading to a Team or Enterprise tier license unlocks
the full potential of FlowFuse and grants access to our dedicated support team.

## Why the Change?

Here at FlowFuse, we're committed to providing a great experience for all our
users, including those utilizing our free, open-source tier. We
initially designed this tier to offer a platform for small organizations and
larger teams to explore FlowFuse's capabilities without needing our direct
involvement. However, we've observed instances where the Open Source tier's free
limits were being used to run very large deployments and even entire sites.

While support is a key benefit we offer to paying customers, we believe everyone
deserves a positive FlowFuse experience. As such, we're adjusting the resource
limits to better align with the Open Source tier's intended purpose and allow the
company to continue to invest in the Open Source tier.

## Transitioning Users

If you're currently impacted by these resource limit changes, we want to ensure
a smooth transition. We're offering a complimentary 1-year Enterprise license to
affected users. To claim your license, simply email <support@flowfuse.com> with
the IP address your server has used to send telemetry data (if available) and a
screenshot of your admin panel so we can match the currently usage with the new
license.

We appreciate your understanding and continued support. If you have any
questions regarding this update, please don't hesitate to reach out to our team
at <support@flowfuse.com>.


# Securing HTTP Traffic for Node-RED with FlowFuse

Citizen development empowers employees to create digital solutions. However, it requires guardrails to ensure data security, operational stability, and compliance. These guardrails are what FlowFuse provides to the Node-RED community to level up their deployments. FlowFuse offers many different security measures for authentication and authorization, which all apply to different scenarios.

In this post we’ll take a look at most of them, specifically for HTTP traffic. We’ll discuss the trade-offs for auditabliltiy, convenience to use as either machine or human, among other factors.

## HTTP Basic Authentication: A Simple Approach

HTTP Basic Authentication is widely supported and straightforward to implement, making it a popular choice for securing APIs. It requires users to provide a username and password before accessing the Node-RED instance. While this method is easy to use, it's important to note that the username and password are shared and transmitted in plain text, making it vulnerable to interception if the connection doesn't leverage SSL/TLS. FlowFuse by default ensures SSL/TLS is deployed.

## Personal access tokens: Knowing who accessed the Node-RED

Personal access tokens (PATs) are an essential component of FlowFuse, allowing users to securely access their accounts without sharing their passwords. These tokens are generated by the user and can be used to authenticate to the SaaS product's API or other services. PATs provide a more secure alternative to traditional username/password authentication, as they can be revoked or regenerated at any time, limiting the potential impact of a compromised token.

## FlowFuse Authentication: Seamless Integration

FlowFuse authentication offers a seamless and secure way for users to access dashboards and other resources that are typically accessed through a browser. It leverages single sign-on (SSO) and SAML 2.0, reducing the management burden for organizations.

For users this is convenient as they can access multiple applications and resources using a single set of credentials, eliminating the need to remember and manage multiple passwords.

For organizations, SSO enhances security by centralizing authentication and authorization, reducing the risk of unauthorized access. By leveraging SSO and SAML 2.0, FlowFuse takes care of user management, freeing up customers from the administrative burden of managing user accounts and passwords. FlowFuse authentication adheres to industry-standard security protocols, ensuring compliance with regulatory requirements.

This method of authentication is however impractical for API access by other services, to programmatically transfer data between them.

## Bearer Authentication: A Token-Based Approach

Bearer Authentication offers a more secure and flexible alternative to traditional username/password authentication. Users will generate the token through the FlowFuse platform with each instance generating its own token. These tokens can be designed to have limited lifespans, reducing the risk if compromised. In the case the token then becomes compromised only the instance in which the token is generated can become subject to malicious behaviors. In the case that this does occur, simply deleting the token will elevate any unwanted access.

Compared to FlowFuse Authentication, this method is very well suited for API access and programmatic access to FlowFuse.

## Choosing the Right Authentication Strategy

FlowFuse provides multiple authentication mechanisms to cater to various aspects of security and user experience. When designing your Node-RED applications, consider the specific requirements of your project and the patterns of user interaction to select the most appropriate authentication strategy. By doing so, you can ensure both a high level of security and an optimal user experience for your web development projects with API calls through Node-RED.

In conclusion, understanding and utilizing these different types of authentication in FlowFuse empowers citizen developers like you to create more secure and efficient applications for diverse use cases.


# Installing and operating Node-RED behind a firewall

Practitioners using Node-RED often find themselves in a situation where a firewall
is deployed in their organization. This network configuration is a fact of life and is generally not controlled by the same people using Node-RED. Given security reigns supreme in Industrial IoT (IIoT), and a firewall offers a lot of benefits, we anticipate it will be deployed more often in the future, and as such it’s good to understand how you can get the most out of Node-RED when deployed behind a firewall.

## Node-RED installation with a firewall

Generally, the standard install procedure for Node-RED requires a connection to the NPM servers that host the package. Due to NPM’s unaudited nature, IT is unlikely to agree to a permanent exception to the firewall to allow access to it. However, there are a couple of actions one can take to install Node-RED anyway.

First, ask for a temporary exception. Node-RED is installed in a few minutes, so if there’s a set time schedule an exception can be made there’s a regular method available again through collaboration with the network administrator. The second option is leveraging vendor specific package managers. As these are vetted repositories, it’s not uncommon that these gates in the firewall have been created and opened to you. Some vendors supply repositories for major package managers like `apt-get` on Debian/Ubuntu-based systems, or there’s a marketplace approach to install Node-RED like for example the [Rexroth CtrlX with Node-RED in it](https://developer.community.boschrexroth.com/t5/Store-and-How-to/FlowFuse-Node-RED/ba-p/82135){rel="&#x22;nofollow&#x22;"}. Lastly, you could consider downloading the NPM package beforehand and transferring it to your machine within the network. NPM allows the installation of local packages, which in turn allows you to create applications with Node-RED. This is generally a shadow IT action, and not recommended unless it’s approved.

## FlowFuse and your firewall

As FlowFuse can be installed in a VPN behind a firewall, there’s no requirement to open up a ‘gate’ in your firewall to FlowFuse servers. The safe perimeter provided remains to the outside world. The security aspect remains, though as a Node-RED developer, there are still everyday tasks you’ll need access to the outside world.

Consider installing third party nodes to connect your Node-RED instance to virtually any protocol or digital service. There are over 5000 of these nodes available, and as an organization it’s challenging to keep on top of. Your firewall provides one layer of security so that the data you’re accessing remains safe. FlowFuse provides a second layer of protection; we’ve introduced a [“Certified Nodes” catalog](https://flowfuse.com/integrations/?certified=1). These nodes have gone through automated and manual inspection to prevent malicious code from making it onto your production systems.

Installing these packages would typically still require you to obtain files from NPM. With FlowFuse however, a cache can be built with only vetted nodes – All other nodes remain unavailable.

Once Node-RED is installed and the initial development has been completed, FlowFuse aims to reduce the maintenance burden on both IT and OT teams too. In the same package cache aforementioned, Node-RED versions can be added. Updating Node-RED to the latest version becomes a job of just a few clicks. Updating your Node-RED instances, even behind a firewall, is imperative, as virtually all breaches are the result of daisy-chaining multiple security vulnerabilities into a high to critical event.

## Wrap up

FlowFuse founding engineers have decades of experience running Node-RED wherever it is valuable. Our product is the culmination of that, and we’re excited to help you become successful in your digitalization efforts – even when a firewall is in play.


# Looking towards Node-RED 4.0 and beyond

With Node-RED 4.0 coming soon, I wanted to take a look at what users can expect to see with the new release,
as well as some of the new features we're working on.

The Node-RED project [schedules its releases](https://nodered.org/about/releases/){rel="&#x22;nofollow&#x22;"} around a yearly major release that coincides with when a Node.js version
reaches its end-of-support. This lets us drop support for that node.js version and update the default version of node used
in the docker containers we publish. We treat this as a major change because it might require actions on the end-users part to update any additional modules they have installed.

With Node-RED 4.0, we will be dropping support for anything earlier than Node 18 - with Node 20 the currently recommended version to use. That will give users almost 2 full years before needing to consider another Node.js upgrade.

Now, talking about Node.js versions is not that exciting. What is more exciting is to look at what new features are coming to Node-RED.

There are a few things already merged and ready to be released in the first beta release, and more landing each week.

### More auto-complete

Node-RED already has simple auto-complete on `msg` fields in the editor. We've now extended that to also work with `flow`/`global` context inputs as well as the `env` type for accessing environment variables.

![Node-RED editor autocompleting properties](https://flowfuse.com/blog/2024/03/images/nr4-auto-complete.png "Node-RED editor autocompleting properties")

This makes it so much easier to work with these types of properties - being sure you're using something that exists rather than having to switch between different views in the editor to get the names right.

In the case of env vars, it also shows you where the value was set - useful when you have nested groups and subflows which might be overriding a particular value.

The `msg` auto-complete is still based on a built-in list of common message properties used by the core nodes. There is interest in enabling this to pull completions from 'live' messages seen by the node in question - but that's not currently in the plan for 4.0.

### Timestamp formatting

The Inject node has provided the ability to inject a timestamp since the very early days of Node-RED. The value it actually sets is the number of milliseconds since epoch (aka January 1st, 1970). If you're used to working with JavaScript, then this is a perfectly normal way to pass times around. However, it isn't always what is needed and flows end up using a Function node to reformat it in some way.

With 4.0 we've added options to pick what format the timestamp is generated in at the start. Now, formatting times and dates can be a big can of worms of options. So, for this initial release, we've kept it simple by offering three options:

!["Format options for Node-RED timestamp"](https://flowfuse.com/blog/2024/03/images/nr4-timestamp-formatting.png "Format options for Node-RED timestamp")

- *milliseconds since epoch* - the existing option, just more explicitly labelled for what it is
- *YYYY-MM-DDTHH\:mm\:ss.sssZ* - also known as ISO 8601
- *JavaScript Date Object* - the standard Date object

There is scope to allow custom format strings to be set in the node - but we'll see what the feedback is on these new options first.

### A better CSV node

The CSV node has had a big overhaul to make it more standards compliant. It turns out CSV has a whole bunch of tricky edge cases that most users don't hit - but if you did hit them you would be stuck.

The new node follows the [RFC4180](https://www.ietf.org/rfc/rfc4180.txt){rel="&#x22;nofollow&#x22;"} standard and is also faster - wins all around.

For those flows that rely on some of the non-standard edge case behaviour of the existing node, we've kept a legacy mode in place to keep those flows working.

### Customising config nodes in Subflows

This one needs a bit of explaining. Subflows are a way Node-RED lets you create a flow and add multiple reusable instances of it within your flows. For example, a subflow may connect to an MQTT broker and do some standard processing on the messages it received before sending them on. The Subflow can then expose a set of properties that can be customised for each instance. In our example, that could be the topic the MQTT node subscribes to.

However, in that example, the MQTT node's broker configuration would be locked to the same broker config node in every instance - and that's something we're solving in Node-RED 4.0.

We're making it possible to expose the choice of a configuration node in the Subflow properties - so each instance can be customised even further.

Another common use for this will be with Node-RED Dashboard - which uses config nodes to set the location of a widget. With Node-RED today, you cannot really use dashboard nodes inside subflows as you end up with multiple copies of the widgets all packed into the same group. With this update, you'll be able to configure the subflow instance with exactly what dashboard group to place its contents into.

### Updated JSONata

The JSONata library is used to provide the `expression` types in Node-RED - a really powerful way of working with JSON objects. With this release we've updated to the new major release of JSONata that comes with a bunch of performance improvements.

### And many more minor changes

I'll hold off listing them all out here, but there are plenty of other smaller changes scattered through the editor and the core nodes. Be sure to check the beta release notes when it arrives to see what else has been done.

## Looking further ahead

Whilst all of these are great incremental improvements to Node-RED, there are some bigger items we're looking at that will really improve the overall Node-RED experience.

I wrote recently about improving how users can [test their flows](https://flowfuse.com/blog/2024/02/software-development-in-node-red/#testing). This remains something I think we really help make Node-RED stand apart from other low-code solutions. It won't be in the imminent 4.0 release, but it is definitely still on the roadmap for a future release.

### Concurrent editing

Another area we want to improve is the collaboration experience within Node-RED. Working on flows as a team is a key feature of FlowFuse, and we want to make it even easier to do.

One of the common complaints is how Node-RED currently handles multiple users editing flows at the same time. Whilst it's better than it used to be, it still makes for a very jarring experience when you have to keep merging other users' changes into your own.

Our goal is to make collaboration as simple and natural as possible.

There are a wide range of approaches we could take here. For example, a small improvement would be to merge other users' changes in the background without interrupting what you're doing. But I think we do better than that.

What if the editing experience was more like Google Docs - knowing that other users have the editor open, and being able to see their changes in real time. This would make for a truely collaborative editing experience.

There are some difficult problems to solve before we can get there, but I think this will be one of the more transformational changes to Node-RED we've had for some time.

## Beta releases

The [release plan](https://nodered.org/about/releases/){rel="&#x22;nofollow&#x22;"} has Node-RED 4.0 coming around the end of April. As mentioned, we'll be doing a series of beta releases between now and then to start getting early feedback from the community.

Keep an eye on the [community forum](https://discourse.nodered.org/c/news/9){rel="&#x22;nofollow&#x22;"} for release announcements as they come.


# Why Low-Code is Better

There are two common reasons why new languages come about. They provide a feature missing in the existing programming languages, or it is a tool that is easier to learn and use. The latter often functions like a swiss army knife with each iteration including more and more tools. The journey of low-code is like a swiss army knife, the perfect tool for the Citizen Developer.

## A Typical Coding Evolution

Every decade seems to introduce something that simplifies coding. For me, in college, it was Python. A classmate was excited about this new programming language that was all about simplicity and readability, especially with its indentation-based syntax. It seemed too simple at first. Yet, over time, Python became a staple in my programming toolbox.

During this time in our education, our coursework was filled with languages like C++, which felt distant from the future of programming we imagined. We joked about "outdated" languages, not yet realizing the breadth of what programming could encompass.

After finishing college in 2010, I started working during the tail end of the housing crisis in the U.S. My first role was as a Controls System Integrator at Logical System Inc., where I was introduced to programming PLCs with Ladder Logic. Despite my initial reservations, viewing it as barely a programming language, this experience was my first step towards appreciating the diversity and utility of programming languages beyond the conventional.

Later on in my career, I worked as a Corporate Automation and Controls Engineer where I worked on and enforced standards for partner System Integrators and OEMs. One of these important standards was making sure applications written in the control process were written in Ladder Logic within the PLCs. There were exceptions, of course, but the rule was to apply a visually appealing coding language, Ladder Logic, over a text-like language often called Structured Text.

## Programming Languages as Specialized Tools

Programming languages are typically optimized for certain tasks. For instance, Matlab and R excel in complex numerical computations thanks to their extensive libraries designed specifically for mathematical operations. While Python might not replace Matlab or R for their core functionalities, it can broaden the applicability of numerical analyses into various other contexts. In another example, VB.net is the go-to for standalone applications in Windows environments. However, for applications that need to run across different operating systems (excluding web applications), Java might be a better choice due to its platform independence. Each programming language has its niche, along with inherent complexities and constraints.

There are situations, however, where the specific strengths of a programming language become less critical. In cases where the application is straightforward, the choice of language might simply come down to personal preference or familiarity. But an important consideration arises when thinking about the future of the project: "Will someone else need to edit or view this code later?" If the answer is yes, and especially if the project aims to involve citizen developers, opting for a low-code solution becomes highly advantageous. Low-code platforms are designed with accessibility in mind, making them ideal for projects that benefit from collaboration and ease of maintenance.

## The Purpose of Citizen Development

The idea behind Citizen Development is simple, make programming accessible to more people. This is what low-code platforms aim to do. They lower the entry barrier, making programming more inclusive. Insisting on complex, traditional programming languages when there are simpler, equally powerful alternatives seems counterproductive. We should be looking towards making programming more accessible to everyone.

If we want to drive meaningful change within our organizations, embracing tools that broaden participation is key. The aim of adopting new standards and tools is to simplify, not complicate. It's about finding better, more accessible ways to work that can accommodate a wider range of skill sets.

## Simplification

This discussion isn't about the mechanics of coding, it's about opening up the field to more diverse contributions. Low-code platforms represent a step towards a more inclusive, collaborative future in technology. By lowering barriers to entry, we're not just simplifying coding, we're inviting a broader community to engage, innovate, and drive progress. I look forward to seeing how we can all contribute to this evolving landscape.

## How FlowFuse Helps

Our goal here at FlowFuse is to keep expanding on the Swiss army knife, Node-RED. We strive to elevate Node-RED for professionals by providing the tools needed to deploy Node-RED in a safe and secure way. For example by default, the editor for Node-RED is protected using your FlowFuse user credentials. You can also use SSO to further protect your user accounts and give access to Node-RED to your team members. All traffic to FlowFuse and your Node-RED instances is protected by HTTPS. FlowFuse has set up the domain name and manages the certificates so you can spend time on your flows rather than configuring security.

We believe that Low-Code is the future and strive to make Citizen Development a reality. To learn more [schedule a call with one of our experts.](https://flowfuse.com/free-consultation/)


# Scaling Node-RED with FlowFuse: Differences between a FlowFuse Instance and a Device Instance

FlowFuse is a Software as a Service (SaaS) platform designed to enhance the experience and capabilities of Node-RED for its users. By focusing on scalability, security, and Dev Ops, FlowFuse aims to remove some of the technical barriers associated with using Node-RED, making it easier for citizen developers to automate tasks, process data, and create applications. In this blog post, we will discuss the differences between a FlowFuse instance and a FlowFuse device instance while highlighting how FlowFuse addresses scalability challenges in Node-RED deployments.

## Scalability Challenges with Traditional Node-RED Deployments

While deploying Node-RED is quite simple, managing multiple instances across different environments can become complex and time-consuming. As the number of devices and use cases grow, users face difficulties in scaling their Node-RED applications efficiently to handle increased load without compromising performance or security. This is where FlowFuse comes into play.

## The Role of FlowFuse as an Orchestration Tool

FlowFuse functions as an orchestration tool that allows the deployment and management of all your Node-RED instances at scale, addressing scalability challenges head-on. By leveraging its platform, users can quickly deploy and manage multiple Node-RED instances while ensuring optimal performance and security. This enables them to connect with a wide range of devices, from PLCs and sensors to legacy software, without worrying about the complexities of managing their Node-RED deployment.

## Deploying Node-RED Next to Devices

One common issue in IoT deployments is that device instances of Node-RED often communicate with unsecure devices or networks. To mitigate security risks and ensure data protection, it's common to deploy Node-RED in close proximity to these devices. The FlowFuse platform uses [device agents](https://flowfuse.com/platform/device-agent/) that communicate back to the platform via a reverse tunnel over port 443. This setup requires only one firewall rule: allowing outbound connections from the [device agent](https://flowfuse.com/platform/device-agent/) running Node-RED to the FlowFuse platform, significantly minimizing security risks while enabling remote monitoring, flow editing, and configuration deployment at scale.

## Deploying Node-RED Instances Within the FlowFuse Platform

Not all instances of Node-RED need to be deployed at the edge and can be deployed anywhere. FlowFuse offers this flexibility in cases where users prefer or require deploying their Node-RED instances within the platform itself. This capability allows users to focus on developing and managing their applications without worrying about the underlying infrastructure.

## Conclusion

FlowFuse addresses scalability challenges in Node-RED deployments by providing an easy-to-use platform that enables users to manage multiple instances at scale while maintaining security and performance. By understanding the differences between a FlowFuse instance and a device instance, you can make informed decisions about your deployment strategy and leverage the full potential of Node-RED for your applications. Stay tuned for our upcoming blogs where we will dive deeper into the areas of security, dev ops, and backup solutions provided by FlowFuse.

[Walter took this exact path, growing from a single Node-RED instance to more than 130 across its global production network without adding headcount to its IT team](https://flowfuse.com/customer-stories/scaling-industrial-iot-operations-while-maintaining-competitive-edge/), using FlowFuse device agents to manage that scale.


# How Kafka is applied in manufacturing

Have you ever wondered how manufacturing and automotive industries can effectively manage the vast amount of real-time data generated by sensors and systems throughout the production process? A few years back, these industries faced major obstacles in handling the large volume of real-time data produced by sensors placed across the production line. Even today many industries continue to grapple with similar challenges. Traditional data management systems struggle to process and analyze this data in real-time, leading to inefficiencies in operational activities and decision-making. To address these challenges, various manufacturing and automobile plants have embraced technologies like Apache Kafka.

Kafka provides a distributed streaming platform that enables the efficient handling of real-time data streams. By leveraging Kafka, we can aggregate, process, and analyze data in real-time seamlessly. This guide provides a high-level overview of Kafka, covering its definition, components, functionality, applications, and limitations.

## What is Kafka?

Apache Kafka is a platform for distributed data streaming that allows for the publishing, subscribing, storing, and processing of streams of records in real-time. It is intended to handle data streams from multiple sources and to deliver them to multiple consumers. In essence, it can move large quantities of data in real-time from any source to any destination, simultaneously.

Kafka is also a very good [broker for UNS architecture](https://flowfuse.com/blog/2024/01/unified-namespace-what-broker/).

## Understanding Kafka's Architecture

Kafka architecture is designed to provide a scalable and fault-tolerant platform for handling real-time data streams. The architecture consists of several key components, each component serves a specific purpose in the data processing pipeline. In this section, we will take an overview of Kafka's architecture and its key components.

!["Architecture of Kafka"](https://flowfuse.com/blog/2024/03/images/using-kafka-in-manufacturing-kafka-architecture.png "Architecture of Kafka"){dataZoomable=""}

**1. Topics and Partitions**

- Topics: Imagine topics as folders for organizing data – they act as distinct categories. Kafka arranges information into these topics for systematic storage.
- Partitions: Think of partitions as subdivisions within topics. They enable parallel processing across multiple servers, enhancing fault tolerance and throughput.

**2. Producers:**

- Producers: Producers are like architects of data flow. They decide where to send records within a topic. This decision can be balanced using a round-robin or directed by a record key for specific purposes, such as maintaining order.

**3. Brokers:**

- Definition: Brokers are the backbone servers in a Kafka cluster.
- Tasks: Brokers store data, handle requests from both producers and consumers, and maintain the integrity and persistence of data. They also manage the critical task of tracking offsets, which determine the position of consumers within partitions.

**4. Consumers and Consumer Groups:**

- Consumers: These entities read data from brokers. They subscribe to one or more topics and pull data from the specific partitions they are interested in.
- Consumer Groups: Consumers collaborate in groups to scale data processing. Kafka dynamically assigns each consumer in a group a set of partitions from the subscribed topics, ensuring that each partition is processed by only one consumer within the group.

**5. Offsets**

- Definition: Offsets act as unique identifiers for records within a partition. They denote the position of a consumer in the partition.
- Function: As consumers read records, they increment their offset. This allows them to resume processing from where they left off, which is crucial for handling failures or restarts. Kafka stores offset information in a specialized topic for easy recovery.

**6. Replication**

- Mechanism: Kafka ensures data durability by replicating partitions across multiple brokers.
- Replication Factor: This configurable setting determines the number of copies of a partition in the cluster. If one broker fails, another can seamlessly take over, guaranteeing high availability.

## Features of Kafka

Now that we've gained a foundational understanding of Kafka, let's explore the key features that make it a preferred choice for many organizations. These features highlight why Kafka transcends being just another data processing tool and why it merits consideration for various use cases.

- **High Throughput and Scalability:** Kafka can handle thousands of messages per second and can scale horizontally and vertically to meet growing data demands without compromising performance.
- **Fault Tolerance and Reliability:** Built to ensure reliability, Kafka guarantees fault tolerance through replication, safeguarding data against loss in the event of a broker failure. Data redundancy ensures data safety even during hardware failures.
- **Real-Time Processing and Low Latency:** Kafka's real-time processing ensures low latency for instant data analysis, which is critical for real-time decision-making.

## Applications of Kafka

As we explore the capabilities of Kafka, we realize that it goes beyond being just a regular data processing tool. Kafka is a strategic powerhouse that influences decision-making, operational efficiency, and overall effectiveness in various industries. In this section, we will discuss specific, practical applications of Kafka in different industries, demonstrating how its adaptability can solve unique challenges.

**1. Manufacturing Operations Optimization:**

- Real-time Production Monitoring: Kafka is used in manufacturing for continuous monitoring of production lines, equipment status, and inventory levels. This real-time visibility aids in optimizing production efficiency, reducing downtime, and enhancing overall supply chain management.
- Quality Assurance and Yield Management: Companies utilize Kafka to monitor quality control metrics in real-time, enabling proactive measures to maintain product quality standards, minimize defects, and optimize production yield.

**2. Predictive Maintenance:** Organizations use Kafka to collect and analyze sensor data from machinery and equipment to predict potential failures. This helps them optimize scheduled maintenance tasks to prevent costly downtime and disruptions

**3. Supply Chain Management:** Kafka provides real-time visibility into supply chain operations. This enables companies to track shipments, monitor inventory levels, and coordinate with suppliers and distributors for efficient supply chain management.

**4. Logistics and Transportation:** Companies use Kafka to track vehicle and shipment locations in real-time, optimizing routes through the processing of streams of GPS data.

**5. Telecommunications:** Telecom operators utilize Kafka to monitor network performance metrics in real-time. This allows swift responses to outages or service degradations, ensuring a seamless communication network.

**6. Financial Services:** Banks leverage Kafka to process transactions in real-time, enabling immediate fraud detection by analyzing patterns in transaction data as they occur. This enhances overall security and compliance in financial operations.

## Challenges and Considerations

As beneficial as Kafka is in various industries, it also presents certain limitations and challenges that must be considered before deciding to use Kafka for your applications.

1. Performance: Kafka both receives and transmits data. When the flow of data is compressed or decompressed, the performance is affected. For example, if the data is decompressed it will eventually drain the node memory. As a result, it affects both throughput and performance.
2. Complexity: As we all know Kafka is an excellent platform for streamlining messages. However, in the case of migration projects that transform data, Apache Kafka gets more complex. Hence, to interact with both data producers and consumers you need to create data pipelines.
3. Tool Support: There is always a concern for startup companies to use Kafka over other options. Especially, if it remains in the long run. This is because a full set of management and monitoring tools are absent in Kafka.
4. Message Tweaking: Kafka uses system calls before delivering a message. Therefore, the messages are sensitive to modifications. Tweaking messages reduces the performance of Kafka to a greater extent. The performance is not impacted only under the condition of not changing the message.
5. Data Storage: Apache Kafka is not a recommended option for storing large sets of data. If the data is stored for a long period, the redundant copies of it are also stored. When this happens, the app must be ready to compromise its performance. For this reason, only use Kafka if there is a need to store data for a short period.

Additionally, if you are interested in learning more about Kafka and its practical implementation, refer to our guide on Using [Kafka with Node-RED](https://flowfuse.com/blog/2024/03/using-kafka-with-node-red/).

## Conclusion

This guide provides a high-level overview of Apache Kafka, including its definition, architecture, features, and applications in various industries and the challenges or limitations of using Kafka. Kafka's versatility in real-time data processing, decision-making, and operational efficiency is highlighted, with applications ranging from manufacturing to finance. The overview aims to provide a clear understanding of Kafka's role in handling data challenges and fostering innovation across sectors.


# Using Kafka with Node-RED

Kafka is one of the most powerful technologies enabling seamless data communication. Many individuals are utilizing it alongside Node-RED for real-time data exchange in their IoT and IIoT applications. However, some users are encountering difficulties in obtaining assistance with Kafka-related queries.

During my recent visit to the Node-RED Forum, I noticed that while some Kafka-related queries have been answered nicely, others remain unanswered or have not been satisfactorily addressed, leaving users feeling stuck. To address this issue, we've created a comprehensive Kafka guide covering everything you need to know about Kafka, from installation and connection to data transmission. For newcomers to Kafka, we recommend reading our previous blog on [how Kafka is applied in manufacturing](https://flowfuse.com/blog/2024/03/using-kafka-in-manufacturing/), where we've covered the basics and practical applications extensively.

## Discussing problem and potential solution

Let's start by discussing a problem: imagine a temperature sensor network across a city. We need to centralize and analyze this data in real time for effective monitoring and visualization.

To resolve this problem we will use Kafka, Temperature sensors will feed data into Kafka through the Kafka producer. To retrieve real-time data for visualization and monitoring, we’ll be using Kafka Consumer. We will organize the data by region. The temperature data for each region will be managed in a specific Kafka topic partition.

While in this guide, we will generate simulated data using random number expression and run both producers and consumers on the same system, practical scenarios often involve distributed setups across different devices or systems.

## Installing and running Kafka locally

In this part, we’ll be installing Kafka locally using Docker to simplify the installation process, so make sure you’ve got Docker installed before you dive in.

1. Pull the zookeeper image if it is not already, and run the zookeeper container.

```text
docker run -p 2181:2181 zookeeper
```

2. Pull the Kafka image if it is not already, and run Kafka Container, expose PORT 9092.

```text
docker run -p 9092:9092 `
-e KAFKA_ZOOKEEPER_CONNECT=<Your_Private_Ip>.1:2181 `
-e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://<Your_Private_Ip>:9092 `
-e KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR=1 `
confluentinc/cp-kafka
```

:cta-image{alt="Power Workplace relies on FlowFuse for scalability, reliability and security audits - book a demo" cta="demo" src="https://flowfuse.com/images/cta/power-workplace-book-demo.png"}

## Running Kafka on the cloud

To run Kafka on the cloud, you can consider utilizing any cloud service according to your preferences. For a guide on running Kafka on a cloud platform, the procedures may differ. You can refer to the documentation provided by your preferred cloud service for detailed instructions.

During the writing of this tutorial, I utilized [Aiven’s cloud data platform](https://aiven.io/kafka-connect){rel="&#x22;nofollow&#x22;"} which offers the option to use Kafka in the free trial. However, you are free to choose any cloud service that suits your requirements and preferences.

## Installing Dashboard 2.0

We will be installing Dashboard 2.0 to display real-time temperature data of various regions on a chart. If you are new to Dashboard 2.0, we recommend referring to [Getting started with Dashboard 2.0](https://flowfuse.com/blog/2024/03/dashboard-getting-started/), which covers everything from basic concepts to installation and creating your first dashboard seamlessly.

## Installing and configuring Kafka custom node

1. Install `node-red-kafka-manager` by the palette manager.
2. Before connecting to Kafka, ensure you have the following information ready and environment variables set up as discussed below in the Adding environment variable section.

- Host: The IP address or hostname of your Kafka broker server.
- Port: Kafka typically uses port 9092 by default. Ensure this aligns with your Kafka broker's configuration.
- SSL Configuration (if applicable):
  CA Certificate: The Certificate Authority (CA) certificate for validating the SSL connection.
- SASL (Simple Authentication and Security Layer) Mechanism: Most of the Kafka broker servers use SASL for authentication such as 'PLAIN', 'SCRAM-SHA-256,' or 'SCRAM-SHA-512.'
- Username: SASL username of Kafka broker server for authentication.
- Password: SASL password of Kafka broker server for authentication.

3. Drag the Kafka Producer node onto the Canvas, click on that node, and click on the edit icon next to the broker input field to configure it.

!["Screenshot showing configuration of kafka"](https://flowfuse.com/blog/2024/03/images/using-kafka-with-node-red-kafka-configuration.png "Screenshot showing configuration of kafka")

4. Enable the TLS option if your Kafka broker server is using it for secure communication.
5. After enabling the TLS option click on the edit icon next to `add new tls-config` and upload the CA Certificate in PEM format.

!["Screenshot showing TLS configuration for kafka"](https://flowfuse.com/blog/2024/03/images/using-kafka-with-node-red-tls-configuration.png "Configuring tls for kafka")

## Adding Environment variables

In this section, we will be setting up environment variables for Kafka configuration. If you have read our previous blog post, you may already know why we highly suggest using environment variables for every configuration. If not, please refer to our blog post on [Using Environment Variables in Node-RED](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/) for more information.

!["Screenshot showing adding environment variable in Node-RED"](https://flowfuse.com/blog/2024/03/images/using-kafka-with-node-red-setting-environment-variables.png "Screenshot showing adding environment variable in Node-RED")

1. Navigate to the instance's setting and then go to the environment section.
2. Click on the `add variable` button and add variables ( host, port, username, and password) for the configuration data that we discussed in the above section. To leverage the ease of configuration provided by the Kafka custom node that we are utilizing, ensure to set only one variable for both host and port in the following format:

```text
[{"host":<enter IP address or hostname of your Kafka broker server >,"port":<enter port on which your kafka broker server is listening>}]
```

3. Click on the save button and restart the instance by clicking on the top right Action button and selecting the restart option.

## Creating a new Kafka topic

In this section, we'll guide you through the process of creating a Kafka topic to handle temperature data from different city regions. To ensure the segregation of data for different zones within the city, we will configure the topic to create three partitions.

1. Drag an inject node onto Canvas.
2. Set `msg.topic` to `createTopics` string.
3. Set `msg.payload` to `[{"topic": "Temperature","partitions": 3,"replicationFactor":1}]`, you can create as many topics as you want at a time.
4. Drag the Kafka admin node onto Canvas.
5. Connect the inject node’s output to the Kafka admin node’s input.
6. Deploy the flow by clicking on the top-right red deploy button.
7. After the Deploy, click on the inject button to create a topic.

![Screenshot showing set payload in inject node for creating new Kafka topic"](https://flowfuse.com/blog/2024/03/images/using-kafka-with-node-red-inject-node.png "Screenshot showing set payload in inject node for creating new Kafka topic")

!["Screenshot showing Node-RED flow for creating new kafka topic"](https://flowfuse.com/blog/2024/03/images/using-kafka-with-node-red-creating-topic.png "Screenshot showing Node-RED flow for creating new kafka topic")

## Sending Data to Kafka topic

In this part, we’ll be setting up a producer to send simulated city region temperature data to Kafka. The producer will populate one of the available partitions in our temperature topic.

We’ve already set up the temperature topic with 3 partitions. We’ll use these partitions to send data from each city region across the city (downtown region, suburban region, and industrial region). The partitioning process keeps the data separated, making it easier and faster to work with and analyze.

1. Drag a Kafka producer node onto Canvas.
2. Selected added Kafka configuration.
3. Click on that node and add the topic that we have created, set the key as `downtown`, and set the partition number as 0. (The partition index starts from zero)
4. Drag an inject node onto Canvas.
5. Set `msg.payload` to `$floor($random() * 100)` as a JSON expression and set the inject node to send the payload automatically after a specific interval of time.

!["Screenshot showing kafka producer configuration"](https://flowfuse.com/blog/2024/03/images/using-kafka-with-node-red-kafka-producer.png "Screenshot showing kafka producer configuration")

## Receiving data from Kafka topic

In this section, we will be creating consumers who will subscribe to listen to downtown region temperature data.

1. Drag the Kafka consumer node onto Canvas.
2. Selected added Kafka configuration.
3. Click on that node, add the topic that we have created, and enter partition `0` from which it will read temperature data.
4. Add the Change node onto the Canvas and set `msg.topic` to `msg._kafka.key` and `msg.payload` to `$number(msg.payload)` because the Kafka custom node we are using is converting number data into a string. (consumer returns a Kafka object containing information related topic’s partition from data received, a key which we have set in the producer section to recognize data, and other information)
5. Add the ui-chart node on to Canvas and select the created group in which the chart will render.
6. Connect the Kafka consumer node’s output to change the node’s input and change the node’s output to the chart node’s input.

!["Screenshot showing kafka consumer configuration"](https://flowfuse.com/blog/2024/03/images/using-kafka-with-node-red-kafka-consumer.png "Screenshot showing kafka consumer configuration")

!["Changing payload received from Kafka consumer"](https://flowfuse.com/blog/2024/03/images/using-kafka-with-node-red-change-node.png "Changing payload received from Kafka consumer")

Repeat the same steps to create producer and consumer for the rest of the two regions suburban and industrial, ensuring to set partitions 1 and 2 for, as we have already assigned partition 0 to the first producer created.

## Deploying the flow

Our temperature monitoring system is now complete and ready for deployment. To initiate the deployment process, locate the red 'Deploy' button positioned in the top right corner and navigate to `https://<your-instance-name>.flowfuse.cloud/dashboard`

!["Screenshot showing Node-RED flow of Real-time temperature monitoring system"](https://flowfuse.com/blog/2024/03/images/using-kafka-with-node-red-temperature-monitoring-system-flow.png "Screenshot showing Node-RED flow of Real-time temperature monitoring system")

:video{ariaLabel="Video showing Dashboard 2.0 view of Real-time temperature monitoring system" autoPlay="true" height="338" loop="true" muted="true" playsInline="true" preload="none" width="600"}

## Conclusion

In this guide, we’ve gone over everything you need to know about how to get started with Kafka and Node-RED. additionally, in this article, we’re going to focus on solving a problem where the sensor data across the city need to be centrally stored for efficient monitoring and visualization. By solving this problem step-by-step, you’ll understand how to integrate Kafka into your Node-RED applications.


# How to Build an Admin Dashboard with Node-RED Dashboard 2.0 (2026)

Managing and analyzing increasing amounts of data becomes crucial for organizations. Dashboard 2.0 and Node-RED help organizations access the data, normalize it, and visualize it. But what about controlling who can access what data? That's where an admin-only page comes in. Now With Node-RED Dashboard 2.0, we can also create robust and secure admin-only pages easily. In this guide, we'll provide you with step-by-step instructions to Build an Admin-only page with Node-RED Dashboard 2.0.

If you're new to Dashboard 2.0, refer to our blog post [Getting Started with Dashboard 2.0](https://flowfuse.com/blog/2024/03/dashboard-getting-started/) to install and get things started.

## Enabling FlowFuse User Authentication

Before proceeding further, let’s enable FlowFuse user authentication. This step adds an extra layer of protection to our dashboard by adding a login page that restricts access exclusively to registered FlowFuse users. Additionally, it further simplifies the process for the FlowFuse Multiuser addon to track and access logged-in user's data on the dashboard.

For more information, refer to the [documentation](https://flowfuse.com/docs/user/instance-settings/#flowfuse-user-authentication) and ensure that it is enabled.

!["Screenshot displaying the configuration settings within the FlowFuse instance, enabling user authentication for enhanced security.
"](https://flowfuse.com/blog/2024/04/images/building-admin-panel-node-red-dashboard-2-flowfuse-instance-setting.png "Screenshot displaying the configuration settings within the FlowFuse instance, enabling user authentication for enhanced security.
"){dataZoomable=""}

## Exploring FlowFuse Multiuser Addon

The FlowFuse Multiuser Addon is a plugin developed for Dashboard 2.0 to access logged-in user data on the dashboard. To install and understand how the FlowFuse Multiuser Addon works, refer to [Exploring the FlowFuse User Addon](https://flowfuse.com/blog/2024/04/displaying-logged-in-users-on-dashboard/#enabling-flowfuse-user-authentication)

## Storing a list of Admin users

Before we start building the admin-only page We need to store a list of admin users somewhere so that we can later display the admin-only page to those users only, For this guide we will store the admin list in the global context.

1. Drag an inject node onto the canvas.
2. Drag the 'change' node onto the canvas and set `global.admins` to a JSON array containing the usernames of admin users. This will store the created admin list in our Node-RED global context.

!["Screenshot displaying the change node which which stores list of admins username in global context"](https://flowfuse.com/blog/2024/04/images/building-admin-panel-node-red-dashboard-2-change-node-for-storing-adminlist-to-global-contenxt.png "Screenshot displaying the change node which which stores list of admins username in global context"){dataZoomable=""}

3. Connect the inject node’s output to the change node’s input.
4. To store the list in a global context, click the inject node’s button once you've deployed the flow.

## Building an Admin-only page

Now, let's proceed with the practical steps to implement the admin-only page:

1. Create a new page in Dashboard 2.0, where we will display sensitive data that we want to hide from regular users, this page will be our admin page.
2. Drag an event node on the canvas, then click on it, and select the UI base that contains your all pages including the admin page
3. Drag a switch node on the canvas, and add two conditions, one to check whether the user’s username is contained in the admin list or a second for otherwise, see the below image.

!["Screenshot displaying the switch node which checks whether the logged-in user's username is contained in the admin list or not"](https://flowfuse.com/blog/2024/04/images/building-admin-panel-node-red-dashboard-2-switch-node-checking-page-viewer-isadmin.png "Screenshot displaying the switch node which checks whether the logged-in user's username is contained in the admin list or not"){dataZoomable=""}

4. Drag two change nodes onto the canvas, Configure the first change node to show the admin page by setting `msg.payload` as `{"pages":{"show":["Admin View"]}}`, and the second change node to hide the admin page by setting the payload as: `{"pages":{"hide":["Admin View"]}}`.

!["Screenshot displaying the change node which contains payload to show admin page"](https://flowfuse.com/blog/2024/04/images/building-admin-panel-node-red-dashboard-2-change-node-for-showing-page.png "Screenshot displaying the change node which contains payload to show admin page"){dataZoomable=""}

!["Screenshot displaying the change node which contains payload to hide admin page"](https://flowfuse.com/blog/2024/04/images/building-admin-panel-node-red-dashboard-2-change-node-for-hidding-page.png "Screenshot displaying the change node which contains payload to display admin page"){dataZoomable=""}

5. Connect the first change node's input to the switch node's first output and the second change node's input to the switch node's second output.
6. Drag a ui-control widget onto the canvas, then click on it and select ui-base which includes all your pages including the admin page.
7. Finally, connect both change node’s outputs to the ui-control’s input.

## Hidding Admin only page by default

To hide an admin-only page by default to ensure regular users don't accidentally land on the admin-only page the following steps are needed.

1. Go to the Dashboard 2.0 sidebar, and select the layout tab.
2. Locate the admin-only page and click on the edit icon next to it.
3. Set visibility as "hidden".

!["Screenshot displaying admin-only page configuration"](https://flowfuse.com/blog/2024/04/images/building-admin-panel-node-red-dashboard-2-admin-only-page-configuration.png "Screenshot displaying admin-only page configuration"){dataZoomable=""}

## Deploying the flow

!["Screenshot displaying the FlowFuse Editor with flow of admin-only page"](https://flowfuse.com/blog/2024/04/images/building-admin-panel-node-red-dashboard-2-flowfuse-editior.png "Screenshot displaying the FlowFuse Editor with flow of admin-only page"){dataZoomable=""}

1. With your flow updated to include the above, click the "Deploy" button in the top-right of the Node-RED Editor.
2. Navigate to `https://<your-instance-name>.flowfuse.cloud/dashboard`.
3. When you visit the page for the first time, you'll need to log in with your FlowFuse username and password or through Single-Sign on.

Now, if your username is added to the list of admin usernames stored in the global context, you will be able to see the admin-only page.

!["Screenshot displaying the Dashboard view of normal users"](https://flowfuse.com/blog/2024/04/images/building-admin-panel-node-red-dashboard-2-dashboard-view-for-normal-users.png "Screenshot displaying the Dashboard view of normal users"){dataZoomable=""}

!["Screenshot displaying the Dashboard view of admin users"](https://flowfuse.com/blog/2024/04/images/building-admin-panel-node-red-dashboard-2-dashboard-view-for-admin-users.png "Screenshot displaying the Dashboard view of admin users"){dataZoomable=""}

## Next step

If you want to learn more about FlowFuse multiuser addon and personalize the multiuser dashboard. we do have many other resources, please refer to them to learn more.

- [Webinar](https://flowfuse.com/webinars/2024/node-red-dashboard-multi-user/) - This webinar provides an in-depth discussion of the Personalised Multi-User Dashboards feature and offers guidance on how to get started with it.
- [Personalised Multi-user Dashboards with Node-RED Dashboard 2.0](https://flowfuse.com/blog/2024/01/dashboard-2-multi-user/) - This article explores the process of building multi-user Dashboards secured with FlowFuse Cloud.
- [Displaying logged-in users on Dashboard 2.0](https://flowfuse.com/blog/2024/04/displaying-logged-in-users-on-dashboard/) - This detailed guide demonstrates how to display logged-in users on Dashboard 2.0 which using the FlowFuse Multiuser addon and FlowFuse.
- [Multi-User Dashboard for Ticket/Task Management](https://flowfuse.com/blueprints/flowfuse-dashboard/multi-user-dashboard/) blueprint, which allows you to utilize templates to develop Personalize multi-user dashboard quickly.


# Dashboard 2.0: Milestones, PWA and New Components

With a new release of Node-RED Dashboard 2.0 we have plenty of new fixes and improvements being added to the project. In this post, we'll deep dive into community contributions, PWA support, new Vuetify components, and the rest of the great work published in this latest release.

## Community Contributions

We firstly wanted to take this opportunity to point out a big milestone that we're very proud to see in Node-RED Dashboard 2.0.

This release marks the first time we've had more contributions in a single release from the community, than from FlowFuse employees. I think this is a testament to the community, and a big milestone in validating the success, and popularity, of Dashboard 2.0 in the wider Node-RED community.

So thank you very much [@BartButenaers](https://github.com/bartbutenaers){rel="&#x22;nofollow&#x22;"}, [@Ek1nox](https://github.com/Ek1nox){rel="&#x22;nofollow&#x22;"}, [@fullmetal-fred](https://github.com/fullmetal-fred){rel="&#x22;nofollow&#x22;"} and [@cgjgh](https://github.com/cgjgh){rel="&#x22;nofollow&#x22;"} for for great efforts and initiative in improving Node-RED Dashboard 2.0.

For anyone else that's interested in contributing to the project, please do reach out, and we'll be happy to help you get started. We also have a [Contributing Guide](https://dashboard.flowfuse.com/contributing/){rel="&#x22;nofollow&#x22;"} if you want to dive straight in.

## Progressive Web App (PWA) Support

The biggest community contribution we saw in this release was the addition of Progressive Web App (PWA) support. This feature was added by [@cgjgh](https://github.com/cgjgh){rel="&#x22;nofollow&#x22;"}, and allows you to install your Node-RED Dashboard 2.0 applications directly onto your platform, including Windows, iOS and Android.

This work will give your Dashboard's a much more native/natural feel when running on your own machines, and mean you no longer need to go via your browser to access your applications.

## New Vuetify (Preview) Components Available

Vuetify is the component library on which most of our Dashboard 2.0 components are built. Our core widgets implement the more fundamental UI elements, but that doesn't stop you from building out fully customized interfaces yourself using our [ui-template node](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html){rel="&#x22;nofollow&#x22;"} with the vast collection of Vuetify components.

Within the `ui-template` node, we natively support any of the [core Vuetify components](https://vuetifyjs.com/en/components/all/#containment){rel="&#x22;nofollow&#x22;"}, but Vuetify itself is always evolving and often they release components into their [Vuetify Labs](https://vuetifyjs.com/en/labs/introduction/#what-is-labs){rel="&#x22;nofollow&#x22;"}.

In their latest releases, a few of the new components have caught our eye as we've seen them regularly requested in Dashboard 2.0. As such, we've now made available the following Vuetify components inside a `ui-template` node:

#### Number Input ([docs](https://vuetifyjs.com/en/components/number-inputs/#installation){rel="&#x22;nofollow&#x22;"})

![Number Input](https://flowfuse.com/blog/2024/04/images/vuetify-numeric.png)*An example v-number-input from Vuetify's component library*

We do have [plans](https://github.com/FlowFuse/node-red-dashboard/issues/41){rel="&#x22;nofollow&#x22;"} for this to become a core widget, and will likely introduce this sooner, rather than later, however, in the mean time, you can now use the `v-number-input` component in a `ui-template` node to create your own number inputs instead.

```html
<template>
    <v-number-input v-model="value"></v-number-input>
</template>

<script>
  export default {
    data() {
      return {
        value: 0
      }
    },
    watch: {
      value: function () {
        this.send({payload: this.value})
      }
    }
  }
</script>

<style>
    .v-number-input__control .v-btn {
        color: var(--v-theme-on-surface);
    }
</style>
```

#### Sparkline ([docs](https://vuetifyjs.com/en/components/sparklines/#installation){rel="&#x22;nofollow&#x22;"})

![Sparkline](https://flowfuse.com/blog/2024/04/images/vuetify-sparkline.png)*An example v-sparkline rendering the output from a ui-slider*

Sparklines are a great way to visualize data trends in a small space, and we've seen them requested a few times in the past. Now you can use the `v-sparkline` component in a `ui-template` node to create your own sparklines.

This will also likely become a standalone node at some point too, possibly as a third-party widget, but for now implementing into a `ui-template` is very straight forward.

In the following example `ui-template`, we append any incoming `msg.payload` to a `value` array and render the sparkline accordingly.

```html
<template>
  <v-sparkline class="nrdb-ui-sparkline" :auto-line-width="false" :fill="false" :gradient="gradient"
    :gradient-direction="'top'" :line-width="2" :model-value="value" :padding="8"
    :smooth="10" :stroke-linecap="'round'" :type="'trend'" auto-draw></v-sparkline>
</template>

<script>
  export default {
    data: function () {
      return {
        gradient: ['#f72047', '#ffd200', '#1feaea'],
        value: [0, 2, 5, 9, 5, 10, 3, 5, 0, 0, 1, 8, 2, 9, 0]
      }
    },
    watch: {
      msg: function () {
        this.value.push(this.msg.payload)
      }
    }
  }
</script>

<style>
.nrdb-ui-sparkline path {
  stroke-dasharray: 0 !important;
}
</style>
```

There is no limitation on *where* you can use the sparkline either, we could, for example, add it to a `v-data-table` to show a sparkline of a particular feature for each row in the table:

![Data Table with Sparkline](https://flowfuse.com/blog/2024/04/images/vuetify-data-table-sparkline.png)*An example v-data-table that renders a v-sparkline on each row*

Here we see the corresponding template for the above `v-data-table` example:

```html
<template>
    <!-- Provide an input text box to search the content -->
    <v-text-field v-model="search" label="Search" prepend-inner-icon="mdi-magnify" single-line variant="outlined"
        hide-details></v-text-field>
    <v-data-table v-model:search="search" :items="msg?.payload" :headers="headers">
        <template v-slot:header.pingvalues="{ item }">
            Ping History
        </template>
        <template v-slot:item.ping="{ item }">
            {{ item.ping }}ms
        </template>
        <template v-slot:item.pingvalues="{ item }">
            <v-sparkline v-model="item.pingValues" :gradient="['#42b3f4', '#42b3f400']"
                :line-width="2" gradientDirection="top" :smooth="true" :fill="true">
        </template>

    </v-data-table>
</template>

<script>
export default {
  data () {
    return {
      search: '',
      headers: [
        { key: 'id', title: 'ID' },
        { key: 'ping', title: 'Ping' },
        { key: 'pingvalues', title: 'Ping History' }
      ]
    }
  }
}
</script>
```

#### Treeview ([docs](https://vuetifyjs.com/en/components/treeview/#installation){rel="&#x22;nofollow&#x22;"})

![Treeview](https://flowfuse.com/blog/2024/04/images/vuetify-treeview.png)*An example v-treeview from Vuetify Lab's component library*

The `v-treeview` component is a great way to visualize hierarchical data in a tree-like structure. We've seen this requested a few times in the past, and now you can use the `v-treeview` component in a `ui-template` node to create your own treeviews.

There is still scope for this to, one day, become a core or third party widget, but in the mean time, it's very easy to get this up and running in a `ui-template` node.

The Treeview example, and other examples above are available in this sample flow:

:iframe{allow="clipboard-read; clipboard-write" height="340px" src="https://flows.nodered.org/flow/0ac4d82aaf97409cb0dce9812cfa214c/share?height=300" style="border: none;" width="100%"}

## Other Highlights

Whilst the above are the main highlights of this release, we've also had a number of other smaller improvements and fixes that have been added to the project. These include:

- UI Radio Group - Dynamic radio options in [#765](https://github.com/FlowFuse/node-red-dashboard/pull/765){rel="&#x22;nofollow&#x22;"}
- UI Notification - Notification output & output msg when button clicked in [#766](https://github.com/FlowFuse/node-red-dashboard/pull/766){rel="&#x22;nofollow&#x22;"}
- UI Dropdown - Clear dropdown selection in [#775](https://github.com/FlowFuse/node-red-dashboard/pull/775){rel="&#x22;nofollow&#x22;"}
- UI Button - Add "Emulate Click" option in [#783](https://github.com/FlowFuse/node-red-dashboard/pull/783){rel="&#x22;nofollow&#x22;"}

You can see the full list of changes in the [1.8.0 Release Notes](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v1.8.0){rel="&#x22;nofollow&#x22;"}.

## Follow our Progress

New features and improvements are coming to Node-RED Dashboard 2.0 every week, if you're interested in what we have lined up, or want to contribute yourself, then you can track the work we have lined up on our GitHub Projects:

- [Dashboard 2.0 Activity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}
- [Dashboard 2.0 Planning Board](https://github.com/orgs/FlowFuse/projects/15/views/4){rel="&#x22;nofollow&#x22;"}
- [Dashboard 1.0 Feature Parity Tracker](https://github.com/orgs/FlowFuse/projects/15/views/5){rel="&#x22;nofollow&#x22;"}

If you have any feature requests, bugs/complaints or general feedback, please do reach out, and raise issues on our relevant [GitHub repository](https://github.com/FlowFuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}.


# Displaying logged in user on Node-RED Dashboard 2.0 (2026)

About a month ago, a powerful solution became available to the Node-RED community to deal with users and allow multiple to interact with the same dashboard in a personalized manner. It's called the Multli user Dashboard for Node-RED. In this guide, we will provide a step-by-step guide to show you how to secure your dashboard and access and display logged in user information on Dashboard 2.0.

If you're new to Dashboard 2.0, refer to our blog post [Getting Started with Dashboard 2.0](https://flowfuse.com/blog/2024/03/dashboard-getting-started/)

## Enabling FlowFuse User Authentication

Before we display logged-in user data on the dashboard, first we need to set up a login mechanism with FlowFuse for the dashboard. This simplifies securing Node-RED Dashboards and provides contextual user data within the Dashboard itself for who is logged in.

1. Navigate to the Instance "settings".
2. Select the "Security" tab.
3. Enable “FlowFuse User Authentication”

Now, the first time you visit the dashboard, you'll need to log in with your registered FlowFuse username and password

!["Screenshot displaying the configuration settings within the FlowFuse instance, enabling user authentication for enhanced security."](https://flowfuse.com/blog/2024/04/images/displaying-logged-in-user-flowfuse-instance-setting.png "Screenshot displaying the configuration settings within the FlowFuse instance, enabling user authentication for enhanced security."){dataZoomable=""}

## Exploring the FlowFuse User Addon

The FlowFuse User Addon is a plugin developed for Dashboard 2.0, leveraging the FlowFuse API to retrieve information about logged in user.

### Installing Flowfuse user addon

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

1. Click the Node-RED Settings (top-right)
2. Click "Manage Palette"
3. Switch to the "Install" tab
4. Search for `@flowfuse/node-red-dashboard-2-user-addon`
5. Click "Install"

### How it Works

In this addon, user information is attached to the `msg` emitted by Dashboard 2.0 nodes. This user information object is attached as `msg._client.user`. Below is an example of how that object looks:

```text
{
   "userId": "", // unique identifier for the user
   "username": "", // FlowFuse Username
   "email": "", // E-Mail Address connected to their FlowFuse account
   "name": "", // Full Name
   "image": "" // User Avatar from FlowFuse
}
```

Behind the scenes, the user addon is appending the user object to the `msg`, via the SocketIO auth option. We make the socketio object available via a computed [setup](https://dashboard.flowfuse.com/contributing/guides/state-management.html#setup-store){rel="&#x22;nofollow&#x22;"} object, this means that we can also access user data in any ui-template widget with `{{ setup.socketio.auth.user }}`, in the `<template>`, or `this.setup.socketio.auth.user`, in the JS.

When running Node-RED Dashboard 2.0 on FlowFuse, you'll have a new tab available in the "Dashboard 2.0" sidebar in the Node-RED Editor, you just have to navigate to the "FF Auth" tab and you’ll see two options.

**Option 1: Include Client Data**

By default, this option is enabled. When this option is enabled, an object with user information will be added to the “msg” emitted by any widget of the Node-RED Dashboard 2.0.

**Option 2: Accept Client Constraints**

A feature that ensures messages are specifically targeted to individual clients, which enhances the precision and security of data transmission within the platform. It determines by enabling the nodes option in the FF Auth tab whether the enabled node type will utilize client data, such as socketid, and restrict communications to only that client.

For example, consider a manufacturing facility where each production line has its own monitoring system. With this feature enabled, data from sensors on Production Line A will only be sent to the monitoring system designated for Production Line A. This ensures that data remains isolated and relevant to each specific area of operation, maintaining organizational efficiency and security.

*Note: Please note that Multi-User Addons can only be used by our Teams and Enterprise Self-Hosted customers. Upon request, we provide all required configurations to get started.*

!["Screenshot displaying the FlowFuse Muti-user addon option"](https://flowfuse.com/blog/2024/04/images/displaying-logged-in-user-ff-auth-tab.png "Screenshot displaying the FlowFuse Muti-user addon option"){dataZoomable=""}

## Displaying logged in user on Dashboard 2.0

Now you know how the user add on works, you are all set to display logged in users on Dashboard 2.0. To confirm this you can use a `debug` node that receives the `msg` object emitted by the Dashboard 2.0 widgets.

To display user information on the dashboard we will use Vue’s [Teleport](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html#teleports){rel="&#x22;nofollow&#x22;"} feature to render content to a specific location in the DOM, we will display user information at the action bar’s right-hand side.

1. Drag a `ui-template` widget onto the canvas.
2. Click on that node, and select type as “Widget (Ui-Scoped)”. ( this allows us to render this ui-template at ui scoped which means I will not required to add separate ui-templates for different pages )
3. Copy the below vue snippet and paste that into the ui-template.

```html
<template>
    <!-- Teleporting user info to #app-bar-actions, which is the ID of the action bars' right corners area -->
    <Teleport v-if="loaded" to="#app-bar-actions">
        <div class="user-info">
            <!-- Displaying user image -->
            <img :src="setup.socketio.auth.user.image" />
            <!-- Greeting the user -->
            <span>Hi, {{ setup.socketio.auth.user.name }}</span>
        </div>
    </Teleport>
</template>

<script>
export default {
    data() {
        return {
            // Flag to indicate if the component is loaded
            loaded: false
        };
    },
    mounted() {
        // This function is called when the component is inserted into the DOM.
        // Setting loaded to true here ensures the component is ready to access #app-bar-actions,
        // as it's now part of the same DOM structure.
        // Accessing it before mounted() would cause an error because the component wouldn't be initialized in the DOM yet.
        this.loaded = true; // Setting loaded to true to indicate that the component has been mounted successfully
    }
}
</script>

<style>
/* Styling for user info display */
.user-info {
    display: flex;
    align-items: center;
    gap: 8px;
}
/* Styling for user avatar image*/
.user-info img {
    width: 24px;
    height: 24px;
}
</style>
```

## Deploying the flow

1. With your flow updated to include the above, click the "Deploy" button in the top-right of the Node-RED Editor.
2. Navigate to `https://<your-instance-name>.flowfuse.cloud/dashboard`.

!["Screenshot of Dashboard displaying logged in user information"](https://flowfuse.com/blog/2024/04/images/displaying-logged-in-user-dashboard-view.png "Screenshot of Dashboard displaying logged in user information"){dataZoomable=""}

## Next step

If you want to learn more about the FlowFuse Multiuser addon and Personalize Multiuser Dashboard. we do have many other resources, please refer to them to learn more.

- [Webinar](https://flowfuse.com/webinars/2024/node-red-dashboard-multi-user/) - This webinar provides an in-depth discussion of the Personalised Multi-User Dashboards feature and offers guidance on how to get started with it.
- [Personalised Multi-user Dashboards with Node-RED Dashboard 2.0](https://flowfuse.com/blog/2024/01/dashboard-2-multi-user/) - This article explores the process of building multi-user Dashboards secured with FlowFuse Cloud.
- [Multi-User Dashboard for Ticket/Task Management](https://flowfuse.com/blueprints/flowfuse-dashboard/multi-user-dashboard/) blueprint, which allows you to quickly utilize templates to develope Personalize multi-user dashboard.

## Conclusion

In this guide, we have demonstrated how to secure your dashboard and how to retrieve and display logged in user data on Dashboard 2.0. Additionally, we have discussed the functionality of the FlowFuse multi-user addon.


# FlowFuse Gears Up for Hannover Messe

We're excited to announce that FlowFuse will be exhibiting at the upcoming Hannover Messe! This renowned industrial trade fair provides a platform to connect with global innovators and explore the latest advancements. Visit us in Hall 14, Stand L59 from April 22nd - 26th.

**Do you need a pass? We can help with that as well.**

## Understanding Node-RED

Node-RED, created by our co-founder Nick O'Leary, is a powerful open-source tool that makes it easy to connect industrial devices, collect data, and create insightful visualizations. Its intuitive interface and wide range of integrations have made it a popular choice in manufacturing.

## Scaling with FlowFuse

As organizations adopt Node-RED more extensively, managing multiple instances can become complex. FlowFuse addresses this by providing a central platform designed to streamline Node-RED operations:

- Operations and Maintenance: Get a consolidated view of your Node-RED instances, track their health, and ensure smooth operation.
- Developer Velocity: Enhance development efficiency with streamlined updates, remote access, and version control for Node-RED deployments.
- Security and Compliance: Integrate Node-RED with your existing security systems, implement detailed user permissions, and maintain audit logs to satisfy industry regulations.

## Experience FlowFuse at Hannover Messe

### Come see us at our booth for:

- Live demonstrations showcasing how FlowFuse enhances your Node-RED applications.
- Discussions about tackling common challenges in industrial data management.
- A chance to connect with our team and learn how we can support your goals.

## Let's Connect!

If you're interested in making the most of Node-RED within your manufacturing processes, FlowFuse offers the tools to simplify and secure your operations. Stop by our booth at Hannover Messe!

## Get Your Free Pass to Hannover Messe

Interested in attending Hannover Messe? Click [here](https://www.hannovermesse.de/en/application/registration/direct-entry-tickets-passes?code=hXWhs){rel="&#x22;nofollow&#x22;"} to claim your free pass to the event.


# Introducing FlowFuse Dedicated

Today, we are excited to officially announce FlowFuse Dedicated, a new way to use our enterprise platform as a single-tenant SaaS offering. This new offering provides all of the benefits of FlowFuse enterprise, with an added focus on data residency, isolation, and private networking to meet compliance needs.

At FlowFuse, we cater to a diverse spectrum of clients, ranging from burgeoning startups to formidable global enterprises. It's clear that a one-size-fits-all approach to deployment doesn't align with the varied needs of our customer base. FlowFuse's product already has flexible deployment options, ranging from FlowFuse Cloud, to a cloud environment of your choosing, to your own hardware on-premise. Allowing our customers to achieve compliance even in the stringent regulatory frameworks. Even sectors not traditionally bound by stringent regulatory frameworks are finding compliance to be a critical factor impacting productivity and profitability.

Here’s what sets FlowFuse Dedicated apart:

- **Single-Tenant FlowFuse Platform:** Enjoy the exclusivity of a dedicated environment, ensuring that your operations are isolated, secure, and tailored to your specific needs.
- **SaaS-like Efficiency:** Experience the ease and simplicity of a SaaS solution, where FlowFuse takes care of the entire management and deployment process. When software is not upgraded to the latest versions, organizations use obsolete and inefficient software that can be exposed to security threats. Because FlowFuse Dedicated is fully managed by FlowFuse, customers get access to the latest software features and security updates imminently.
- **Regional Deployment Flexibility:** FlowFuse Dedicated can be deployed in the region of your choice, ensuring data residency requirements are met while optimizing performance by reducing latency. FlowFuse Dedicated can be deployed in 30+ regions.
- **Enterprise-Grade Features:** Enjoy access to all enterprise features and configurations as your own FlowFuse Administrator, enabling you to manage multiple teams effectively.
- **Comprehensive Compliance:** Meet complex compliance standards with ease, thanks to full data and source code IP isolation.

FlowFuse Dedicated represents a paradigm shift in Node-RED offerings, a solution that not only meets the demanding requirements of today's enterprises in terms of speed, efficiency, and productivity but also navigates the complex terrain of compliance and data security with unparalleled finesse. [Contact us to learn more](https://flowfuse.com/contact-us/).


# How to Build An Application With Node-RED Dashboard 2.0 (2026)

In this guide, we'll build a Todo application to guide you through the features and explain how you can build rich and dynamic applications too. It shows many of the features that make Dashboard 2.0 great, and why you should use it over the deprecated node-red-dashboard.

If you're new to Dashboard 2.0, refer to our blog post [Getting Started with Dashboard 2.0](https://flowfuse.com/blog/2024/03/dashboard-getting-started/) to install and get things started.

## Installing Flowfuse user addon

The FlowFuse User Addon is a plugin developed for Dashboard 2.0, that levereges the FlowFuse API to access logged in user's information at Dashboard 2.0. For detailed information refer to the [Exploring the FlowFuse User Addon](https://flowfuse.com/blog/2024/04/displaying-logged-in-users-on-dashboard/#exploring-the-flowfuse-user-addon) and make sure to install it.

Before you begin the application development process, please make sure that FlowFuse user authentication is enabled. This feature adds a layer of security to your application with a login page. By combining the FlowFuse user addon with user authentication, we gain access to the logged in user's data within our application. For more information on FlowFuse user authentication, refer to the [documentation](https://flowfuse.com/docs/user/instance-settings/#flowfuse-user-authentication) and make sure that it is enabled.

## Building Task Management application

:video{ariaLabel="Video of the Todo application built with Node-RED Dashboard 2.0" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

Throughout this guide, we will be building a simple, secure, and personalized Task management application that will allow users to create and view their tasks.

### Building a Form to Submit Tasks

1. Drag an **ui-form** widget onto the canvas.
2. Click on the edit icon next to Page 1 (The default page added when you install Dashboard 2.0) in the Dashboard 2.0 sidebar. While this step is optional, updating the page configurations as shown in the image below ensures that your application aligns with the layout described in this guide.

!["Screenshot displaying 'new task' page configurations"](https://flowfuse.com/blog/2024/04/images/building-an-application-with-dashboard-2-page1-configuration.png "Screenshot displaying 'new task' page configurations"){dataZoomable=""}

3. Click on the **ui-form** widget to add form elements such as title, description, due date, and priority.

!["Screenshot of ui widget form configuration"](https://flowfuse.com/blog/2024/04/images/building-an-application-with-dashboard-2-task-submission-form.png "Screenshot of ui widget form configuration"){dataZoomable=""}

### Storing Tasks in the Global Context

For this guide, we are storing our Tasks in Node-RED global context but storing them in a database will make it easy to manage your task data.

1. Drag a **function** node onto the canvas
2. Paste the below code in the **function** node.

```javascript
// Retrieve the existing tasks from the global context or initialize an empty array if none exists

let tasks = global.get('tasks') || [];

// Push the new task object into the tasks array, including the task details and the user object extracted from the message object, as each payload emitted by the Node-RED Dashboard 2.0 widgets contains user information due to the FlowFuse User Addon.

tasks.push({
  ...msg.payload,
  ...{
    user: msg._client.user // Assign the user object to the task
  }
});

// Update the 'tasks' variable in the global context with the modified tasks array

global.set('tasks', tasks);

return msg;
```

3. Connect the **ui-form** widget’s output to the **function** node’s input.

### Displaying notification on successful task submission

1. Drag a **change** node onto the canvas and set `msg.payload` to the confirmation message you want to display on successful task submission.

!["screenshot of the change node setting payload for notification"](https://flowfuse.com/blog/2024/04/images/building-an-application-with-dashboard-change-node-setting-payload-for-notification.png "screenshot of the change node setting payload for notification"){dataZoomable=""}

2. Drag an **ui-notification** onto the canvas select **ui-base** and set the position to "center".
3. Connect the **ui-form** widget’s output to the **change** node’s input and the **change** node’s output to the **ui-notification** widget's input.

### Retrieving and Filtering Tasks

Now that we can store tasks along with the user details of who submitted them, we need to retrieve and filter them based on users, ensuring that users can only see their tasks only and not others.

1. Drag a **ui-event** widget onto the canvas and select **ui-base** for it. The **ui-event** will enable us to display updated tasks on the table without the need for polling, as it triggers when the page reloads or changes.
2. Drag a **change** node onto the canvas and set `msg.payload` to `global.tasks`.

!["Screenshot of the change setting retriving global context and setting to msg.payload"](https://flowfuse.com/blog/2024/04/images/building-an-application-with-dashboard-change-node-retriving-global-context-data.png "Screenshot of the change setting retriving global context and setting to msg.payload"){dataZoomable=""}

3. Drag a **function** node onto the canvas and paste the below code into it.

```javascript
// Filter the payload array of tasks to include only those tasks associated with the currently logged in user.

msg.payload = msg.payload.filter((task) => task.user.userId === msg._client.user.userId);

// Return the modified message object containing the filtered tasks.

return msg;
```

4. Connect the **ui-event** widget’s output to the **change** node’s input and the **change** nodes’ output to the **function** node’s input.

### Enabling client constraint for ui-template

Before we begin building our table to display tasks, we need to enable access to client constraints for the **ui-template** widget. Access client constraints ensure that messages or actions are specifically targeted to individual clients. For instance, if 100 people are interacting with the same task management dashboard simultaneously and one person submits a task, the notification will only be visible to that person and not to the remaining 99 individuals.

If you have experience with Node-RED Dashboard 1.0, you may recall that these client constraints were only available for **ui-control** and **ui-notification** widgets but in Dashboard 2.0 you can enable it for any widget.

!["Screenshot displaying FF Auth tab"](https://flowfuse.com/blog/2024/04/images/building-an-application-with-dashboard-2-ff-auth-tab.png "Screenshot displaying FF Auth tab"){dataZoomable=""}

1. Navigate to the Dashboard 2.0 sidebar and select the top-right "FF Auth" Tab
2. In the "Accept Client Constraints" option, you'll see Dashboard 2.0 widgets where this option is by default enabled for **ui-notification** and **ui-control**, enable it for **ui-template** as well.

### Creating a table and displaying the task

In this section, we will build an interactive table using **ui-template** and [vuetify component](https://vuetifyjs.com/en/components/all/){rel="&#x22;nofollow&#x22;"}. Vuetify offers a wide range of components, all of which are compatible with our Node-RED Dashboard 2.0's ui-template widget. You can easily use them by just simply copying and pasting them into the **ui-template** widget.

1. Drag an **ui-template** widget onto the canvas
2. Create a new **ui-page** and **ui-group** for it. Below, I have provided a screenshot of the "new task" page configurations. Again You can replicate it if you want to align with the layout described in this guide, otherwise, it is optional.

!["Screenshot displaying ui-template widget with code for building table for displaying task"](https://flowfuse.com/blog/2024/04/images/building-an-application-with-dashboard-template-widget.png "Screenshot displaying ui-template widget with code for building table for displaying task"){dataZoomable=""}

3. Paste the below code into the widget, If you're new to Vue.js, rest assured I've included helpful comments for clarity.

```html
` <template>
 <!-- Input field for searching tasks -->
 <v-text-field v-model="search" label="Search" prepend-inner-icon="mdi-magnify" single-line variant="outlined"
  hide-details></v-text-field>
 
 <!-- Data table to display tasks -->
 <v-data-table :search="search" :items="msg?.payload">
  <!-- Custom header for the "current" column -->
  <template v-slot:header.current>
   <div class="text-center">Center-Aligned</div>
  </template>

  <!-- Template for the "priority" column -->
  <template v-slot:item.priority="{ item }">
   <!-- Display priority icon if it exists -->
   <v-icon v-if="item.priority" icon="mdi-alert" color="red"></v-icon>
  </template>

  <!-- Template for the "user" column -->
  <template v-slot:item.user="{ item }">
   <!-- Display user avatar and username -->
   <div class="user">
    <!-- User avatar -->
    <img :src="item.user.image" width="24" />
    <!-- Username -->
    <span>{{ item.user.username }}</span>
   </div>
  </template>

  <!-- Template for the "due" column -->
  <template v-slot:item.due="{ item }">
   <!-- Calculate and display the number of days between due date and current date -->
   {{ daysBetween(item.due, new Date()) }} Days
  </template>
 </v-data-table>
</template>

<script>
 export default {
  data() {
   return {
    // Search input field model
    search: '',
   }
  },
  methods: {
   // Method to calculate the number of days between two dates
   daysBetween(date1, date2) {
    // Calculate the difference in days
    const oneDay = 24 * 60 * 60 * 1000; // hours*minutes*seconds*milliseconds
    const firstDate = new Date(date1);
    const secondDate = new Date(date2);
    const diffDays = Math.round(Math.abs((firstDate - secondDate) / oneDay));
    return diffDays;
   }
  }
 }
</script>

<style scoped>
 /* Styling for user avatar and username */
 .user {
  display: flex;
  gap: 5px; /* Gap between avatar and username */
 }

 /* Styling for user avatar */
 .user img {
  width: 24px; /* Set width of user avatar */
 }
</style>

```

3. Connect the **ui-template** widget's input to the **function** node's output ( function node which we have added to filter tasks based on user ).

## Deploying the flow

!["Screenshot displaying Node-RED flow of Task management system"](https://flowfuse.com/blog/2024/04/images/building-an-application-with-dashboard-task-management-application-flow.png "Screenshot displaying Node-RED flow of Task management system"){dataZoomable=""}

1. Deploy the flow by clicking the top right Deploy button.
2. Locate the 'Open Dashboard' button at the top-right corner of the Dashboard 2.0 sidebar and click on it to navigate to the dashboard.
3. Login with the registered FlowFuse account username and password.

Now, we're all set to add tasks. Navigate to the "New Task" page to add tasks. To view tasks, navigate to the "your Task" page.

## Next step

If you want to enhance this simple application by adding more features, consider the following resources:

- [Webinar](https://flowfuse.com/webinars/2024/node-red-dashboard-multi-user/) - This webinar provides an in-depth discussion of the Personalised Multi-User Dashboards feature and offers guidance on how to get started with it.
- [Displaying logged-in users on Dashboard 2.0](https://flowfuse.com/blog/2024/04/displaying-logged-in-users-on-dashboard/) - This detailed guide demonstrates how to display logged-in users on Dashboard 2.0 which using the FlowFuse Multiuser addon and FlowFuse.
- [How to Build an Admin Dashboard with Node-RED Dashboard 2.0](https://flowfuse.com/blog/2024/04/building-an-admin-panel-in-node-red-with-dashboard-2/) - This detailed guide demonstrates how to build a secure admin page in Node-RED Dashboard 2.0.
- [Multi-User Dashboard for Ticket/Task Management](https://flowfuse.com/blueprints/flowfuse-dashboard/multi-user-dashboard/) blueprint, which allows you to utilize templates to develop a personalized multi-user dashboard quickly. This Task management blueprint has all features such as adding, updating, and deleting tasks, user profiles, and admin dashboard.


# Node-RED Manufacturing Architecture

The architecture of a factory's Node-RED infrastructure is a common topic of discussion and inquiry. Fundamentally, my response to such queries unfolds in two parts. Initially, the focus must be on data organization. I champion a structure centered around a [Unified Namespace](https://flowfuse.com/use-cases/uns/), a concept I explore in depth in this article ["Node-RED in a Unified Namespace Architecture."](https://flowfuse.com/blog/2024/02/node-red-unified-namespace-architecture/) However, this is only one part of the inquiry. The other part of the question delves into the positioning of FlowFuse and Node-RED within the network infrastructure.

## Understanding the Multilayered Approach: The Foundation of Factory Architecture

For illustrative purposes, I’ve opted to reference the [Purdue / ISA-99 Model](https://webstore.ansi.org/preview-pages/ISA/preview_S_990001_2007.pdf){rel="&#x22;nofollow&#x22;"}, despite its fair share of criticism. Many of today's factories and manufacturing spaces adhere to this model, and the aim here is to mirror a realistic network scenario. For the sake of clarity, I've condensed the network into three primary layers.

**ISA-99 Visualization**

![Purdue Model](https://flowfuse.com/blog/2024/04/images/purdue-model.png){dataZoomable=""}

At the base is the Shopfloor layer. This is where all the physical factory equipment resides. Often, this layer is segmented further, but for our discussion, it's represented as a single zone.

Next is the Edge layer, which serves as the communicative conduit between the Shopfloor and the Enterprise layers. This layer often contains a Demilitarized Zone (DMZ) where various Gateways are positioned.

At the top, we find the Enterprise Layer. This can signify either cloud services or a company-wide accessible network. Frequently, the Cloud and Enterprise layers are divided, but in our case, it doesn’t matter whether they are separated.

![Node-RED Manufacturing Architecture](https://flowfuse.com/blog/2024/04/images/node-red-architecture.png){dataZoomable=""}

## Applications Across Factory Layers

**Shopfloor:** Node-RED's versatility shines at the shopfloor level, where it’s typically installed on a variety of industrial devices. A prominent application is the development of simple Human-Machine Interfaces (HMIs) using the [Dashboard module](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"}, which enables operators to interact with the machines visually and intuitively. Additionally, Node-RED is instrumental in data acquisition tasks, where it can gather, process, and interpret data from sensors and actuators in real-time. This capability allows for the monitoring of production processes, predictive maintenance, and the triggering of automated workflows in response to specific conditions or anomalies detected on the shop floor.

**Edge:** At the edge level, Node-RED plays a pivotal role in harmonizing the divide between Operational Technology (OT) and Information Technology (IT). Its gateway functionalities are not only integral in facilitating the flow of data between the shopfloor devices and the enterprise-level systems but also it is at this juncture that plant-wide Key Performance Indicators (KPIs) are generated. These KPIs, aggregated from various data points across the production line, are essential for operational oversight and strategic decision-making. Edge-level Node-RED instances can run local analytics and manage alarms.

**Enterprise Network:** Within the higher echelons of the network, FlowFuse establishes its domain, serving as a central hub for managing multiple Node-RED instances. In this space, Node-RED’s agility is leveraged for creating test environments, where simulated data flows can be used to model and understand potential changes before they are deployed on the shopfloor. For enterprise-wide KPI calculations, advanced analytics, and integration with other business systems like ERP or CRM. This layer can use data processed at the edge to inform enterprise-level decisions, drive continuous improvement, and harness machine learning models to glean deeper insights into the production process, quality control, and supply chain logistics.

### The Device Agent: Empowering Remote Node-RED Instances

Every Node-RED instance that isn’t hosted within the Enterprise/Cloud Network’s domain of FlowFuse operates on a Device Agent. This simple tool runs Node-RED and facilitates the connection to FlowFuse. Such remote Node-RED instances are referred to as Devices.

### How to communicate between Node-RED Instance? Project Nodes

Facilitating communication between Node-RED instances is a fundamental requirement for creating a cohesive and responsive Node-RED architecture. FlowFuse elevates this capability by providing an event-driven communication framework (based on MQTT) that binds different Node-RED instances together. This is primarily achieved through the use of Project Links, a feature within FlowFuse that allows for the smooth transfer of data between instances.

These [Project Links](https://flowfuse.com/docs/user/projectnodes/) are more than just communication channels; they represent a method of organizing Node-RED instances into a networked application, where each instance can be considered a node within the project. With Project Links, instances can subscribe to specific events or topics and publish messages that other instances are listening for. This is particularly useful for triggering actions across the network, like updating a dashboard in real time or controlling devices on the shopfloor based on analytics computed at the edge.

## Summary

By employing a unified namespace approach and strategically positioning Node-RED and FlowFuse within the network, we enable a seamless flow of data from the shopfloor to the enterprise level. This multilayered approach not only enhances communication between operational technology and information technology but also empowers real-time monitoring, predictive maintenance, and strategic decision-making.


# Node-RED Multiplayer mode

Last month I [wrote](https://flowfuse.com/blog/2024/03/looking-towards-node-red-4/) about what users
can expect with Node-RED 4.0. One of the features I highlighted was improving the
concurrent editing experience. With the recent [beta release](https://discourse.nodered.org/t/node-red-4-0-0-beta-2-released/87026){rel="&#x22;nofollow&#x22;"} of Node-RED, the first
steps on that journey are now available to try.

In this post, I'll cover what has been done so far and what we've got planned.

Full concurrent editing within Node-RED is not a small task, so naturally we're breaking it up into a series of iterations that each bring us a step closer to the eventual goal.

The natural first step was to add some basic awareness of who else has the editor open. On the surface, this may sound like a simple step, but it required laying lots of groundwork to achieve such as designing how the editor and runtime communicate this state in real-time.

It also meant starting to figure out the visual language we'll use in the editor to represent users. I spent time researching how other applications handle this - seeing what would work in the Node-RED context.

With Node-RED v4-beta.2, we have made these first steps available to the community. When the feature is enabled, you will now see icons in the header for all of the other users that have the editor open.

![Screenshot of Node-RED with additional user icons in the header](https://flowfuse.com/blog/2024/04/images/nr-multiplayer.png)

Screenshot of Node-RED with additional user icons in the header

Clicking on their icon will show a little information box about *where* they are in the editor. Now, for this iteration, that information is fairly crude - it will tell you the name of the flow they have open and which node they are currently editing, but that's it. Which leads me on to what we have planned next.

### Next steps

The next iteration will be to improve how we indicate where a user is in the editor. Adding mini-icons to the editor tabs, or as annotations on individual nodes will allow us to more seamlessly indicate where a user is.

After that, one possible option will be to show the user's mouse cursor movement in real-time within the flow tab, and start to layer up the feedback we can provide as they make changes.

### Trying it out on FlowFuse Cloud

I mentioned earlier this feature has to be enabled. For a local install, details on how to do this are in the [release forum post](https://discourse.nodered.org/t/node-red-4-0-0-beta-2-released/87026#introducing-multiplayer-mode-2){rel="&#x22;nofollow&#x22;"}.

If you want to give it a go now, we already have Node-RED v4-beta.2 available to [try on FlowFuse Cloud](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"} - where the multiplayer feature is pre-enabled whilst it's in beta mode.


# Role-Based Access for your Node-RED applications

Role-based access Control (RBAC) is a crucial component of modern software platforms. It provides granular control over access rights and enhances security. Integrating RBAC into the FlowFuse platform brings this level of sophistication to Node-RED, allowing users to manage their environments with precision and confidence. This blog will explore how FlowFuse's RBAC system improves both security and user experience within the Node-RED ecosystem.

## Roles Overview

FlowFuse offers a variety of roles that cater to different levels of access within the Node-RED environment, ensuring that users can tailor their platform according to their needs. These roles include:

1. Owner - The highest level of access with full control over team settings, instances, and features.
2. Member - Functions similarly to Owner, but inhibits the abilities to change instance states and manage members.
3. Viewer - Allows users to visualize and see flows and dashboards. This is great for collaboration across multi tenant teams.
4. Dashboard Only - Designed for end users that will interact with Dashboards, but don't have a reason to see or edit flows.

!["Role Based Access Control For Node-RED with FlowFuse"](https://flowfuse.com/blog/2024/04/images/role-based-access-control-for-node-red-flowfuse.png "Role Based Access Control For Node-RED with FlowFuse"){dataZoomable=""}

For further details see [documentation](https://flowfuse.com/docs/user/team/#role-based-access-control) for full granularity of roles.

## Instance Protection Mode

A useful feature of FlowFuse's RBAC system is the Instance Protection Mode. This mode adds an additional layer of security by locking down critical Node-RED instances, preventing unauthorized modifications to configuration and nodes. The protection mode is particularly useful in production environments and areas in which need an extra layer of protection for any unintentional updates or changes.

!["Protect Node-RED instance from change with Instance Protection Mode"](https://flowfuse.com/blog/2024/04/images/protect-instance-node-red-with-flowfuse.png "Protect Node-RED instance from change with Instance Protection Mode"){dataZoomable=""}

## The Impact on User Experience

FlowFuse's RBAC system significantly enhances the user experience for Node-RED users by providing a secure, customizable, and controlled environment. Teams can collaborate more efficiently and safely, knowing that access is properly managed and critical systems are protected.

## Conclusion

FlowFuse's integration of RBAC into the Node-RED ecosystem represents a significant enhancement in how users can interact with, manage, and secure their Node-RED instances. By offering detailed control over access rights and introducing features like Instance Protection Mode, FlowFuse not only secures Node-RED environments but also greatly improves their manageability and the overall user experience. With RBAC, users can now tailor their Node-RED platforms according to their specific needs while ensuring that security and collaboration are at the forefront of their operations.

For more information on how to implement and utilize Role-Based Access Control within FlowFuse, please refer to our [documentation](https://flowfuse.com/docs/user/team/#role-based-access-control).


# Exploring Node-RED Dashboard 2.0 Widgets

This guide delves into Node-RED Dashboard 2.0 widgets. It is a guide on how to build a Dashboard application, and will cover many of the widgets available today.

If you're new to Dashboard 2.0, we recommend starting with the [Getting Started with Dashboard 2.0](https://flowfuse.com/blog/2024/03/dashboard-getting-started/) guide and make sure to install it.

## What Are Widgets?

Widgets in Node-RED Dashboard 2.0 are the building blocks for creating a user interface. In Dashboard 2.0, you get a variety of widgets like forms, templates, buttons, and others to make different parts of your interface.

## Building Applications with Dashboard 2.0 Widgets

:video{ariaLabel="Income-expense tracker built with dashboard 2.0" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}*Income-expense tracker build with dashboard 2.0*

In this guide, we'll create a basic application to input expenses and income. This will then be displayed in a chart and table for analysis. The application will utilize a wide range of widgets available in Dashboard 2.0, helping you understand and use them confidently.

### Adding Forms

For the income and expense submission, we'll incorporate a form using the **ui-form** widget.

1. Drag the **ui-form** widget onto the canvas.
2. Double-click on it to access various widget properties and select the **ui-group** where it should render.
3. Add "date", "description", "amount", and "note" form elements by clicking the **+element** button at the bottom left.

!["Screenshot displaying Income submission ui-form's configuration"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-income-submission-form.png "Screenshot displaying Income submission ui-form's configuration"){dataZoomable=""}*Screenshot displaying Income submission ui-form's configuration*

Once you've added the income submission form, repeat the process to add an expense submission form on another **ui-page** and **ui-group**. For more information on **ui-form**, refer to the [ui-form docs](https://dashboard.flowfuse.com/nodes/widgets/ui-form.html){rel="&#x22;nofollow&#x22;"}.

!["Screenshot displaying Expense submission ui-form's configuration"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-expense-submission-form.png "Screenshot displaying Expense submission ui-form's configuration"){dataZoomable=""}*Screenshot displaying Expense submission ui-form's configuration*

### Storing Form Data

The **ui-form** widget emits a payload object with key-value pairs of form elements upon submission. We'll store this data in a global context, If you are not familiar with Node-RED context, refer to [Understanding Node-RED varriables](https://flowfuse.com/blog/2024/05/understanding-node-flow-global-environment-variables-in-node-red/).

1. Drag a **function** node onto the canvas and add the following code. This will store the submission in the `income` global context variable, and then modify `msg.payload` to pass on a notification to any further connected nodes.

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

```javascript
// Retrieve the existing 'income' array from the global context, or initialize it as an empty array if it doesn't exist
let income = global.get('income') || [];

// Push the incoming payload along with a 'type' property set to "income" into the 'income' array
income.push({
  ...msg.payload,
  type: "income",
});

// Store the updated 'income' array back into the global context
global.set('income', income);

// Set the message payload to a confirmation message for notification
msg.payload = "Thank you for submitting income!";

// Return the modified message
return msg;
```

Similarly, you can do this for storing expense data submitted using the expense submission form.

### Displaying Notifications

For displaying notifications on the dashboard, we'll utilize the **ui-notification** widget, which emits notifications to the user's dashboard. It accepts `msg.payload` which should be a string format or raw HTML/JavaScript for custom formatting.

1. Drag the **ui-notification** widget onto the canvas.
2. Set the position property to **center**. You can also adjust colors or notification timeout by modifying the color and timeout properties. Please take a look at the [ui-notification docs](https://dashboard.flowfuse.com/nodes/widgets/ui-notification.html#properties){rel="&#x22;nofollow&#x22;"} for more information on **ui-notification**.

!["Screenshot displaying ui-notification widgets configuration"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-notification-widget.png "Screenshot displaying ui-notification widgets configuration"){dataZoomable=""}*Screenshot displaying ui-notification widgets configuration*

### Listening for events

In Dashboard 2.0, the **ui-event** widget allows you to listen to user behavior or events. It does not render any content or components on the dashboard. Currently, this widget only listens for page views (`$pageview`) and leave (`$pageleave`) events.

With this, we can listen for page view and page leave events and trigger tasks based on those events. For instance, in our application, we will be displaying a table containing income and expense data, along with a chart. We'll update them when navigating to a new page or leaving a page.

1. Drag an **ui-event** widget onto the canvas.
2. Double-click on it and select the correct **ui-base** of your application.

For more information on ui-event refer to [ui-event docs](https://dashboard.flowfuse.com/nodes/widgets/ui-event.html){rel="&#x22;nofollow&#x22;"}.

### Retrieving Income-Expense Data

In our income-expense application, we will display the income and expenses in a single table.

1. Drag a **change** node onto the canvas.
2. Set `msg.payload` to the JSONata expression below, which merges the income and expense arrays.

```javascript
[$globalContext('income'), $globalContext('expense')]
```

3. Connect the output of the **ui-event** widget to the input of the **change** node.

!["Screenshot displaying the change node setting JSON expression to payload for retrieving and sorting data."](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-change-node.png "Screenshot displaying the change node setting JSON expression to payload for retrieving and sorting data."){dataZoomable=""}&#x2A;Screenshot displaying the change node setting JSON expression to payload for retrieving and sorting data.*

### Displaying Data on the Table

To display data on the table, we use the **ui-table** widget in Dashboard 2.0. This widget accepts an array of objects as input. The columns in the table correspond to the properties of the objects within the array, and each row represents a different object with values corresponding to those properties.

1. Drag a **ui-table** widget onto the canvas.
2. Create a new **ui-page** and **ui-group** for it.
3. Connect the output of the **change** node to the input of the **ui-table** widget.

!["Screenshot displaying the ui-table widget configuration"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-table-widget.png "Screenshot displaying the ui-table widget configuration"){dataZoomable=""}*Screenshot displaying the ui-table widget configuration*

For more information on ui-table refer to [ui-table docs](https://dashboard.flowfuse.com/nodes/widgets/ui-table.html){rel="&#x22;nofollow&#x22;"}

### Calculating total category-wise

In our application, we will display data on the chart, showing the total income and total expenses for analysis. In this section, we will calculate the total expenses and income using the function node.

1. Drag the two **change** node onto the canvas.
2. For the first **Change** node Set `msg.payload` to `global.income` and `msg.topic` to "income" and give it name "retrive income". For the second **Change** node, set `msg.payload` to `global.expense` and `msg.topic` to "expense" and give that second change node name "retrive expense".

!["Screenshot displaying the change node retrieving income data from global context"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-chart-widget-retrieve-income-change-node.png "Screenshot displaying the change node retrieving income data from global context"){dataZoomable=""}*Screenshot displaying the change node retrieving income data from global context*

!["Screenshot displaying the change node retrieving expense data from global context"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-chart-widget-retrieve-expense-change-node.png "Screenshot displaying the change node retrieving expense data from global context"){dataZoomable=""}*Screenshot displaying the change node retrieving expense data from global context*

3. Drag a **Split** node onto the canvas.
4. Drag the **Change** node onto the canvas and set `msg.payload.amount` to the JSONata expression `$number(payload.amount)` and give it name "Convert amount to number".

!["Screenshot displaying the change node converting amount to number"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-chart-widget-convert-amount-to-number-change-node.png "Screenshot displaying the change node converting amount to number"){dataZoomable=""}*Screenshot displaying the change node converting amount to number*

5. Drag a **Join** node onto the canvas, select mode as **reduced expression**, and set the **Reduce exp** to `$A + payload.amount`. Set Initial value to `0`, and **Fix-up exp** to `$A`. Give this **join** node the name "Calculate total". This function operates similarly to using the javascript reduce method on an array to calculate the sum of its values. `$A` stores the accumulated value, and with every incoming message payload, it adds the `payload.amount` value to it, for more details on this refer to the [core node docs on join node](https://flowfuse.com/node-red/core-nodes/join/).

!["Screenshot displaying the join node calculating the total income and expense data"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-chart-widget-calculate-total-join-node.png "Screenshot displaying the join node calculating the total income and expense data"){dataZoomable=""}*Screenshot displaying the join node calculating the total income and expense data*

7. Drag an another join node onto the canvas set mode to manual, combine each to complete message, to create to array and After a number of message parts to 2 and give it name "combine two objects into array".

!["Screenshot displaying the join node combining the income and expense object into the array"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-chart-widget-retrieve-combine-object-join-node.png "Screenshot displaying the join node combining the income and expense object into the"){dataZoomable=""}*Screenshot displaying the join node combining the income and expense object into the array*

7. Connect the output of the **ui-event** widget to the input of the **Change** node named "Retrieve Income" and "Retrieve Expense". Then, connect the outputs of the "Retrieve Income" and "Retrieve Expense" **Change** nodes to the input of the **Split** node.
8. Next, connect the output of the **Split** node to the **Change** node named "Convert Amount to Number". Afterward, connect the output of that **Change** node to the input of the **Join** node named "Calculate Total". Finally, connect the output of the "Calculate Total" **Join** node to the input of the **Join** node named "Combine Objects into Array".

### Displaying data on the chart

To display charts on the dashboard, we have to use the ui-chart widget which allows us to display different types of charts on a dashboard including linear, bar, scatter, etc. This accepts an array and object as input.

1. Drag a **ui-chart** widget onto the canvas.
2. Double-click on the widget and select Type as **bar**.
3. Configure the series to **category** and the y-axis to **amount**. This configuration informs the chart that the **amount** property of the input objects will be plotted on the y-axis and category to the x-axis of the chart.
4. Connect the output of the **join** node named "Combine Objects into Array" to the **ui-chart** widget's input.

!["Screenshot displaying the ui-chart widget's configuration"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-chart-widget.png "Screenshot displaying the ui-chart widget's configuration"){dataZoomable=""}*Screenshot displaying the ui-chart widget's configuration*

### Adding custom footer with ui-template

With the **ui-template** widget, we can add a custom component to our app using Vue.js. It also allows adding custom CSS for the dashboard and lot of other things. For more information refer to [ui-template docs](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html){rel="&#x22;nofollow&#x22;"}.

Using this widget, we will add a footer to our application.

1. Drag an **ui-template** widget onto the canvas.
2. Set the widget type (scoped UI) that will render this widget on the entire dashboard, eliminating the need to add separate footers for each page of the dashboard.
3. Insert the following vue.js code in the **ui-template** widget.

```javascript
<template>
  <!-- Footer Component -->
  <div class="footer">
    <!-- Description of the Income-Expense Tracker -->
    <div>
      Welcome to our comprehensive income expense tracker! Take control of your finances by monitoring your income and
      expenses effortlessly. Our user-friendly interface makes it simple to record transactions, categorize expenses, and
      analyze your financial trends. With real-time insights into your spending habits, you can make smarter financial
      decisions and achieve your money goals faster.
    </div>
    <!-- Copyright Information -->
    <div class="copyright">
      <!-- Display Current Year and Copyright Information -->
      2024, <strong>Vuetify</strong>
    </div>
  </div>
</template>
<style scoped>
  /* Make the footer occupy all available space */
  .footer {
    position:absolute;
    bottom:0;
    background-color:rgb(26,26,26);
    color:rgb(238,238,238);
    height:130px;
    text-align:center;
    padding:14px;
  }

  .copyright{
    margin-top:10px;
  }
</style>
```

!["Screenshot displaying the ui-template widget's configuration"](https://flowfuse.com/blog/2024/05/images/exploring-dashboard-2-widgets-template-widget.png "Screenshot displaying the ui-template widget's configuration"){dataZoomable=""}

### Deploying your application flow

::render-flow{:height='450'}
```json
[{"id":"301c1fd8e29c3aae","type":"ui-template","z":"7ac3890dfa74703b","group":"","page":"","ui":"a0a85a5f4c29af50","name":"Footer","order":0,"width":0,"height":0,"head":"","format":"<template>\n  <!-- Footer Component -->\n  <div class=\"footer\">\n    <!-- Description of the Income-Expense Tracker -->\n    <div>\n      Welcome to our comprehensive income expense tracker! Take control of your finances by monitoring your income and\n      expenses effortlessly. Our user-friendly interface makes it simple to record transactions, categorize expenses,\n      and\n      analyze your financial trends. With real-time insights into your spending habits, you can make smarter financial\n      decisions and achieve your money goals faster.\n    </div>\n    <!-- Copyright Information -->\n    <div class=\"copyright\">\n      <!-- Display Current Year and Copyright Information -->\n     2024, <strong>Vuetify</strong>\n    </div>\n  </div>\n</template>\n\n<style scoped>\n  /* Make the footer occupy all available space */\n  .footer {\n    position: absolute;\n    bottom: 0;\n    background-color: rgb(26, 26, 26);\n    color: rgb(238, 238, 238);\n    height: 130px;\n    text-align: center;\n    padding: 14px;\n  }\n\n  .copyright {\n    margin-top: 10px;\n  }\n</style>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"widget:ui","className":"","x":910,"y":700,"wires":[[]]},{"id":"342f3ee215d32fdc","type":"group","z":"7ac3890dfa74703b","name":"New Icome page","style":{"label":true},"nodes":["d028c878350d19e1","43e79bb77d718c95","5ba5d8bff1a77bea"],"x":274,"y":279,"w":752,"h":82},{"id":"d028c878350d19e1","type":"ui-form","z":"7ac3890dfa74703b","g":"342f3ee215d32fdc","name":"Income Submission Form","group":"961528943e1bb698","label":"","order":1,"width":"0","height":"0","options":[{"label":"Date","key":"date","type":"date","required":true,"rows":null},{"label":"Description","key":"description","type":"text","required":true,"rows":null},{"label":"Amount","key":"amount","type":"number","required":true,"rows":null},{"label":"Note","key":"note","type":"text","required":false,"rows":null}],"formValue":{"date":"","description":"","amount":"","note":""},"payload":"","submit":"submit","cancel":"clear","resetOnSubmit":true,"topic":"topic","topicType":"msg","splitLayout":"","className":"","x":410,"y":320,"wires":[["5ba5d8bff1a77bea"]]},{"id":"43e79bb77d718c95","type":"ui-notification","z":"7ac3890dfa74703b","g":"342f3ee215d32fdc","ui":"a0a85a5f4c29af50","position":"center center","colorDefault":true,"color":"#000000","displayTime":"3","showCountdown":true,"outputs":0,"allowDismiss":true,"dismissText":"Close","raw":false,"className":"","name":"","x":910,"y":320,"wires":[]},{"id":"5ba5d8bff1a77bea","type":"function","z":"7ac3890dfa74703b","g":"342f3ee215d32fdc","name":"Store income","func":"let income = global.get('income') || [];\n\nincome.push({\n    ...msg.payload,\n    type:\"income\",\n});\n\nglobal.set('income', income);\n\nmsg.payload = \"Thank you for submitting income!\"\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":650,"y":320,"wires":[["43e79bb77d718c95"]]},{"id":"961528943e1bb698","type":"ui-group","name":"Income Submission Form","page":"d954d73f9dcd1472","width":"12","height":"1","order":1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"d954d73f9dcd1472","type":"ui-page","name":"New Income","ui":"a0a85a5f4c29af50","path":"/new-Icome","icon":"bank-transfer-in","layout":"notebook","theme":"aeeec3fc1077eb1c","order":1,"className":"","visible":"true","disabled":"false"},{"id":"aeeec3fc1077eb1c","type":"ui-theme","name":"dashboard","colors":{"surface":"#1a1a1a","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"4afb4814be56a9a8","type":"group","z":"7ac3890dfa74703b","name":"New Expense page","style":{"label":true},"nodes":["e82b719d899cbf73","3457848652ad75e1","bd90a9ad612408d3"],"x":1054,"y":279,"w":752,"h":82},{"id":"e82b719d899cbf73","type":"ui-form","z":"7ac3890dfa74703b","g":"4afb4814be56a9a8","name":"Expense Submission Form","group":"854706651cd8a8f2","label":"","order":1,"width":"12","height":"1","options":[{"label":"Date","key":"date","type":"date","required":true,"rows":null},{"label":"Description","key":"description","type":"text","required":true,"rows":null},{"label":"Category","key":"category","type":"text","required":true,"rows":null},{"label":"Amount","key":"amount","type":"number","required":true,"rows":null},{"label":"Note","key":"note","type":"text","required":false,"rows":null}],"formValue":{"date":"","description":"","category":"","amount":"","note":""},"payload":"","submit":"submit","cancel":"clear","resetOnSubmit":true,"topic":"topic","topicType":"msg","splitLayout":"","className":"","x":1190,"y":320,"wires":[["bd90a9ad612408d3"]]},{"id":"3457848652ad75e1","type":"ui-notification","z":"7ac3890dfa74703b","g":"4afb4814be56a9a8","ui":"a0a85a5f4c29af50","position":"center center","colorDefault":true,"color":"#000000","displayTime":"3","showCountdown":true,"outputs":0,"allowDismiss":true,"dismissText":"Close","raw":false,"className":"","name":"","x":1690,"y":320,"wires":[]},{"id":"bd90a9ad612408d3","type":"function","z":"7ac3890dfa74703b","g":"4afb4814be56a9a8","name":"Store expense","func":"let expense = global.get('expense') || [];\n\nexpense.push({\n    ...msg.payload,\n    type: \"expense\",\n});\n\nglobal.set('expense', expense);\n\nmsg.payload = \"Thank you for submitting expense!\"\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1420,"y":320,"wires":[["3457848652ad75e1"]]},{"id":"854706651cd8a8f2","type":"ui-group","name":"Expense Submission Form","page":"97bf3e87f4bdddc1","width":"12","height":"1","order":2,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"97bf3e87f4bdddc1","type":"ui-page","name":"New Expense","ui":"a0a85a5f4c29af50","path":"/new-expense","icon":"bank-transfer-out","layout":"notebook","theme":"aeeec3fc1077eb1c","order":2,"className":"","visible":"true","disabled":"false"},{"id":"77217e256ef75328","type":"group","z":"7ac3890dfa74703b","name":"Your icome and expense table","style":{"label":true},"nodes":["452d561bf79727cb","0c64567c81dd6a8d"],"x":274,"y":399,"w":572,"h":82},{"id":"452d561bf79727cb","type":"ui-table","z":"7ac3890dfa74703b","g":"77217e256ef75328","group":"e848a5e48a6549c9","name":"","label":"text","order":2,"width":0,"height":0,"maxrows":0,"passthru":false,"autocols":true,"selectionType":"click","columns":[],"x":770,"y":440,"wires":[[]]},{"id":"0c64567c81dd6a8d","type":"change","z":"7ac3890dfa74703b","g":"77217e256ef75328","name":"Merge income and expense data","rules":[{"t":"set","p":"payload","pt":"msg","to":"[    $globalContext(\"income\"),\t   $globalContext(\"expense\")\t]","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":440,"y":440,"wires":[["452d561bf79727cb"]]},{"id":"e848a5e48a6549c9","type":"ui-group","name":"Your Income and Expense","page":"7abf0b3cb6f38ca3","width":"12","height":"5","order":2,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"7abf0b3cb6f38ca3","type":"ui-page","name":"Your Income and expense","ui":"a0a85a5f4c29af50","path":"/your-icome-expense","icon":"calendar-multiple-check","layout":"grid","theme":"aeeec3fc1077eb1c","order":3,"className":"","visible":"true","disabled":"false"},{"id":"1b78769d6d27d102","type":"group","z":"7ac3890dfa74703b","name":"Event lister","style":{"label":true},"nodes":["9ce6db04b2c9d7b2"],"x":74,"y":479,"w":152,"h":82},{"id":"9ce6db04b2c9d7b2","type":"ui-event","z":"7ac3890dfa74703b","g":"1b78769d6d27d102","ui":"a0a85a5f4c29af50","name":"","x":150,"y":520,"wires":[["0c64567c81dd6a8d","2ca552c7e56b3619","a7360e4a62bfc518"]]},{"id":"32502807f24f79b8","type":"group","z":"7ac3890dfa74703b","name":"Overview chart","style":{"label":true},"nodes":["424b35900722e740","058a77a65653d3f8","7246228e57ac1fc5","2ca552c7e56b3619","23a4a7d15b44876b","a7360e4a62bfc518","fe308581b8a5b9f1"],"x":274,"y":519,"w":1392,"h":142},{"id":"424b35900722e740","type":"ui-chart","z":"7ac3890dfa74703b","g":"32502807f24f79b8","group":"54eca83feb7c1479","name":"Overview Chart","label":"chart","order":2,"chartType":"bar","category":"topic","categoryType":"property","xAxisProperty":"","xAxisPropertyType":"msg","xAxisType":"category","yAxisProperty":"payload","ymin":"","ymax":"","action":"replace","pointShape":"circle","pointRadius":4,"showLegend":false,"removeOlder":1,"removeOlderUnit":"3600","removeOlderPoints":"","colors":["#1eb33c","#aec7e8","#ff7f0e","#5f2ed1","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"width":"12","height":"6","className":"","x":1560,"y":600,"wires":[[]]},{"id":"058a77a65653d3f8","type":"join","z":"7ac3890dfa74703b","g":"32502807f24f79b8","name":"Calculate total","mode":"reduce","build":"object","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":true,"timeout":"","count":"","reduceRight":false,"reduceExp":"$A+payload.amount","reduceInit":"0","reduceInitType":"num","reduceFixup":"$A","x":1000,"y":600,"wires":[["fe308581b8a5b9f1"]]},{"id":"7246228e57ac1fc5","type":"split","z":"7ac3890dfa74703b","g":"32502807f24f79b8","name":"","splt":"\\n","spltType":"str","arraySplt":1,"arraySpltType":"len","stream":false,"addname":"","x":550,"y":600,"wires":[["23a4a7d15b44876b"]]},{"id":"2ca552c7e56b3619","type":"change","z":"7ac3890dfa74703b","g":"32502807f24f79b8","name":"Retrieve income","rules":[{"t":"set","p":"payload","pt":"msg","to":"income","tot":"global"},{"t":"set","p":"topic","pt":"msg","to":"income","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":380,"y":560,"wires":[["7246228e57ac1fc5"]]},{"id":"23a4a7d15b44876b","type":"change","z":"7ac3890dfa74703b","g":"32502807f24f79b8","name":"Convert amount to number","rules":[{"t":"set","p":"payload.amount","pt":"msg","to":"$number(payload.amount)\t","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":760,"y":600,"wires":[["058a77a65653d3f8"]]},{"id":"a7360e4a62bfc518","type":"change","z":"7ac3890dfa74703b","g":"32502807f24f79b8","name":"Retrieve income","rules":[{"t":"set","p":"payload","pt":"msg","to":"expense","tot":"global"},{"t":"set","p":"topic","pt":"msg","to":"expense","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":380,"y":620,"wires":[["7246228e57ac1fc5"]]},{"id":"fe308581b8a5b9f1","type":"join","z":"7ac3890dfa74703b","g":"32502807f24f79b8","name":"Combine two object into one array","mode":"custom","build":"array","property":"","propertyType":"full","key":"topic","joiner":"\\n","joinerType":"str","accumulate":false,"timeout":"","count":"2","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":1270,"y":600,"wires":[["424b35900722e740"]]},{"id":"54eca83feb7c1479","type":"ui-group","name":"Overview","page":"47bde79e946933d2","width":"12","height":"4","order":-1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"47bde79e946933d2","type":"ui-page","name":"Overview","ui":"a0a85a5f4c29af50","path":"/overview","icon":"google-analytics","layout":"notebook","theme":"aeeec3fc1077eb1c","order":-1,"className":"","visible":"true","disabled":"false"},{"id":"a0a85a5f4c29af50","type":"ui-base","name":"Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control","ui-chart","ui-table"],"showPathInSidebar":false,"navigationStyle":"icon"}]
```
::

1. Deploy the flow by clicking the top right **Deploy** button.
2. Locate the \***Open Dashboard** button at the top-right corner of the Dashboard 2.0 sidebar and click on it to navigate to the dashboard.

Now that we've built an income-expense tracker application and gained a basic understanding of Dashboard 2.0 widgets for building dashboards.

### Up next

If you want to enhance this simple application by adding more features or want to make the application personalize for users, consider the following resources:

- [Webinar](https://flowfuse.com/webinars/2024/node-red-dashboard-multi-user/) - This webinar provides an in-depth discussion of the Personalised Multi-User Dashboards feature and offers guidance on how to get started with it.
- [Comprehensive guide: Node-RED Dashboard 2.0 layout, sidebar, and styling](https://flowfuse.com/blog/2024/05/node-red-dashboard-2-layout-navigation-styling/) - This comprehensive guide will cover everything about Node-RED Dashboard 2.0 styling, layouts and sidebars.
- [Displaying logged-in users on Dashboard 2.0](https://flowfuse.com/blog/2024/04/displaying-logged-in-users-on-dashboard/) - This detailed guide demonstrates how to display logged-in users on Dashboard 2.0 which using the FlowFuse Multiuser addon and FlowFuse.
- [How to Build an Admin Dashboard with Node-RED Dashboard 2.0](https://flowfuse.com/blog/2024/04/building-an-admin-panel-in-node-red-with-dashboard-2/) - This detailed guide demonstrates how to build a secure admin page in Node-RED Dashboard 2.0.
- [How to Build An Application With Node-RED Dashboard 2.0](https://flowfuse.com/blog/2024/04/how-to-build-an-application-with-node-red-dashboard-2/) - This guide, covers how you can build personalize multiuser dashboard using flow fuse multi-user addon.
- [Multi-User Dashboard for Ticket/Task Management blueprint](https://flowfuse.com/blueprints/flowfuse-dashboard/multi-user-dashboard/) - this blueprint allows you to utilize templates to develop a personalized multi-user dashboard quickly. This Task management blueprint has all features such as adding, updating, and deleting tasks, user profiles, and admin dashboard.


# FlowFuse 2.4: making it easier to work with Snapshots, Blueprints & Devices

FlowFuse 2.4 introduces better ways to work with Snapshots, Blueprints, view the content of you flows in FlowFuse, and manage the version of Node-RED running on Devices

## Export Snapshots from FlowFuse [#3627](https://github.com/FlowFuse/flowfuse/issues/3627){rel="&#x22;nofollow&#x22;"}

You can now export your Snapshots of your Node-RED instances. This is our first step towards making it easier to move Snapshots in and out or your FlowFuse projects, as well as share them with other teams. We will be adding many more Snapshot management features over the next few releases.

## Easier creation of Node-RED instances from Blueprints [#3729](https://github.com/FlowFuse/flowfuse/issues/3729){rel="&#x22;nofollow&#x22;"}

We introduced our library of Node-RED [Blueprints](https://flowfuse.com/blog/2023/10/blueprints/) in October 2023. FlowFuse Blueprints aim to make the Node-RED experience more accessible for newcomers, while also offering a treasure trove of fresh ideas for seasoned Node-RED users. In this release, we are making it even easier to start a new Node-RED instance based on a Blueprint from our library.

## View Flows within the Team Library without loading Node-RED [#3803](https://github.com/FlowFuse/flowfuse/issues/3803){rel="&#x22;nofollow&#x22;"}

In September 2023, Node-RED community member [gorenje](https://github.com/gorenje){rel="&#x22;nofollow&#x22;"} created some code that could be used to visualise Node-RED flows without having to load the full Node-RED editor. This was added to the community [flow library](https://flowfuse.com/blog/2023/09/flow-viewer/) and has proven to be a great addition.

With gorenje's support, we've packaged up his library to make it easier to embed in other sites and have made it generally available [here](https://github.com/FlowFuse/flow-renderer){rel="&#x22;nofollow&#x22;"}. A big thanks to gorenje for laying the ground work and allow us to build on it.

We've wasted no time putting this to good use within FlowFuse. Our first step is in our [Team Library](https://flowfuse.com/changelog/2024/05/library-flowviewer/). You can now view a visual representation of saved flows in your Team Library.

## View Flows within Snapshots without loading Node-RED [#3798](https://github.com/FlowFuse/flowfuse/issues/3798){rel="&#x22;nofollow&#x22;"}

The second place we are adding the ability to preview flows is to the Snapshots interface. Again, based on [node-red-flowviewer-js](https://github.com/gorenje/node-red-flowviewer-js){rel="&#x22;nofollow&#x22;"}, the Flow Viewer will make loading the snapshot you need into your Node-RED instance quicker and easier.

## Manage Node-RED versions on Devices [#3766](https://github.com/FlowFuse/flowfuse/pull/3766){rel="&#x22;nofollow&#x22;"}

It can be useful to select a specific version of Node-RED to run, for example where you are using a custom node which only runs on specific versions of Node-RED. In this release we have added the ability to easily select the version of Node-RED you wish to run on your devices.

## Full list of release features and bug fixes

You can view everything included in 2.4 on the [Github Release page](https://github.com/FlowFuse/flowfuse/releases/tag/v2.4.0){rel="&#x22;nofollow&#x22;"}.

We also regularly release updates to \[FlowFuse Cloud]\({{ site.appURL }}) in between our monthly releases. You can follow the updates as they are made via our [ChangeLog](https://flowfuse.com/changelog).

## What's next?

We're always working to enhance your experience with FlowFuse. Here's how you can stay informed and contribute:

- **Roadmap Overview**: Check out our [Product Roadmap Page](https://flowfuse.com/changelog/) to see what we're planning for future updates.
- **Entire Roadmap**: Visit our [Roadmap on GitHub](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"} to follow our progress and contribute your ideas.
- **Feedback**: We're interested in your thoughts about FlowFuse. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try it out

We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 2.4.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go to the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# Mapping location data within Node-RED Dashboard 2.0. (2026)

Fleet management in IoT uses sensors and software to collect real-time data on vehicles, such as location, fuel consumption, and driver behavior. This data allows companies to optimize routes, reduce costs, improve safety, and enhance overall operational efficiency of their fleet. Building an application that allows the tracking of location to support Fleet management is what this post is about.

Before moving further, make sure you have installed Dashboard 2.0. If you are new to Dashboard 2.0, please refer to [Getting Started with Dashboard 2.0](https://flowfuse.com/blog/2024/03/dashboard-getting-started/) for more information.

## Installing world map custom node

To render an interactive world map webpage for plotting location data, we will use a popular custom node called [node-red-contrib-web-worldmap-page](https://flows.nodered.org/node/node-red-contrib-web-worldmap){rel="&#x22;nofollow&#x22;"}. This node offers extensive features enabling us to render a world map and plot various items with different icons, colors, NATO symbologies, ranges, and more.

1. Click the Node-RED Settings (top-right).
2. Click "Manage Palette".
3. Switch to the "Install" tab.
4. Search for `node-red-contrib-web-worldmap`.
5. Click "Install".

## Retrieving location Data

Before plotting locations, we need to obtain the data first. For this purpose, we will utilize the [Edenburg Open Public Transportation API](https://tfe-opendata.readme.io/docs/getting-started){rel="&#x22;nofollow&#x22;"}. This API provides the live locations of all of Edenburg's public buses and trams, enabling us to access the necessary data for plotting on Worldmap within Dashboard 2.0.

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

1. Drag an **Inject** node onto the canvas and set the repeat property to a 20-second interval.
2. Drag an HTTP request node onto the canvas, Dobule-click on it and choose **GET** method, and enter `https://tfe-opendata.com/api/v1/vehicle_locations` in the URL field and select return as **a parsed json object**. This API is public, so no need for environment variables. For private APIs, consider using [environment variables](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red) for security.

!["Screenshot of the HTTP request node configuration for retrieving data from the API"](https://flowfuse.com/blog/2024/05/images/mapping-location-on-dashboard-2-http-request-node.png "Screenshot of the HTTP request node configuration for retrieving data from the API"){dataZoomable=""}

3. Connect the **Inject** node's output to the **HTTP request** node's input.

## Formatting Location Data

To ensure compatibility with the Worldmap custom node, we need to format the location data appropriately.

1. Drag the **Change** node onto the canvas, and set the `msg.payload` to `msg.payload.vehicles`, and give it name **Set payload**.

![Screenshot of the Change node setting the payload to the vehicles JSON array containing actual vehicle location data](https://flowfuse.com/blog/2024/05/images/mapping-location-on-dashboard-2-change-node.png "Screenshot of the Change node setting the payload to the vehicles JSON array containing actual vehicle location data"){dataZoomable=""}

2. Drag a **Split** node onto the canvas.
3. Add another **Change** node to the canvas. Configure it to set and delete properties as shown in the image below, and give it name **Change and delete properties**. By changing and deleting properties of the location, we ensure that only the properties acceptable by the **Worldmap** node are included in the location data.

![Screenshot of the Change node configuring properties to ensure compatibility with the Worldmap node](https://flowfuse.com/blog/2024/05/images/mapping-location-on-dashboard-2-change-node-changing-and-deleting-properties.png "Screenshot of the Change node configuring properties to ensure compatibility with the Worldmap node"){dataZoomable=""}

4. Drag a **Switch** node onto the canvas and add conditions to check if `msg.payload.vehicle_type` is equal to **tram** or not.

![Screenshot of the Switch node checking if the vehicle type is tram or not](https://flowfuse.com/blog/2024/05/images/mapping-location-on-dashboard-2-switch-node-checking-is-vehicale-type-is-tram-or-not.png "Screenshot of the Switch node checking if the vehicle type is tram or not"){dataZoomable=""}

5. Add another **Change** node to the canvas and give it a name **set icon and icon color for tram**. Set `msg.payload.icon` to **fa-train** and `msg.payload.iconColor` to **yellow**.

![Screenshot of the Change node setting the icon and icon color for tram](https://flowfuse.com/blog/2024/05/images/mapping-location-on-dashboard-2-change-node-setting-icon-for-tram.png "Screenshot of the Change node setting the icon and icon color for tram"){dataZoomable=""}

7. Add another **Change** node to the canvas and give it a name **set icon and icon color for bus**. Set `msg.payload.icon` to **bus** and `msg.payload.iconColor` to **red**.

![Screenshot of the Change node setting the icon and icon color for bus](https://flowfuse.com/blog/2024/05/images/mapping-location-on-dashboard-2-change-node-setting-icon-for-bus.png "Screenshot of the Change node setting the icon and icon color for bus"){dataZoomable=""}

8. Connect the **HTTP request** node's output to the input of the **Change** node named **Set payload**, and connect the output of that **Change** node to the input of the **Split** node.
9. Then, connect the output of the **Split** node to the input of the **Change** node named **Change and delete properties**, and connect the output of the "Change and delete properties" node to the input of the **Switch** node. Then **Switch** node's first output to the input of the **Change** node named **set icon and icon color for tram**, and its second output to the input of the **Change** node named **set icon and icon color for bus**.

## Plotting location data on Worldmap

1. Drag a **Worldmap*&#x2A; node onto the canvas. Set the path to **/worldmap** and keep the rest of the settings unchanged, although you can modify other properties according to your preferences.

!["Screenshot displaying the configuration of the Worldmap custom node"](https://flowfuse.com/blog/2024/05/images/mapping-location-on-dashboard-2-worldmap-node.png "Screenshot displaying the configuration of the Worldmap custom node"){dataZoomable=""}

2. With the **worldmap** node configured, it will generate a world map with plotted data accessible at the specified path.
3. Connect the **Function** node's output to **Worldmap** node's input.

Now we have successfully created a page with a world map displaying plotted vehicle location data. To confirm, you can visit `https://<your-instance-name>.flowfuse.cloud/worldmap`.

## Rendering map on Dashboard 2.0

To render worlmap webpage on dashboard 2.0 we will use **iframe** custom widget which will allow us to embed an external webpage into Dashboard 2.0 applications using an iframe.

### Installing iframe custom widget

1. Click the Node-RED Settings (top-right)
2. Click **Manage Palette**
3. Switch to the **Install** tab
4. Search for `@flowfuse/node-red-dashboard-2-ui-iframe`
5. Click **Install**

### Rendering worlmap on Dashboard 2.0

1. Drag an **iframe** widget onto the canvas.
2. Select **ui-group** and **ui-base** for it, where you want to render the webpage.
3. Set height and width for it according to your preference and set URL to **/worlmap**.

!["Screenshot showing configurations of iframe widget for rendering worlmap page on dashboard"](https://flowfuse.com/blog/2024/05/images/mapping-location-on-dashboard-2-iframe-widget.png "Screenshot showing configurations of iframe widget for rendering worlmap page on dashboard"){dataZoomable=""}

## Deploying the flow

:video{ariaLabel="Video displaying live locations of UK public transport on the dashboard" autoPlay="true" height="480" loop="true" muted="true" playsInline="true" preload="none" width="853"}

::render-flow
```json
[{"id":"4e45e8ef870b86fb","type":"group","z":"eacc68e72f120b0e","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["b6917d83.d1bac","3842171.4d487e8","b4f2e2dabd5b8220","5f0d149d4dc38916","2ff7e9501ad50cd5","a08f0a836ac412a7","bc891dc2aaaedc39","726a8da3fe930e54","b3dd7814ea5270ca","0c5d6bcfd71d40da","e037ee3d1f702d25","d7ca6c3cdf176e4e"],"x":814,"y":759,"w":1872,"h":322},{"id":"b6917d83.d1bac","type":"http request","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"","method":"GET","ret":"obj","paytoqs":"ignore","url":"https://tfe-opendata.com/api/v1/vehicle_locations","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":1190,"y":900,"wires":[["a08f0a836ac412a7"]]},{"id":"3842171.4d487e8","type":"inject","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"get transporatation data","props":[{"p":"payload"}],"repeat":"5","crontab":"","once":false,"onceDelay":"","topic":"","payload":"","payloadType":"str","x":970,"y":900,"wires":[["b6917d83.d1bac"]]},{"id":"b4f2e2dabd5b8220","type":"worldmap","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"worldmap","lat":"","lon":"","zoom":"","layer":"OSMG","cluster":"","maxage":"","usermenu":"show","layers":"show","panit":"false","panlock":"false","zoomlock":"false","hiderightclick":"false","coords":"mgrs","showgrid":"false","showruler":"false","allowFileDrop":"false","path":"/worldmap","overlist":"DR,CO,RA,DN","maplist":"OSMG,OSMC,EsriC,EsriS,UKOS","mapname":"","mapurl":"","mapopt":"","mapwms":false,"x":2600,"y":900,"wires":[]},{"id":"5f0d149d4dc38916","type":"comment","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"Retrieving, formatting, and plotting location data on a world map.","info":"","x":1390,"y":800,"wires":[]},{"id":"2ff7e9501ad50cd5","type":"comment","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"Rendering a map with plotted data on Dashboard 2.0.","info":"","x":1440,"y":980,"wires":[]},{"id":"a08f0a836ac412a7","type":"change","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"Set payload","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.vehicles","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1390,"y":900,"wires":[["726a8da3fe930e54"]]},{"id":"bc891dc2aaaedc39","type":"change","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"Change and delete properties","rules":[{"t":"set","p":"payload.lat","pt":"msg","to":"payload.latitude","tot":"msg"},{"t":"delete","p":"payload.latitude","pt":"msg"},{"t":"set","p":"payload.lon","pt":"msg","to":"payload.longitude","tot":"msg"},{"t":"delete","p":"payload.longitude","pt":"msg"},{"t":"set","p":"payload.color","pt":"msg","to":"blue","tot":"str"},{"t":"set","p":"payload.name","pt":"msg","to":"payload.vehicle_id","tot":"msg"},{"t":"delete","p":"payload.vehicle_id","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1770,"y":900,"wires":[["b3dd7814ea5270ca"]]},{"id":"726a8da3fe930e54","type":"split","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"","splt":"\\n","spltType":"str","arraySplt":1,"arraySpltType":"len","stream":false,"addname":"","x":1550,"y":900,"wires":[["bc891dc2aaaedc39"]]},{"id":"b3dd7814ea5270ca","type":"switch","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"is vehical type is tram","property":"payload.vehicle_type","propertyType":"msg","rules":[{"t":"eq","v":"tram","vt":"str"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":2040,"y":900,"wires":[["0c5d6bcfd71d40da"],["e037ee3d1f702d25"]]},{"id":"0c5d6bcfd71d40da","type":"change","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"set icon and icon color for tram","rules":[{"t":"set","p":"payload.icon","pt":"msg","to":"fa-train","tot":"str"},{"t":"set","p":"payload.iconColor","pt":"msg","to":"yellow","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":2310,"y":860,"wires":[["b4f2e2dabd5b8220"]]},{"id":"e037ee3d1f702d25","type":"change","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"set icon and icon color for bus","rules":[{"t":"set","p":"payload.icon","pt":"msg","to":"bus","tot":"str"},{"t":"set","p":"payload.iconColor","pt":"msg","to":"red","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":2310,"y":940,"wires":[["b4f2e2dabd5b8220"]]},{"id":"d7ca6c3cdf176e4e","type":"ui-iframe","z":"eacc68e72f120b0e","g":"4e45e8ef870b86fb","name":"","group":"15d2dfa55e99ea43","order":0,"src":"/worldmap","width":"12","height":"10","x":1370,"y":1040,"wires":[]},{"id":"15d2dfa55e99ea43","type":"ui-group","name":"U.K Transportation Live","page":"e098e3047b4a4eaa","width":"12","height":"1","order":-1,"showTitle":false,"className":"","visible":"true","disabled":"false"},{"id":"e098e3047b4a4eaa","type":"ui-page","name":"U.K Transportation Live","ui":"c2e1aa56f50f03bd","path":"/worldmap","icon":"earth","layout":"grid","theme":"129e99574def90a3","order":-1,"className":"","visible":"true","disabled":"false"},{"id":"c2e1aa56f50f03bd","type":"ui-base","name":"Dashboard","path":"/dashboard","showPathInSidebar":false,"navigationStyle":"default"},{"id":"129e99574def90a3","type":"ui-theme","name":"Another Theme","colors":{"surface":"#000000","primary":"#ff4000","bgPage":"#f0f0f0","groupBg":"#ffffff","groupOutline":"#d9d9d9"},"sizes":{"pagePadding":"9px","groupGap":"12px","groupBorderRadius":"9px","widgetGap":"6px"}}]
```
::

1. With your flow updated to include the above, click the **Deploy** button in the top-right of the Node-RED Editor.
2. Locate the **Open Dashboard** button at the top-right corner of the Dashboard 2.0 sidebar and click on it to navigate to the dashboard.

Now you can view the live location of Edinburgh public transport vehicles on the dashboard. Additionally, clicking on each vehicle reveals further details such as its name, speed, and other properties you've included. Moreover, if you wish to track the live locations of your own vehicles instead of Edinburgh's public transport vehicles, you can connect your devices and access GPS and sensor data using the [Flowfuse device agent](https://flowfuse.com/platform/device-agent/).

## Conclusion

In conclusion, this guide shows an easy way to map location data on Dashboard 2.0. By following these steps, you can make interactive dashboards that give you real-time info, useful for things like managing fleets and tracking logistics.


# Comprehensive guide: Node-RED Dashboard 2.0 layout, sidebar, and styling

In this comprehensive guide, we will explore different layouts and sidebar styles in Dashboard 2.0. Additionally, we will cover how you can style Dashboard 2.0 elements effortlessly.

If you are new to Dashboard 2.0, refer to [Getting started with Node-RED Dashboard 2.0](https://flowfuse.com/blog/2024/03/dashboard-getting-started/) and make sure you have installed it.

## Understanding Dashboard 2.0 layouts.

A layout in Node-RED Dashboard 2.0 refers to how groups of widgets are organized and arranged on a page. It controls the visual structure and placement of these widget groups to create an organized and easy-to-use interface.

### Exploring Dashboard 2.0 layouts

In Dashboard 2.0, we have three types of layouts: Grid, Notebook, and Fixed.

#### Grid layout

Choosing this layout divides your dashboard page into **12 equally-sized columns**, and you can specify how many columns your group will occupy using the `size` property. When groups within a row take up all available columns, a new row automatically starts. The height of each row is determined by the tallest widget in that row.

!["Screenshot of dashboard having grid layout"](https://flowfuse.com/blog/2024/05/images/node-red-dashboard-2-layout-navigation-styling-grid-layout.jpg "Screenshot of dashboard having grid layout"){dataZoomable=""}

In the image above, you can see that the first and last widget groups occupy all 12 columns, while in the middle, two groups each take up six columns.

#### Notebook layout

Choosing the Notebook layout for your page in Dashboard 2.0 makes it work like a Jupyter Notebook, fixed at a width of **1024px** and **centered**. Here, a groups' "width" defines the number of columns the group contains. The group itself will always render the full width of the Notebook. It's great for dynamic Markdown, data tables, and visuals. Groups of pages are stacked vertically.

!["Screenshot of dashboard having notebook layout"](https://flowfuse.com/blog/2024/05/images/node-red-dashboard-2-layout-navigation-styling-notebook-layout.png "Screenshot of dashboard having notebook layout"){dataZoomable=""}

#### Fixed layout

In this layout, the width value is converted to "units", with each unit being `90px` wide. For example, if you set the group width to `3`, it will be 3 \* 90 = 270px wide. Within a given group, the group size represents a column in the group's internal grid, following the same pattern as other layouts.

!["Screenshot of dashboard having fixed layout"](https://flowfuse.com/blog/2024/05/images/node-red-dashboard-2-layout-navigation-styling-fix-layout.png "Screenshot of dashboard having fixed layout"){dataZoomable=""}

*Note: Currently this layout is not optimised, with plans to make it similar to Dashboard 1.0 in how it compresses content vertically, so it is recommended to use other layouts.*

### Setting page layout

1. Navigate to the page configuration by clicking on the **edit** button of your page in the Dashboard 2.0 sidebar.
2. In the page configuration, you can select the preferred layout for that page within the layout field.

:video{ariaLabel="Video showing process of setting page layout" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

## Setting Dashboard 2.0 elements size

Setting the size for elements in Dashboard 2.0 is straightforward, but understanding the actual unit size in the size property can be a bit tricky.

It's important to note that the size of a single horizontal unit varies depending on the layout, but the vertical size of a single row is consistently **48px**.

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

## Sizing Widgets within a Group

In any layout (Grid, Notebook, or Fixed), widgets within a group are sized using a unified approach. The size property assigned to widgets determines their width within the group. Each unit in the size property represents a fraction of the group's total width. This width is determined by an internal grid established by the group.

### Widget Sizing

Widgets are sized relative to the number of columns in the internal grid. For example, if a group has 4 columns and two widgets, and the first widget is set to 1 width while the second to 3 width, the first widget will occupy 25% of the group's width, and the second widget will occupy 75%.

Regardless of the layout type, the concept of sizing widgets within a group remains consistent. Whether it's the grid, notebook, or fixed layout, the same principles apply, ensuring uniformity in widget layout and design.

###  Setting element size

To set the size of groups and widgets in Dashboard 2.0, follow these steps:

1. Go to the Dashboard 2.0 sidebar and click on the edit button next to the element you want to resize.
2. Adjust the size using the size property.

:video{ariaLabel="Video showing process of setting element size" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

## Understanding Dashboard 2.0 Theme

The theme is a collection of colors that control the look and feel of the widgets, groups, and other elements on the page.

In Dashboard 2.0, when adding a page ( ui-page ) we can specify which theme it will use. By default, we have one theme in Dashboard 2.0, we can add more themes using the Dashboard 2.0 side panel.

### Understanding theme properties

In the theme (`ui-theme`) configuration, there are two main sections:

- **Colors:** Specify colors for Navigation, primary elements, page background, group backgrounds, and outlines.
- **Sizing:** Define the gaps between groups, page padding, group outline radius, and gaps between widgets, all in pixels.

For additional information on the `ui-theme` settings, please refer to the [ui-theme documentation](https://dashboard.flowfuse.com/nodes/config/ui-theme.html){rel="&#x22;nofollow&#x22;"}.

### Setting a new page theme

1. Navigate to the Dashboard 2.0 sidebar and switch to the theme tab.
2. Click on the top-right “+theme” button to add a new theme.
3. After specifying colors and sizing click on the top right update button to save the theme.
4. Now switch to the layout tab and click on the edit button next to the page for which you want to set a new theme.
5. In the page config, select the newly added theme in the Theme field.

:video{ariaLabel="Video showing process of adding new theme" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

## Dashboard 2.0 Navigation

### Setting sidebar

1. Navigate to the Dashboard 2.0 sidebar in the Node-RED editor
2. Click on the "Edit Settings" button located at the top left side of the Dashboard 2.0 sidebar.
3. Select your preferred sidebar style from the "Style" field in the sidebar options section.

:video{ariaLabel="Video showing process of changing sidebar style" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

### Sidebar Navigation Options

In Dashboard 2.0, we have 5 different navigation options for your application.

#### Collapsing

This is the default sidebar, when it's opened, the page content adjusts to the width of the sidebar.

:video{ariaLabel="Video showing 'Collapsing' sidebar" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

You can see in the image above how the page content automatically adjusts when the sidebar is opened.

#### Fixed

In this type, the sidebar is always visible and fixed on the left side, and the top menu icon is hidden. The page content adjusts to the width of the sidebar.

!["Image showing 'Fixed' sidebar"](https://flowfuse.com/blog/2024/05/images/node-red-dashboard-2-layout-navigation-styling-fixed-layout.png "Image showing Fixed sidebar"){dataZoomable=""}

#### Collapse to icon

This type of sidebar is similar to the collapsible one, but when the sidebar is collapsed, you can still navigate through different pages as the page icons become visible.

:video{ariaLabel="Video showing 'Collapse to icon' sidebar" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

#### Apear over content

When the sidebar is opened, the page is partially covered by a transparent layer, and the sidebar appears on top of this layer

:video{ariaLabel="Video showing 'Appear over content' sidebar" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

In this type of sidebar, you can notice how the sidebar opens without affecting the width of the page content

#### Always hide

In this type, the sidebar is always hidden, and navigation between different pages can be achieved using the ui-control widget.

!["screenshot displaying searching for botFather bot for creating custom bot"](https://flowfuse.com/blog/2024/05/images/node-red-dashboard-2-layout-navigation-styling-always-hidden.png "screenshot displaying searching for botFather bot for creating custom bot"){dataZoomable=""}

## Customising your Dashboard 2.0 further

 
In Dashboard 2.0, we can add classes to almost all widgets, pages, and groups and style them using CSS.

### Adding classes

1. To add classes to your widget, page, or group, you'll need to open its configuration
2. Find the 'Class' field and enter your class.

!["Screenshot showing the class property input field"](https://flowfuse.com/blog/2024/05/images/node-red-dashboard-2-layout-navigation-styling-showing-class-property-feild.png "Screenshot showing the class property input field"){dataZoomable=""}

### Writing custom CSS

In Dashboard 2.0, the `ui-template` node allows you to write custom CSS for Dashboard 2.0.

In the template node, you can add CSS for two different scopes:

- **Single Page:** Selecting this allows you to specify CSS that is constrained to a single page of your dashboard.
- **All Pages:** Selecting this allows you to define CSS that will apply across your whole dashboard.

To define your own CSS:

1. Drag an ui-template widget onto the canvas.
2. Double-click on it and select the scope within the type field.
3. If you select the "CSS (Single Page)" type, you'll then need to select the `ui-page` to which your custom class definitions will apply. If you select the "CSS (All Pages)" type, then you'll need to select the `ui-base` that includes those pages to which you want to add styling.
4. Now you can write your custom CSS within the ui-template.

!["Image displaying the left side with the page and group where custom CSS has been applied, and the right side showcasing the UI-template with the corresponding CSS"](https://flowfuse.com/blog/2024/05/images/node-red-dashboard-2-layout-navigation-styling-adding-style.png "Image displaying the left side with the page and group where custom CSS has been applied, and the right side showcasing the UI-template with the corresponding CSS"){dataZoomable=""}

## Up Next

To delve deeper into Node-RED Dashboard 2.0, we recommend exploring the following resources:

- [FlowFuse Dashboard Articles](https://flowfuse.com/blog/dashboard/) - Collection of examples and guides written by FlowFuse.
- [Node-RED Dashboard 2.0 Documentation](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"} - Detailed information for each of the nodes available in Dashboard 2.0, as well as useful guides on building custom nodes and widgets of your own.
- [Node-RED Forums - Dashboard 2.0](https://discourse.nodered.org/tag/dashboard-2){rel="&#x22;nofollow&#x22;"} - The Node-RED forums are a great place to ask questions, share your projects and get help from the community.
- [Beginner Guide to a Professional Node-RED](https://flowfuse.com/ebooks/beginner-guide-to-a-professional-nodered/) - A free guide to an enterprise-ready Node-RED. Learn all about Node-RED history, securing your flows, and dashboard data visualization.


# The MIND stack with Node-RED and FlowFuse Dashboard 2.0

The [MING stack](https://flowfuse.com/blog/2023/02/ming-blog/) has gained significant popularity over the years as it built upon open-source projects. That has given way to many people leveraging this stack to build solutions upon in various different environments. The MING stack is composed of 4 main components, [MQTT](https://mosquitto.org/){rel="&#x22;nofollow&#x22;"}, [InfluxDB](https://www.influxdata.com/){rel="&#x22;nofollow&#x22;"}, [Node-RED](https://flowfuse.com/node-red/), and [Grafana](https://grafana.com/){rel="&#x22;nofollow&#x22;"}. Combined together are the 4 main pillars, data transportation, data storage, data transformation, and visualizations. With this, it requires the management of 4 different applications, which often reside on the same server, but not necessarily. With more moving parts, creates complexity.

## FlowFuse: Integrated IoT Deployment

With FlowFuse we have bundled up 3 of those 4. First and foremost, the FlowFuse platform deploys Node-RED in two main ways. A cloud based deployment and remote deployment with management from the FlowFuse platform. Part of this management piece leverage MQTT between the devices for management. Because of this we have a built in MQTT broker that allows for communication between Node-RED instance within the FlowFuse platform. Lastly, with the release of Dashboards 2.0 from FlowFuse we have introduced the next generation of visualizations for the Node-RED platform.

It often makes sense to deploy a full MING stack, but in some deployments, it might be necessary to deploy a more simplistic version of the MING stack. This is where MIND comes into play.

### FlowFuse MQTT: Simplified Communications

FlowFuse has a built-in feature called [project link nodes](https://flowfuse.com/docs/user/projectnodes/), which leverages MQTT, that allows the communication of data between FlowFuse runtimes of Node-RED. One caveat is that this MQTT broker is only available within the FlowFuse platform. What this means is there needs to be some form of translation to be done within Node-RED. This isn’t a big deal for small deployments, because often Node-RED runtimes at the edger are collecting data from various sources that aren’t MQTT. The flow of data is as follows:

Sensor > Node-RED([FlowFuse Device Agent](https://flowfuse.com/platform/device-agent/)) > [MQTT Encapsulated by FlowFuse](https://flowfuse.com/docs/user/projectnodes/) > Node-RED(FlowFuse Platform) > InfluxDB

!["Screenshot showing the flow of data: Sensor > Node-RED(FlowFuse Device Agent) > MQTT Encapsulated by FlowFuse > Node-RED(FlowFuse Platform) > InfluxDB"](https://flowfuse.com/blog/2024/05/images/sensor-data-mqtt-node-red-dashboard-influxdb.png){dataZoomable=""}

A key benefit of having the MQTT broker encapsulated by FlowFuse is that it becomes extremely easy to set up. With the project nodes, there isn’t a need to configure certificates or security credentials because it is only exposed internally to the FlowFuse platform. Furthermore, the access and control limits are applied by the platform so your data remains within the same FlowFuse Team.

### InfluxDB: Efficient Data Storage

The deployment of InFluxDB doesn't change in the MIND configuration. The only significant change is that InFluxDB is deployed higher up in the architecture and closer to the FlowFuse Platform instead of the edge.

### Data Visualization with Dashboard 2.0

FlowFuse's Dashboard 2.0 makes it incredibly easy to visualize your data. You can create beautiful and informative dashboards in minutes. Simply drag and drop your desired widgets onto the canvas, and configure them with a few clicks.

We have gone through the step of providing you with an example dashboard for visualizing your MIND stack.

::render-flow
```json
[{"id":"dc1c7f4e5ddc86f8","type":"tab","label":"MIND","disabled":false,"info":"","env":[]},{"id":"1423665d39048eba","type":"mqtt in","z":"dc1c7f4e5ddc86f8","name":"","topic":"flowfuse/temp","qos":"2","datatype":"auto-detect","broker":"e8ea838e83035408","nl":false,"rap":true,"rh":0,"inputs":0,"x":190,"y":160,"wires":[["7ddcaadd5c43f11d","c359b55bc77165c2"]]},{"id":"993651c073e7659c","type":"mqtt in","z":"dc1c7f4e5ddc86f8","name":"","topic":"flowfuse/RH","qos":"2","datatype":"auto-detect","broker":"e8ea838e83035408","nl":false,"rap":true,"rh":0,"inputs":0,"x":190,"y":220,"wires":[["01f4e507e7deaaea","33e5c2e4a61d01e3"]]},{"id":"7ddcaadd5c43f11d","type":"change","z":"dc1c7f4e5ddc86f8","name":"Temp","rules":[{"t":"set","p":"topic","pt":"msg","to":"temp","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":350,"y":160,"wires":[["f39435df2b4db94f"]]},{"id":"01f4e507e7deaaea","type":"change","z":"dc1c7f4e5ddc86f8","name":"RH","rules":[{"t":"set","p":"topic","pt":"msg","to":"RH","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":350,"y":220,"wires":[["f39435df2b4db94f"]]},{"id":"f39435df2b4db94f","type":"join","z":"dc1c7f4e5ddc86f8","name":"","mode":"custom","build":"object","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":false,"timeout":"","count":"2","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":550,"y":180,"wires":[["fa067011fa3f705f","c9d37220d787ac92","681b2e5009ec5e1e"]]},{"id":"fa067011fa3f705f","type":"function","z":"dc1c7f4e5ddc86f8","name":"Send it to InfluxDB","func":"var temp = Number(msg.payload.temp);\nvar RH = Number(msg.payload.RH);\n\nmsg.measurement = \"room1\";\nmsg.payload = {Temperature:temp,RH:RH};\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":770,"y":180,"wires":[["0e86e1bd4bf8b9f6"]]},{"id":"0e86e1bd4bf8b9f6","type":"influxdb out","z":"dc1c7f4e5ddc86f8","influxdb":"cb09abcd8b693ca8","name":"","measurement":"","precision":"","retentionPolicy":"","database":"database","precisionV18FluxV20":"ms","retentionPolicyV18Flux":"","org":"organization","bucket":"bucket","x":1080,"y":180,"wires":[]},{"id":"c359b55bc77165c2","type":"ui-text","z":"dc1c7f4e5ddc86f8","group":"11df00492fb20acd","order":0,"width":0,"height":0,"name":"","label":"Temperature","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"Verdana,Verdana,Geneva,sans-serif","fontSize":16,"color":"#717171","className":"","x":530,"y":100,"wires":[]},{"id":"33e5c2e4a61d01e3","type":"ui-text","z":"dc1c7f4e5ddc86f8","group":"11df00492fb20acd","order":0,"width":0,"height":0,"name":"","label":"RH","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"Verdana,Verdana,Geneva,sans-serif","fontSize":16,"color":"#717171","className":"","x":510,"y":280,"wires":[]},{"id":"c9d37220d787ac92","type":"function","z":"dc1c7f4e5ddc86f8","name":"Temp","func":"var temp = Number(msg.payload.temp);\n\nmsg.payload = temp;\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":730,"y":120,"wires":[["432850955a867e1e","28d0b846fd2a48ab"]]},{"id":"681b2e5009ec5e1e","type":"function","z":"dc1c7f4e5ddc86f8","name":"RH","func":"var RH = Number(msg.payload.RH);\nmsg.payload = RH;\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":730,"y":240,"wires":[["a41e65a351476137","80b1312f88e4f656"]]},{"id":"432850955a867e1e","type":"ui-chart","z":"dc1c7f4e5ddc86f8","group":"aa70ec0abc058d78","name":"","label":"Live Temperature ","order":9007199254740991,"chartType":"line","category":"Temperature","categoryType":"str","xAxisProperty":"","xAxisPropertyType":"msg","xAxisType":"time","yAxisProperty":"","ymin":"0","ymax":"50","action":"append","pointShape":"line","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"3600","removeOlderPoints":"","colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"width":"6","height":"8","className":"","x":950,"y":120,"wires":[[]]},{"id":"a41e65a351476137","type":"ui-chart","z":"dc1c7f4e5ddc86f8","group":"aa70ec0abc058d78","name":"","label":"Live RH","order":9007199254740991,"chartType":"line","category":"RH","categoryType":"str","xAxisProperty":"","xAxisPropertyType":"msg","xAxisType":"time","yAxisProperty":"","ymin":"0","ymax":"100","action":"append","pointShape":"line","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"3600","removeOlderPoints":"","colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"width":"6","height":"8","className":"","x":940,"y":240,"wires":[[]]},{"id":"87ebfee665b784ee","type":"function","z":"dc1c7f4e5ddc86f8","name":"Min","func":"// Construct the query using the provided start and stop timestamps\nmsg.query = `SELECT min(Temperature) FROM room1`;\n\n// Pass the modified message object to the next node\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":450,"y":500,"wires":[["7d727f5a7723a73d"]]},{"id":"7d727f5a7723a73d","type":"influxdb in","z":"dc1c7f4e5ddc86f8","influxdb":"cb09abcd8b693ca8","name":"Read Temp","query":"","rawOutput":false,"precision":"","retentionPolicy":"","org":"organization","x":610,"y":540,"wires":[["fe9230e31884d82b"]]},{"id":"1da5df166734acac","type":"switch","z":"dc1c7f4e5ddc86f8","name":"Temp","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"Min","vt":"str"},{"t":"eq","v":"Max","vt":"str"},{"t":"eq","v":"Total","vt":"str"}],"checkall":"true","repair":false,"outputs":3,"x":310,"y":540,"wires":[["87ebfee665b784ee"],["1322af95dd29b8c3"],["717e1a07222ec348"]]},{"id":"1322af95dd29b8c3","type":"function","z":"dc1c7f4e5ddc86f8","name":"Max","func":"// Construct the query using the provided start and stop timestamps\nmsg.query = `SELECT max(Temperature) FROM room1`;\n\n// Pass the modified message object to the next node\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":450,"y":540,"wires":[["7d727f5a7723a73d"]]},{"id":"88e2e00b4e5f5fd6","type":"ui-dropdown","z":"dc1c7f4e5ddc86f8","group":"f02746ad7e1ab68c","name":"","label":"Select Option:","tooltip":"","order":0,"width":0,"height":0,"passthru":false,"multiple":false,"options":[{"label":"Min","value":"Min","type":"str"},{"label":"Max","value":"Max","type":"str"},{"label":"Total","value":"Total","type":"str"}],"payload":"","topic":"topic","topicType":"msg","className":"","x":160,"y":540,"wires":[["1da5df166734acac"]]},{"id":"57a7757bf943bce5","type":"ui-text","z":"dc1c7f4e5ddc86f8","group":"f02746ad7e1ab68c","order":0,"width":0,"height":0,"name":"","label":"Temp Stats","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"Verdana,Verdana,Geneva,sans-serif","fontSize":16,"color":"#717171","className":"","x":1290,"y":540,"wires":[]},{"id":"cac36785f12f3bf5","type":"function","z":"dc1c7f4e5ddc86f8","name":"Min","func":"var min = msg.payload[0].min\nmsg.payload = \"Minimum is \" + min;\nreturn (msg)","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1090,"y":500,"wires":[["57a7757bf943bce5"]]},{"id":"fc6330b5fcc33acc","type":"function","z":"dc1c7f4e5ddc86f8","name":"Max","func":"var avg = msg.payload[0].max;\nmsg.payload = \"Max is \" + avg;\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1090,"y":540,"wires":[["57a7757bf943bce5"]]},{"id":"6453914fa7bdd751","type":"switch","z":"dc1c7f4e5ddc86f8","name":"Temp","property":"payload[0]","propertyType":"msg","rules":[{"t":"hask","v":"min","vt":"str"},{"t":"hask","v":"max","vt":"str"},{"t":"hask","v":"count","vt":"str"}],"checkall":"true","repair":false,"outputs":3,"x":950,"y":540,"wires":[["cac36785f12f3bf5"],["fc6330b5fcc33acc"],["d29294d236bef25c"]]},{"id":"717e1a07222ec348","type":"function","z":"dc1c7f4e5ddc86f8","name":"Count","func":"// Construct the query using the provided start and stop timestamps\nmsg.query = `SELECT count(Temperature) FROM room1`;\n\n// Pass the modified message object to the next node\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":450,"y":580,"wires":[["7d727f5a7723a73d"]]},{"id":"d29294d236bef25c","type":"function","z":"dc1c7f4e5ddc86f8","name":"Count","func":"var count = msg.payload[0].count;\nmsg.payload = \"Total Record is \" + count;\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1090,"y":580,"wires":[["57a7757bf943bce5"]]},{"id":"e7465ddb4fd72e6a","type":"function","z":"dc1c7f4e5ddc86f8","name":"Min","func":"// Construct the query using the provided start and stop timestamps\nmsg.query = `SELECT min(RH) FROM room1`;\n\n// Pass the modified message object to the next node\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":450,"y":620,"wires":[["db0873d1bbef089a"]]},{"id":"db0873d1bbef089a","type":"influxdb in","z":"dc1c7f4e5ddc86f8","influxdb":"cb09abcd8b693ca8","name":"Read RH","query":"","rawOutput":false,"precision":"","retentionPolicy":"","org":"organization","x":600,"y":660,"wires":[["f14e43cc318fa92b"]]},{"id":"a27e50703cb15e38","type":"switch","z":"dc1c7f4e5ddc86f8","name":"RH","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"Min","vt":"str"},{"t":"eq","v":"Max","vt":"str"},{"t":"eq","v":"Total","vt":"str"}],"checkall":"true","repair":false,"outputs":3,"x":310,"y":660,"wires":[["e7465ddb4fd72e6a"],["0e8acb8b65e368f6"],["7402a7eec1245643"]]},{"id":"0e8acb8b65e368f6","type":"function","z":"dc1c7f4e5ddc86f8","name":"Max","func":"// Construct the query using the provided start and stop timestamps\nmsg.query = `SELECT max(RH) FROM room1`;\n\n// Pass the modified message object to the next node\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":450,"y":660,"wires":[["db0873d1bbef089a"]]},{"id":"a36dafb79f2fce75","type":"ui-dropdown","z":"dc1c7f4e5ddc86f8","group":"f02746ad7e1ab68c","name":"","label":"Select Option:","tooltip":"","order":0,"width":0,"height":0,"passthru":false,"multiple":false,"options":[{"label":"Min","value":"Min","type":"str"},{"label":"Max","value":"Max","type":"str"},{"label":"Total","value":"Total","type":"str"}],"payload":"","topic":"topic","topicType":"msg","className":"","x":160,"y":660,"wires":[["a27e50703cb15e38"]]},{"id":"4800381c4950d245","type":"ui-text","z":"dc1c7f4e5ddc86f8","group":"f02746ad7e1ab68c","order":0,"width":0,"height":0,"name":"","label":"RH Stats","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"Verdana,Verdana,Geneva,sans-serif","fontSize":16,"color":"#717171","className":"","x":1280,"y":660,"wires":[]},{"id":"4af1d2b0abf0009f","type":"function","z":"dc1c7f4e5ddc86f8","name":"Min","func":"var min = msg.payload[0].min\nmsg.payload = \"Minimum is \" + min;\nreturn (msg)","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1090,"y":620,"wires":[["4800381c4950d245"]]},{"id":"cfc4f16f835d3724","type":"function","z":"dc1c7f4e5ddc86f8","name":"Max","func":"var avg = msg.payload[0].max;\nmsg.payload = \"Max is \" + avg;\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1090,"y":660,"wires":[["4800381c4950d245"]]},{"id":"49ac1cdfe4289eac","type":"switch","z":"dc1c7f4e5ddc86f8","name":"RH","property":"payload[0]","propertyType":"msg","rules":[{"t":"hask","v":"min","vt":"str"},{"t":"hask","v":"max","vt":"str"},{"t":"hask","v":"count","vt":"str"}],"checkall":"true","repair":false,"outputs":3,"x":950,"y":660,"wires":[["4af1d2b0abf0009f"],["cfc4f16f835d3724"],["57b2d15bae6a4d42"]]},{"id":"7402a7eec1245643","type":"function","z":"dc1c7f4e5ddc86f8","name":"Count","func":"// Construct the query using the provided start and stop timestamps\nmsg.query = `SELECT count(RH) FROM room1`;\n\n// Pass the modified message object to the next node\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":450,"y":700,"wires":[["db0873d1bbef089a"]]},{"id":"57b2d15bae6a4d42","type":"function","z":"dc1c7f4e5ddc86f8","name":"Count","func":"var count = msg.payload[0].count;\nmsg.payload = \"Total Record is \" + count;\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1090,"y":700,"wires":[["4800381c4950d245"]]},{"id":"fb1cbe8ec45b5de7","type":"comment","z":"dc1c7f4e5ddc86f8","name":"Write Operation","info":"","x":100,"y":80,"wires":[]},{"id":"931c16333d3efcad","type":"comment","z":"dc1c7f4e5ddc86f8","name":"Read Operation","info":"","x":180,"y":340,"wires":[]},{"id":"f200e4be2158481e","type":"comment","z":"dc1c7f4e5ddc86f8","name":"Read Operation","info":"","x":180,"y":480,"wires":[]},{"id":"80b1312f88e4f656","type":"ui-gauge","z":"dc1c7f4e5ddc86f8","name":"Live RH","group":"f02746ad7e1ab68c","order":0,"width":"0","height":"0","gtype":"gauge-34","gstyle":"rounded","title":"Live RH","units":"%","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#5cd65c"},{"from":"40","color":"#ffc800"},{"from":"70","color":"#ea5353"}],"min":0,"max":"100","sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":940,"y":280,"wires":[]},{"id":"28d0b846fd2a48ab","type":"ui-gauge","z":"dc1c7f4e5ddc86f8","name":"Live Temperature","group":"f02746ad7e1ab68c","order":0,"width":"0","height":"0","gtype":"gauge-34","gstyle":"rounded","title":"Temperature","units":"Degrees C","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#5cd65c"},{"from":"30","color":"#ffc800"},{"from":"40","color":"#ea5353"}],"min":0,"max":"50","sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":950,"y":80,"wires":[]},{"id":"f22ff292ec2d0964","type":"ui-form","z":"dc1c7f4e5ddc86f8","name":"Start Time","group":"11df00492fb20acd","label":"Select Date and Time","order":0,"width":0,"height":0,"options":[{"label":"Start","key":"Start Date","type":"date","required":true,"rows":null},{"label":"Start Time","key":"Start Time","type":"time","required":true,"rows":null},{"label":"Stop Date","key":"Stop Date","type":"date","required":true,"rows":null},{"label":"Stop Time","key":"Stop Time","type":"time","required":true,"rows":null}],"formValue":{"Start Date":"","Start Time":"","Stop Date":"","Stop Time":""},"payload":"","submit":"submit","cancel":"clear","resetOnSubmit":false,"topic":"topic","topicType":"msg","splitLayout":false,"className":"","x":160,"y":420,"wires":[["05dfd0f5d8b97fba"]]},{"id":"05dfd0f5d8b97fba","type":"function","z":"dc1c7f4e5ddc86f8","name":"start date and end date","func":"var startDate = msg.payload[\"Start Date\"];\nvar startTime = msg.payload[\"Start Time\"];\nvar stopDate = msg.payload[\"Stop Date\"];\nvar stopTime = msg.payload[\"Stop Time\"];\n\n\n\nvar startTimestamp = `${startDate}T${startTime}:00+05:30`; // +05:30 is the offset for IST\nvar stopTimestamp = `${stopDate}T${stopTime}:00+05:30`; // +05:30 is the offset for IST\n\n// Construct the query using the provided start and stop timestamps\nmsg.query = `SELECT * FROM room1 WHERE time >= '${startTimestamp}' AND time <= '${stopTimestamp}'`;\n\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":410,"y":420,"wires":[["a1d3dda63ad3bd6f"]]},{"id":"a1d3dda63ad3bd6f","type":"influxdb in","z":"dc1c7f4e5ddc86f8","influxdb":"cb09abcd8b693ca8","name":"Read","query":"","rawOutput":false,"precision":"","retentionPolicy":"","org":"organization","x":610,"y":420,"wires":[["ad4f278b680749b2"]]},{"id":"024b2830c4183fd1","type":"function","z":"dc1c7f4e5ddc86f8","name":"Table","func":"var temp=[];\nvar a = msg.payload;\n\na.forEach(function (value,index) {\ntemp.push(value)\n});\n\nmsg.payload=temp\n\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":1650,"y":780,"wires":[[]]},{"id":"5bb2164a578330bd","type":"ui-table","z":"dc1c7f4e5ddc86f8","group":"11df00492fb20acd","name":"Historic Data","label":"text","order":0,"width":0,"height":0,"maxrows":0,"autocols":true,"columns":[],"x":1050,"y":420,"wires":[]},{"id":"ad4f278b680749b2","type":"copy-array","z":"dc1c7f4e5ddc86f8","name":"Table","x":790,"y":420,"wires":[["5bb2164a578330bd"]]},{"id":"dd00c6e47e1480ad","type":"ui-button","z":"dc1c7f4e5ddc86f8","group":"aa70ec0abc058d78","name":"","label":"Clear Temp","order":0,"width":0,"height":0,"passthru":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","payload":"[]","payloadType":"json","topic":"topic","topicType":"msg","x":730,"y":60,"wires":[["432850955a867e1e"]]},{"id":"7e6d8eb54dc0d8aa","type":"ui-button","z":"dc1c7f4e5ddc86f8","group":"aa70ec0abc058d78","name":"","label":"Clear RH","order":0,"width":0,"height":0,"passthru":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","payload":"[]","payloadType":"json","topic":"topic","topicType":"msg","x":740,"y":300,"wires":[["a41e65a351476137"]]},{"id":"fe9230e31884d82b","type":"copy-array","z":"dc1c7f4e5ddc86f8","name":"Temp Data","x":810,"y":540,"wires":[["6453914fa7bdd751"]]},{"id":"f14e43cc318fa92b","type":"copy-array","z":"dc1c7f4e5ddc86f8","name":"RH Data","x":800,"y":660,"wires":[["49ac1cdfe4289eac"]]},{"id":"e8ea838e83035408","type":"mqtt-broker","name":"","broker":"192.168.1.39","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closeRetain":"false","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willRetain":"false","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":""},{"id":"cb09abcd8b693ca8","type":"influxdb","hostname":"127.0.0.1","port":"8086","protocol":"http","database":"environment","name":"","usetls":false,"tls":"cff98b62.009678","influxdbVersion":"1.x","url":"http://localhost:8086","timeout":"10","rejectUnauthorized":true},{"id":"11df00492fb20acd","type":"ui-group","name":"Room 1","page":"6a43b6805a66d2b8","width":"6","height":"1","order":-1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"aa70ec0abc058d78","type":"ui-group","name":"Live Data","page":"6a43b6805a66d2b8","width":"6","height":"1","order":-1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"f02746ad7e1ab68c","type":"ui-group","name":"Stat Data","page":"6a43b6805a66d2b8","width":"6","height":"1","order":-1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"cff98b62.009678","type":"tls-config","name":"","cert":"","key":"","ca":"","certname":"","keyname":"","caname":"","servername":"","verifyservercert":false},{"id":"6a43b6805a66d2b8","type":"ui-page","name":"Environment Data","ui":"20ae73d735a60fbc","path":"/page2","icon":"home","layout":"flex","theme":"074b315414230834","order":-1,"className":"","visible":"true","disabled":"false"},{"id":"20ae73d735a60fbc","type":"ui-base","name":"UI Name","path":"/dashboard","showPathInSidebar":false},{"id":"074b315414230834","type":"ui-theme","name":"Theme Name","colors":{"surface":"#ffffff","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
```
::

This dashboard example allows you to do quick visualizations of data from an InfluxDB. In this particular case, it leverages the Relative Humidity (RH) and Temperature of a sensor. It captures the data and stores in InfluxDB and then visualizes it in Dashboard 2.0. Use this as a starting point to display data in the MIND stack.

## Advantages of FlowFuse’s MIND Stack

FlowFuse provides built-in features, such as MQTT, backups, deployment pipelines, and access control, helping to protect data and devices from unauthorized access. FlowFuse simplifies the MING stack to the MIND deployment, bringing numerous benefits to organizations. It reduces the complexity of managing multiple components, minimizing configuration, update, and maintenance overhead. The single platform approach for MQTT, Node-RED, and visualization simplifies maintenance tasks, lowers the risk of conflicts, and ensures consistency. FlowFuse's lighter deployment requires fewer hardware resources, making it suitable for resource-constrained environments or cost-sensitive projects. Organizations can potentially save on licensing and maintenance costs by reducing the number of deployed software components. Faster deployment is enabled with fewer components to set up and configure, allowing projects to realize value sooner. FlowFuse's scalable architecture handles large data volumes and devices, ensuring suitability for growing IoT deployments.

## Conclusion

While we believe that the MING stack is here to stay, we believe as the market matures, it should offer many different variations suitable for each customer's needs. However, we find that the MIND offering does fill a niche in the market that may better suit your needs. None the less, choosing FlowFuse to manage your Node-RED runtimes will ensure that your applications will be secure, scalable, and easily manageable. Allowing your domain experts to take control and extend their knowledge bringing increased value to industrial facilities around the world.


# Product Mission Statement and Strategy Updates

It's now been two years since our first ever `0.1.0` release of FlowFuse. In that time, we've been working hard to build out a platform to help users elevate their Node-RED experience. In that time we've delivered some incredibly valuable features to FlowFuse users such as centralized instance management, remote deployments and version control. We've also learned a lot about our users, their needs, and how we can best serve them, and in a recent reflection on our product strategy decided to refine our product mission statement.

## Product Mission Statement

FlowFuse is used across a range of industries and use-cases, and in the hundreds of conversations we've had with customers, we've found that in every scenario there is a common pattern. So, to reflect ths, we've created a new Product Mission Statement, to make it clear to existing and prospective users of FlowFuse what it is that we're striving for.

Our new mission statement is as follows:

> **Provide the best way to build, manage and deploy Node-RED applications at scale, in reliable and secure production environments.**

We believe that by focusing on this mission, we can better serve our users and provide them with the tools they need to succeed. This mission statement will act as the north star for our product prioritization moving forward, and be our compass to ensure we're staying on track in delivering value to our users.

### Build

FlowFuse strives to be the best place to build Node-RED applications by providing tools to help users build applications with more confidence.

- **Simplified Hosting:** Whether you want cloud-hosted instances, or to run Node-RED on edge devices, FlowFuse provides the smoothest experience to setup new Node-RED instances.
- **Trust**: [Certified Nodes](https://flowfuse.com/blog/2023/10/certified-nodes/) ensure Node-RED developers can trust the reliability, quality and security of third-party nodes they're using in their applications.
- **Version Control**: [Snapshots](https://flowfuse.com/docs/user/snapshots/) capture point-in-time views of Node-RED flows, environment variables and other configuration settings. We even capture automatic snapshots of your flows every time you deploy, so you can always be confident you have a backup.
- **Collaborative Development**: We are building FlowFuse to be a platform that enables teams to work seamlessly together on Node-RED applications. From the [Team Library](https://flowfuse.com/docs/user/shared-library/), through to [Node-RED Multiplayer](https://flowfuse.com/blog/2024/04/node-red-multiplayer/), we want to make sure that FlowFuse is the best platform for collaborative development in Node-RED.
- **Remote Access:** FlowFuse provides a secure way to access your Node-RED instances and devices from anywhere in the world, so you can build and debug your applications with ease.

### Manage

With FlowFuse, it's possible to manage thousands of Node-RED instances, all in one place. We make sure you have a clear picture of what's happening across all of your instances, and provide tools to help you manage them effectively.

- **Centralized Management**: FlowFuse provides a single entry point to manage all of your Node-RED instances, no matter where they are hosted.
- **Security**: FlowFuse provides a range of security features to help you keep your Node-RED instances secure. From [Two-Factor Authentication](https://flowfuse.com/docs/user/user-settings/#two-factor-authentication) to [Role-Based Access Control](https://flowfuse.com/blog/2024/04/role-based-access-control-rbac-for-node-red-with-flowfuse/), we're building FlowFuse to be the most secure way to manage your Node-RED instances.
- **Frictionless Maintenance:** Whether you're updating your Node-RED version, or one of the many third-party dependencies that your applications depend upon, FlowFuse provides tools to make it easy to keep your instances up-to-date and running smoothly.
- **Observability:** FlowFuse provides tools to help you keep an eye on your Node-RED instances and make sure they're running smoothly. Get alerts when something goes wrong, and use the [Audit Logs](https://flowfuse.com/docs/user/logs/#audit-log) to help you debug issues when they arise.

### Deploy

With FlowFuse, we aim to provide the best way to deploy Node-RED applications to production environments, whether that be to hundreds of remote devices, or via staging environments to ensure you can deploy with confidence.

- **DevOps:** Test your applications in development and staging environments, ensuring you can deploy them with confidence to production.
- **Remote Deployments:** Deploy your applications to hundreds of remote devices with a single-click, ensuring you can get your applications running in production quickly and easily.
- **Reliability:** FlowFuse users can have trust that their applications will run without issues with features like [High Availability](https://flowfuse.com/blog/2023/06/flowforge-1-8-released/). FlowFuse makes sure users have the tools to monitor and manage the reliability of their applications, including being alerted when things go wrong, and making the recovery as easy as possible.

### What's Next?

Our development team are busy working on a range of new features to help us deliver on our mission. If you're interested to see what highlight features we're working on for the next release (v2.5) in four weeks time, you can checkout our [Development Board](https://github.com/orgs/FlowFuse/projects/1/views/39){rel="&#x22;nofollow&#x22;"} on GitHub.

For longer term planning, we have our [Product Planning Board](https://github.com/orgs/FlowFuse/projects/3/views/9){rel="&#x22;nofollow&#x22;"}, which outlines the features we're working on for the next 12 months. It's subject to change, as we're always [iterating](https://flowfuse.com/handbook/company/values/#iterative-improvement), but it gives a good idea of where our focus will likely be in the coming months.

In the mean time, please do reach out if there are any features you'd like to see in FlowFuse, or if you have any feedback on our product strategy. We're always keen to hear from our users and learn how we can better serve you.

### Read More

If you're interested in learning more about our company and product strategies, you can read more detail in our Handbook:

- [Company Strategy](https://flowfuse.com/handbook/company/strategy)
- [Product Mission Statement](https://flowfuse.com/handbook/engineering/product/)


# How to Use Variables in Node-RED: Flow, Global, Context & Environment (2026)

Node-RED has four types of variables: **message variables** that travel with `msg` through your nodes, and **context variables** in three scopes, **node** (private to a single function node), **flow** (shared within one tab), and **global** (shared across the entire instance), plus **environment variables** for configuration and secrets. You set and retrieve context variables with `global.set()`/`global.get()`, `flow.set()`/`flow.get()`, and `context.set()`/`context.get()` in function nodes, or visually through the change node. Context variables are stored in memory by default and are lost on restart, so any state that must survive a reboot needs persistent storage.

That's the short version. The rest of this guide walks through each variable type in detail, showing you exactly how to set, retrieve, and delete them, when to use each scope, and how to make them persist across restarts and redeployments.

## What Are Node-RED Variables?

Variables in Node-RED serve as containers for storing and managing data throughout your application. Understanding the different types and their scopes is essential for building efficient, organized flows.

Node-RED offers three primary variable categories:

**Message variables** travel with the message object as it flows through your nodes. The most common example is `msg.payload`, which carries the primary data between nodes. For a deeper dive into message handling, see the [Understanding Node-RED Messages](https://flowfuse.com/node-red/getting-started/node-red-messages/) guide.

**Context variables** store application state at different levels, node, flow, or global scope. They persist data that needs to be accessed across multiple message events, making them ideal for tracking counters, storing configuration, or maintaining state.

**Environment variables** handle configuration data and sensitive information like API keys and credentials. By storing this data separately from your flows, you maintain security and make configuration management more flexible.

## Global Variables: Instance-Wide Data Storage

Global variables provide a centralized storage mechanism accessible throughout your entire Node-RED instance. Any function, change, inject, or switch node can read or write global variables, making them perfect for sharing data across multiple flows.

**When to use global variables:** Consider using them for system-wide settings, shared configuration, or data that multiple flows need to access. For example, in a home automation system with separate flows for lighting, security, and climate control, global variables can store user preferences that all flows reference.

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

### Working with Global Variables

**Setting global variables** can be done through the change node or programmatically in a function node:

Using the change node:

1. Select "global" from the variable type dropdown
2. Enter your variable name
3. Set the value or expression

!["Screenshot showing how to set global variable using the change node"](https://flowfuse.com/blog/2024/05/images/variables-in-node-red-setting-global-variable-using-change-node.png "Screenshot showing how to set global variable using the change node"){dataZoomable=""}

Using a function node:

```javascript
global.set('userName', 'John');
global.set('systemMode', 'active');
```

**Retrieving global variables** follows a similar pattern:

In a change, inject, or switch node, simply set the action to “set”, choose the type as “global”, and specify the variable name.

!["Screenshot showing how to retrieve global variables using the change node"](https://flowfuse.com/blog/2024/05/images/variables-in-node-red-retrieving-global-variable-using-change-node.png "Screenshot showing how to retrieve global variables using the change node"){dataZoomable=""}

In function nodes:

```javascript
const userName = global.get('userName');
const mode = global.get('systemMode');
```

**Deleting global variables** can be accomplished through the change node by selecting "delete" from the action dropdown, or via the Context Data sidebar panel, which provides a comprehensive view of all variables.

!["Screenshot showing how to delete global variable using the change node"](https://flowfuse.com/blog/2024/05/images/variables-in-node-red-deleting-global-variable-using-change-node.png "Screenshot showing how to delete global variable using the change node"){dataZoomable=""}

## Flow Variables: Tab-Scoped Data

Flow variables exist within a single tab or flow in your Node-RED editor. They're accessible to all nodes within that specific flow but isolated from other flows, providing logical data separation.

**When to use flow variables:** Use them for data that's relevant only to a specific workflow. For instance, in a temperature monitoring flow with multiple sensor nodes, flow variables can track the current reading, alert thresholds, or calculation results, data that doesn't need to be shared with other parts of your application.

### Working with Flow Variables

**Setting flow variables:**

Using the change node, select the action “set”, choose “flow” as the variable type, and configure your variable.

!["Screenshot showing how to set flow variable using the change node"](https://flowfuse.com/blog/2024/05/images/variables-in-node-red-setting-flow-variable-using-change-node.png "Screenshot showing how to set flow variable using the change node"){dataZoomable=""}

In function nodes:

```javascript
flow.set('currentTemp', 72.5);
flow.set('alertThreshold', 85);
```

**Retrieving flow variables:**

In a change, inject, or switch node, simply set the action to “set”, choose the type as “flow”, and specify the variable name.

!["Screenshot showing how to retrieve flow variable using the change node"](https://flowfuse.com/blog/2024/05/images/variables-in-node-red-retrieving-flow-variable-using-change-node.png "Screenshot showing how to retrieve flow variable using the change node"){dataZoomable=""}

In function nodes:

```javascript
const temp = flow.get('currentTemp');
const threshold = flow.get('alertThreshold');
```

**Deleting flow variables** works the same way as global variables, use the change node's delete action or the Context Data panel.

!["Screenshot showing how to delete flow variable using the change node"](https://flowfuse.com/blog/2024/05/images/variables-in-node-red-deleting-flow-variable-using-change-node.png "Screenshot showing how to delete flow variable using the change node"){dataZoomable=""}

## Node Variables: Node-Level Isolation

Node variables (also called node context) are the most restrictive scope, they exist only within a single node. No other node can access or modify these variables, making them ideal for maintaining private state.

**When to use node variables:** Perfect for counters, temporary calculations, or any data that should remain private to a specific node. For example, a function node that generates unique IDs for database records can maintain a counter variable that's never exposed to other parts of your flow.

### Working with Node Variables

Node variables are local to a Function node and cannot be read or modified by other nodes.

**Setting node variables:**

```javascript
context.set('counter', 0);
context.set('lastProcessedId', 'ABC123');
```

**Retrieving node variables:**

```javascript
let counter = context.get('counter');
counter++;
context.set('counter', counter);
```

**Deleting node variables** must be done through the Context Data sidebar panel.

## Persistent Storage with FlowFuse

By default, all context variables (node, flow, and global) are stored in memory. This means they're lost whenever you restart Node-RED or redeploy your flows. For production applications, this is often unacceptable.

FlowFuse provides persistent storage that survives restarts, redeployments, and system updates. This ensures your application state remains intact across sessions.

### Using Persistent Storage

**Setting persistent variables:**

In the change node, select "persistent" from the store dropdown instead of "memory".

:video{ariaLabel="Video showing how to set global variable using the change node" autoPlay="true" height="366" loop="true" muted="true" playsInline="true" preload="none" width="538"}

In function nodes, add "persistent" as a third parameter:

```javascript
global.set('userData', userData, 'persistent');
flow.set('sessionConfig', config, 'persistent');
context.set('processedCount', count, 'persistent');
```

**Retrieving persistent variables:**

In a change, inject, or switch node, ensure you're selecting from the "persistent" store.

:video{ariaLabel="Video showing how to retrieve global variable using the change node" autoPlay="true" height="366" loop="true" muted="true" playsInline="true" preload="none" width="528"}

In function nodes:

```javascript
const userData = global.get('userData', 'persistent');
const config = flow.get('sessionConfig', 'persistent');
const count = context.get('processedCount', 'persistent');
```

Persistent storage allows Node-RED to retain state between restarts, crucial for historical metrics, long-running counters, dashboard application data, and any flow that must persist through a reboot without losing information.

## The Context Data Panel

Node-RED includes a dedicated Context Data panel in the sidebar that provides visibility into all your variables. This panel is invaluable for debugging and understanding your application's state.

!["Screenshot showing Node-RED Context data tab"](https://flowfuse.com/blog/2024/05/images/variables-in-node-red-context-data-tab.png "Screenshot showing Node-RED Context data tab"){dataZoomable=""}

**Features of the Context Data panel:**

- View all node, flow, and global variables in organized sections
- See when each variable was last updated
- Copy variable names or values with one click
- Refresh individual variables to see current values
- Delete variables directly from the interface

To access this panel, open the sidebar and choose ‘Context Data’ from the dropdown menu. Use the refresh icon in each section to update the display with the latest values.

!["Screenshot showing Node-RED Context data tab options for managing variables"](https://flowfuse.com/blog/2024/05/images/variables-in-node-red-context-data-tab-options-for-varrables.png "Screenshot showing Node-RED Context data tab options for managing variables"){dataZoomable=""}

## Environment Variables: Secure Configuration

Environment variables serve a different purpose than context variables, they're designed for configuration data, especially sensitive information that shouldn't be hardcoded in your flows.

Node-RED supports environment variables at two levels:

**Flow-level environment variables** are accessible only within a specific flow. This is useful when different flows need different configurations. For example, one flow might connect to a development database while another connects to production, each using its own credentials.

**Global-level environment variables** are accessible across all flows in your instance. Use these for shared configuration like API keys that multiple flows need to reference.

### Working with Environment Variables

**Setting flow-level environment variables:**

1. Double-click on the flow tab to open the edit dialog
2. Navigate to the "Environment Variables" section
3. Add your variables as name-value pairs
4. Click Done and deploy

:video{ariaLabel="Video showing how to set flow level environment variables" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

For global-level environment variables, see [Using Environment Variables in Node-RED](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/) for detailed instructions.

**Accessing environment variables:**

In change, inject, or switch nodes, select "env variable" and specify the name.

!["Screenshot showing how to retrieve environment variable in the change node"](https://flowfuse.com/blog/2024/05/images/variables-in-node-red-retrieving-environment-variable-using-change-node.png "Screenshot showing how to retrieve environment variable in the change node"){dataZoomable=""}

In function nodes:

```javascript
const apiKey = env.get('API_KEY');
const dbHost = env.get('DB_HOST');
```

In template nodes:

```javascript
API Endpoint: {{env.API_ENDPOINT}}
```

For configuration nodes that don't have explicit environment variable support, you can often use the syntax `${VARIABLE_NAME}` in input fields.

**Important note on precedence:** When a flow-level and global-level environment variable share the same name, Node-RED uses the flow-level value. To explicitly access the global-level variable, prefix it with `$parent.` in your reference.

**Deleting environment variables:** Return to the flow edit dialog where you added them and click the delete icon next to each variable. Remember to redeploy your flows after making changes.

## Best Practices

Here are some guidelines for effective variable usage in Node-RED:

**Choose the right scope:**

- Use node variables for node-specific data
- Use flow variables for data shared within a single workflow
- Use global variables for system-wide shared data
- Use environment variables for configuration and secrets

**Naming conventions matter:** Use clear, descriptive names. Consider prefixing variables with their purpose (e.g., `sensor_temperature`, `config_timeout`, `user_preferences`).

**Leverage persistent storage:** For production applications, identify which variables need to survive restarts and use persistent storage for those.

**Keep sensitive data in environment variables:** Never hardcode API keys, passwords, or other secrets directly in flows. Always use environment variables.

**Document your variables:** Use the description field in your nodes to explain what variables are being set or read, especially for complex flows that others might maintain.

**Monitor the Context Data panel:** Regularly check this panel during development to verify variables are being set correctly and to catch potential issues early.

## Conclusion

Node-RED's four variable types give you a clear toolkit for managing data and state. Use **node context** for private, node-specific values, **flow variables** for data shared within a single tab, and **global variables** for anything multiple flows need to reach. Reach for **environment variables** when you're handling configuration and secrets that shouldn't be hardcoded. Matching the scope to the job keeps your flows organized, predictable, and easy for others to maintain.

The one thing to keep front of mind: context variables live in memory by default, so they reset on every restart or redeploy. For anything your application genuinely depends on, counters, cached configuration, dashboard history, plan for persistent storage from the start rather than discovering the gap in production.

Get the scopes right and lean on persistence where it matters, and Node-RED will handle everything from quick prototypes to applications you can run with confidence.


# Why you need a low-code platform

Digital transformation is a series of technological advancements that aim to simplify complex tasks. From calculators and graphical user interfaces (GUIs) to new programming languages, these advancements have enabled individuals to create value that was once beyond their reach. The key is to understand that these tools are not meant to replace expertise but to enhance it, making complex tasks more manageable, speeding up development time, and empowering more people.

## What Does It Mean to Empower Someone?

Often, people perceive "empowerment" as a derogatory term, but it shouldn't be. Empowerment should mean enabling a domain expert to further grow their expertise. They are adding one more tool (and hopefully replacing some) to their toolbox to bring value to what they **know**. And what they know is often hard to explain. It has taken years to master their role, which people usually take for granted because they don't understand the complex dance they do to make their section of the world operate flawlessly.

## What Do They Do, and Why Is It Hard to Explain?

Imagine a simple project like building a tire swing. The humorous illustration below shows how different interpretations and outcomes can arise throughout a project lifecycle:

![Tire Swing Analogy](https://flowfuse.com/blog/2024/05/images/tire-swing-project-management-flowfuse-node-red.png "Example of communication issues between the developers and end-users"){dataZoomable=""}

This analogy highlights the potential misunderstandings and miscommunications that occur between various stakeholders in a project. From the initial customer explanation to the final product, each stage can introduce variations that stray from the original intent. This leads to a final outcome that often doesn't meet the customer's needs or expectations.

In a perfect world, with clear instructions and years of prep work to define the problem statement, there's a chance the project will be completed close to 95% of what the domain expert wanted, if you're lucky. But how do you close the last 5%? Developers might move on to new projects, or worse, leave the company. The remaining tasks become difficult to complete and often go undone.

## Put the Domain Expert in the Driver’s Seat

Calculators were not created to be used only by mathematicians. GUIs weren't created to be used only by programmers. They were created to make people's lives easier. No longer was there a **need** to use the command line to start an application; simply click the icon for the desired application. These simple iterations open the opportunity for a larger range of people to leverage tools.

With low-code applications, the process is the same. Put the domain expert in the driver’s seat. Make them their own developer. They understand the process better than anyone else. Pair them with a low-code domain expert and have them co-develop the application.

With the domain expert in the driver’s seat of their own low-code project, the days of the last 5% undone become less common. There is always a path forward.

## Which Low-Code Solution Should You Go With?

With over 10 years of development emerging from [IBM’s Emerging Technology Group](https://flowfuse.com/blog/2024/02/history-of-nodered/), Node-RED is a clear leader. Dare I say the de facto solution. It is open-source and easy to spin up. It is currently being leveraged in many industries; ranging from pharmaceuticals, to agriculture, and to telecom.

But you might think Node-RED is just a proof-of-concept tool. You’re wrong. Has it been used as [Shadow-IT](https://www.cloudflare.com/learning/access-management/what-is-shadow-it/){rel="&#x22;nofollow&#x22;"}? Yes, and that is beautiful and awesome. Innovation is at the heart of Shadow-IT. No one ever said, “There is a tool supported by my IT company that would be perfect for the job, but I think I would rather deploy an unsanctioned tool.” The flaw in this statement is believing there is a choice in tools. Node-RED has often been the only tool available in the domain expert's toolbox.

## Increased Development Speed

Domain experts often find themselves needing to develop solutions but learning a new programming language can be time-consuming. With the open-source community behind Node-RED, many common integrations and transformations have already been created. This community sharing of knowledge accelerates development because often a needed programming task has already been developed and shared. This allows domain experts to repurpose existing code as [**nodes, flows, or collections**](https://flows.nodered.org/){rel="&#x22;nofollow&#x22;"}, significantly speeding up the development process.

## FlowFuse

FlowFuse is your solution to solving Shadow-IT and paving the way for your [Citizen Development](https://flowfuse.com/blog/2024/02/why-citizen-development-platforms/) journey. All the reasons why Node-RED hasn’t been sanctioned within organizations have nothing to do with its ability to execute but more with its lack of scalability, easy-to-use security, and manageability. Enter FlowFuse, developed by the same people who developed your go-to low-code solution. FlowFuse addresses exactly the problems that put it in the Shadow-IT realm.

With security and scalability top of mind, FlowFuse allows IT teams to manage their Node-RED deployments with features like Role-Based Access Control (RBAC), remote management of Node-RED runtimes, and backup and recovery of Node-RED deployments called Snapshots. These are just a few of the features that elevate an already widely used solution, making it ready for enterprise networks.

### Low-code platform success in the real world

Low-code platforms are industry-agnostic, with applications varying from industrial manufacturing to news agencies. Here are some customer success stories of how the FlowFuse low-code platform has helped:

- [**Abrasive Technology:**](https://flowfuse.com/customer-stories/leveraging-node-red-and-flowfuse-to-automate-precision-manufacturing/) Leveraged Node-RED and FlowFuse to optimize automation and improve operational efficiency. The transition to FlowFuse Cloud has enhanced their ability to manage Node-RED instances effectively, supporting innovation and agility in their manufacturing processes.
- [**Power Workplace:**](https://flowfuse.com/customer-stories/node-red-building-management/) Utilized FlowFuse and Node-RED to automate building management, significantly reducing development time and enhancing scalability and reliability. This has helped them meet security and compliance requirements more easily, improving service delivery across multiple regions.
- [**Large US Manufacturing Company:**](https://flowfuse.com/customer-stories/manufacturing-digital-transformation/) Employed Node-RED and FlowFuse to drive digital transformation across numerous manufacturing sites. By decentralizing innovation, they have improved data visibility, real-time decision-making, and overall process efficiency, using FlowFuse to manage extensive Node-RED deployments and version control.

## The Low-Code Future

In conclusion, low-code platforms like Node-RED and FlowFuse empower domain experts to take control of their own digital transformation journeys. By putting the domain expert in the driver’s seat, low-code applications enable them to create solutions tailored to their specific needs and requirements. This approach not only reduces the risk of the last 5% of a project going undone but also fosters a culture of innovation and collaboration within organizations.


# Node-RED Dashboard Formally Deprecated

Dave Conway-Jones, the lead maintainer of Node-RED Dashboard, has [just announced](https://discourse.nodered.org/t/node-red-dashboard-v1-deprecation-notice/89006){rel="&#x22;nofollow&#x22;"} that Node-RED Dashboard has been formally deprecated, meaning there will be no further development activity on the project.

[FlowFuse Dashboard](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"} (also known as Node-RED Dashboard 2.0) is a natural successor to Node-RED Dashboard, and in this article, we detail what FlowFuse Dashboard offers, and how you can get started.

## What's new in Dashboard 2.0?

Not only have we made significant efforts to ensure that FlowFuse Dashboard has as much feature parity with Node-RED Dashboard as possible, but we've also introduced a number of new features that we think you'll love, some highlights include:

- **Multi Tenancy:** A big change from Node-RED Dashboard is the introduction of multi-tenancy features. This allows you to build Dashboards that are unique to each user that interacts with your flows.
- **Responsive Layouts:** FlowFuse Dashboard is built with a responsive layout in mind, meaning that your Dashboards will automatically adjust to the screen size of the device they are being viewed on.
- **New Nodes:** We've introduced a five new nodes; [Button Group](https://dashboard.flowfuse.com/nodes/widgets/ui-button-group.html){rel="&#x22;nofollow&#x22;"}, [Radio Group](https://dashboard.flowfuse.com/nodes/widgets/ui-radio-group.html){rel="&#x22;nofollow&#x22;"}, [File Upload](https://dashboard.flowfuse.com/nodes/widgets/ui-file-input.html){rel="&#x22;nofollow&#x22;"}, [Event](https://dashboard.flowfuse.com/nodes/widgets/ui-event.html){rel="&#x22;nofollow&#x22;"} and [Table](https://dashboard.flowfuse.com/nodes/widgets/ui-table.html){rel="&#x22;nofollow&#x22;"} to help you build your Dashboards, without needing to write custom code, or depend on third-party libraries.
- **Directly Install on Mobile:** FlowFuse Dashboard is built as a Progressive Web App (PWA), this means that you're able to install it directly onto your mobile device as if it were a native mobile application.
- **Vuetify Framework:** FlowFuse Dashboard is built on VueJS, and with that, we made the decision to integrate in [Vuetify](https://vuetifyjs.com/en/components/all/#containment){rel="&#x22;nofollow&#x22;"}, a very rich collection of functional UI widgets. All of these widgets are available, by default when you want to build your own custom widgets in a `ui-template` node.

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

## What we have planned

We are actively investing into the development of FlowFuse Dashboard, and releasing new features and updates on a regular basis. We have a public [Project Management Board](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"} that show exactly what we're working on, and what we have planned in the near future. Some particular highlights include:

- **Visual Layout Editor:** This would be the biggest improvement to building dashboards in Node-RED. We're aiming for a fully interactive front-end to help you design your Dashboard layouts. This would live in your Dashboard itself, no more needing to switch between the Node-RED Editor and your Dashboard to sanity check changes. You can see more details [here](https://github.com/FlowFuse/node-red-dashboard/issues/30){rel="&#x22;nofollow&#x22;"}.
- **Diversity of Data Visualisation:** We are planning to provide a richer ecosystem of data visualisations. We're also likely to be switching to [Apache eCharts](https://github.com/FlowFuse/node-red-dashboard/issues/782){rel="&#x22;nofollow&#x22;"} (subject to further investigation), and are considering a `ui-template`-type node that can be used to build [custom charts](https://github.com/FlowFuse/node-red-dashboard/issues/58){rel="&#x22;nofollow&#x22;"} too.
- **Feature Parity:** Whilst we've covered there vast majority of Dashboard 1.0 features, we've still got a little bit to go, in particular, the most requested features we have are [programmatic (mustache) title and labels](https://github.com/FlowFuse/node-red-dashboard/issues/555){rel="&#x22;nofollow&#x22;"}.

If there are any other features you'd like to see, please do open a [Feature Request](https://github.com/FlowFuse/node-red-dashboard/issues/new/choose){rel="&#x22;nofollow&#x22;"}, and we'll do our best to accommodate.

## Getting Started with FlowFuse Dashboard

If you're ready to get started with FlowFuse Dashboard, you can install it directly from the Node-RED Palette Manager. Simply search for `@flowfuse/node-red-dashboard` and install the latest version.

![A short recording to show how easy it is to setup your first dashboard](https://dashboard.flowfuse.com/assets/getting-started.DHDsIsZl.gif){dataZoomable=""}*A short recording to show how easy it is to setup your first dashboard*

Getting started is as easy as dropping on your first node. FlowFuse Dashboard will automatically set you up with a default group, page, theme and underlying Dashboard configuration.

### Resources

We have a comprehensive [Getting Started Guide](https://dashboard.flowfuse.com/getting-started.html){rel="&#x22;nofollow&#x22;"} that will walk you through the process of setting up your first Dashboard. You can download our ["Ultimate Guide" eBook](https://dashboard.flowfuse.com/#download-our-e-book){rel="&#x22;nofollow&#x22;"} too.

### Dashboard Workshop

We'll running a [Workshop](https://flowfuse.com/webinars/2024/workshop-dashboard) on July 2nd, where we will be covering a collection of useful tips and design patterns to help you get the most out of Dashboard.

The recording will also be available on the [FlowFuse YouTube channel](https://www.youtube.com/@FlowFuseInc){rel="&#x22;nofollow&#x22;"} after the event.

## Migrating to FlowFuse Dashboard

If you're looking to migrate your existing Node-RED Dashboard flows to FlowFuse Dashboard, we have a [Migration Guide](https://flowfuse.com/platform/dashboard/#migration-service) that details all of the features and properties that have, and haven't, been migrated into FlowFuse Dashboard.

It's worth noting that FlowFuse Dashboard *will* run side-by-side with the original Node-RED Dashboard, so you can take your time to migrate your flows over, and do so, piece-by-piece.

This week, we also made available the first iteration of the [Dashboard Migration Service](https://flowfuse.com/platform/dashboard/#migration-service):

![Screenshot showing the Dashboard Migration Service available on FlowFuse's website](https://flowfuse.com/blog/2024/06/images/dashboard-migration-service.png){dataZoomable=""}*Screenshot showing the Dashboard Migration Service available on FlowFuse's website*

Currently, it'll convert your `ui_tab`, `ui_group` nodes, and setup your new `ui-theme` and `ui-base` nodes for you. We'll be extending this over time, and eventually hope to auto-convert most of your existing Dashboard 1.0 flows.

## Final Thoughts

We're really excited to see what you can build with FlowFuse Dashboard, and we're here to help you every step of the way. If you have any questions, please do reach out to us on the [Node-RED Community Forum](https://discourse.nodered.org/tag/dashboard-2){rel="&#x22;nofollow&#x22;"}.

If you're interested in contributing and extending FlowFuse Dashboard, we're very open to Pull Requests, and have a detailed contributing guide you can take a look at [here](https://dashboard.flowfuse.com/contributing/){rel="&#x22;nofollow&#x22;"}.


# Multi-Tenancy available for everyone with FlowFuse's Dashboard 2.0

FlowFuse Dashboard has featured multi-tenancy features through the FlowFuse User Addon. This made user based applications available only to specific FlowFuse team tiers and customers. However, the Node-RED community wanted to use the same feature set in cases FlowFuse didn't consider initially. Taking this feedback on board, today we announce some significant changes to how you can build Dashboards with multi-tenancy in mind.

Having taken that feedback on board, we've made some significant changes to how you can build Dashboards with multi-tenancy in mind.

:product-update-note

A quick summary of the changes are as follows:

- **Socket constraints moved to core Dashboard:** The ability to constrain communications to a specific client (using the `msg._client.socketId`) has been moved to the core of Dashboard 2.0, and is no longer a feature of the FlowFuse User Addon. As such, it's available to *all* users, for *all* node types.
- **FlowFuse User Addon now Source Available:** The addon is available to install in *any* instances of Node-RED running on FlowFuse, so that's all team tiers on FlowFuse Cloud, and any self-hosted instances of FlowFuse too. It is available to install from Node-RED's Palette Manager.
- **Cloudflare Auth Plugin:** Release of the first community-created Auth Plugin for Dashboard for adding a `user` object when authenticating with Cloudflare. (See more details and install the plugin [here](https://flows.nodered.org/node/@fullmetal-fred/node-red-dashboard-2-cloudflare-auth){rel="&#x22;nofollow&#x22;"})

## Using Client Data

Available since our `1.10.0` release of Dashboard, we have a new sidebar tab - "Client Data".

This new tab acts as a portal to control whether data about the connected clients is included in any events emitted in the Node-RED editor (appended into `msg._client`). You can then use the "Accept CLient Data" options to define which nodes accept that data as a constraint for communication.

![Screenshot showing the new "Client Data" sidebar available with Dashboard](https://flowfuse.com/blog/2024/06/images/dashboard-multi-tenancy-sidebar.png){dataZoomable=""}*Screenshot showing the new "Client Data" sidebar available with Dashboard*

In this case, if we send a `msg` to any `ui-notification` or `ui-control` which a specified `msg._client.socketId`, then that `msg` will *only* be sent to the relevant socket connection.

## Building Multi-Tenant Dashboards

We have introduced a new section to our documentation on [Design Patterns](https://dashboard.flowfuse.com/getting-started.html#design-patterns){rel="&#x22;nofollow&#x22;"}.

To summarise briefly, we now consider there to be two primary design patterns when building with Dashboard:

- **Single Source of Truth**: All users of your Dashboard will see the same data. This is useful for industrial IoT or Home Automation applications.
- **Multi-Tenancy**: Data shown in a particular widget is unique to a given client/session/user. This represents a more traditional web application, where each user has their own session and associated data.

Note that these patterns can be intertwined, some widgets on a screen may be driven by "Single Source of Truth", and others by "Multi-Tenancy".

#### Building a Single Source of Truth Dashboard

![Example flow diagram to show the flow of data in a "Single Source of Truth" architecture](https://flowfuse.com/blog/2024/06/images/design-pattern-single.png){dataZoomable=""}*Example flow diagram to show the flow of data in a "Single Source of Truth" architecture*

Data can be sent to these widgets at any time, when a user connects to the Dashboard, the respective widget will load the relevant data from the centralised data source in Node-RED and show it to the user.

#### Building a Multi-Tenancy Dashboard

![Example flow diagram to show the flow of data in a "Multi-Tenancy" architecture](https://flowfuse.com/blog/2024/06/images/design-pattern-client.png){dataZoomable=""}*Example flow diagram to show the flow of data in a "Multi-Tenancy" architecture*

In this pattern, a very useful node is the `ui-event` node which fires a `msg` when a user views a page. This `msg` will contain a `msg._client` object, detailing the client's connection.

This `_client` object contains the `socketId` of the user (and potentially more depending on any [Authentication plugins](https://flowfuse.com/#authentication-plugins) used). This `msg` can then be passed through to any other widget, and if configured to "Accept Client Constraints" that `msg` will only be sent to the specified client.

## Authentication Plugins

In this release we've also added a special category of plugins, "Authentication Plugins".

These plugins register themselves with Dashboard, and are permitted to add to the `msg._client` object. This can be useful for adding additional information about end users, such as their user ID, e-mail address or username.

This data can be used to constrain communications from Node-RED to a specific *user* rather than just a *socket connection*, which is far more reliable and secure.

![Screenshot showing "FlowFuse User" being appended to \_client by the FlowFuse User Addon](https://flowfuse.com/blog/2024/06/images/dashboard-include-client-data.png){dataZoomable=""}*Screenshot showing "FlowFuse User" being appended to `_client` by the FlowFuse User Addon*

Any active plugins you have installed, will also be detailed in the new "Client Data" sidebar (detailed above) so you can see which plugins are active and what data they are adding to the `msg._client` object.

### FlowFuse User Addon

Whilst the plugin was first published a few months back, after hearing community feedback, we've made changes and are now publishing the plugin to the Node\_RED Palette Manager. As such, it's available to all users running FlowFuse.

The addon appends a `user` object to the `msg._client` object, populated with the details of the FlowFuse user performing the relevant actions in Dashboard. You can use this information to build multi-tenant Dashboards.

You can [install the FlowFuse User Addon](https://flows.nodered.org/node/@flowfuse/node-red-dashboard-2-user-addon){rel="&#x22;nofollow&#x22;"} from the Palette Manager in the Node-RED editor.

![Screenshot of the Instance settings in FlowFuse to enable "FlowFuse User Authentication"](https://flowfuse.com/blog/2024/06/images/flowfuse-instance-security.png){dataZoomable=""}&#x2A;Screenshot of the Instance settings in FlowFuse to enable "FlowFuse User Authentication"*

It's worth noting that instances must have ["FlowFuse User Authentication"](https://flowfuse.com/blog/2024/04/displaying-logged-in-users-on-dashboard/#enabling-flowfuse-user-authentication) switched on in the instance's settings.

### Cloudfare User Addon (Community Contribution)

We're also thrilled to announce that the first community-contributed plugin has been [published](https://flows.nodered.org/node/@fullmetal-fred/node-red-dashboard-2-cloudflare-auth){rel="&#x22;nofollow&#x22;"} which will append a `user` object to the `msg._client` object when authenticating with Cloudflare.

A huge thanks to Fred Loucks ([@fullmetal-fred](https://github.com/fullmetal-fred){rel="&#x22;nofollow&#x22;"} on GitHub) for his great contribution!

## Build Multi Tenant Dashboards with FlowFuse Cloud

Start by following our [Getting Started Guide](https://dashboard.flowfuse.com/user/multi-tenancy.html#building-multi-tenant-dashboards){rel="&#x22;nofollow&#x22;"}.


# FlowFuse 2.5: New features to visualize snapshots, LDAP integration, and more

FlowFuse 2.5 introduces LDAP integration, snapshot comparison, extends the ability to preview flow to Blueprints, rounds out the management for snapshots, and allows you to point your own domain names at your FlowFuse instances.

## Support for LDAP integration [#2558](https://github.com/FlowFuse/flowfuse/issues/2558){rel="&#x22;nofollow&#x22;"}

In our commitment to making FlowFuse more versatile and secure, we've introduced support for LDAP alongside our existing SAML SSO options. This has been a much requested feature that we are excited to release. This allows organizations to manage user authentication seamlessly, leveraging their existing LDAP infrastructure. With this feature, you can ensure that access controls are robust and aligned with your company's security policies.

## Compare Snapshots Visually to see differences [#3624](https://github.com/FlowFuse/flowfuse/issues/3624){rel="&#x22;nofollow&#x22;"}

Keeping track of changes and updates has never been easier. With our new visual comparison tool, you can now compare snapshots and see the differences at a glance. This feature provides a clear, graphical representation of changes, making it simple to identify modifications and understand their impact.

## Preview Blueprints before Deployment [#3838](https://github.com/FlowFuse/flowfuse/issues/3838){rel="&#x22;nofollow&#x22;"}

Similarly to the feature to be able to compare snapshots we have enabled this same feature to allow users to preview team flows and blueprints prior to deploying. This expedites the process when you are attempting to find the correct flow for your application. We find that our users will be able to expedite the exploration of both their own team library and the blueprints.

## Import and Export support for snapshots [#3628](https://github.com/FlowFuse/flowfuse/issues/3628){rel="&#x22;nofollow&#x22;"}

Managing your Node-RED artifacts just got simpler with our new import and export support for snapshots. With just a few clicks, you can easily transfer configurations between deployments or back up your current setup. This feature is perfect for those who need to replicate environments within their own enterprise with multiple deployments or ensure their configurations are safely stored.

## Deploy Dashboard and APIs running on Flowfuse via your own Domain Names [#324](https://github.com/FlowFuse/flowfuse/issues/324){rel="&#x22;nofollow&#x22;"}

Branding and accessibility are crucial, and with FlowFuse 2.5, you can now deploy dashboards and APIs on your own domain names. This enhancement allows you to present a consistent brand experience and makes it easier for users to access your services. Whether you're deploying internally or externally, this feature provides the flexibility you need.

## Full list of release features and bug fixes

You can view everything included in 2.5 on the [Github Release page](https://github.com/FlowFuse/flowfuse/releases/tag/v2.5.0){rel="&#x22;nofollow&#x22;"}.

We also regularly release updates to \[FlowFuse Cloud]\({{ site.appURL }}) in between our monthly releases. You can follow the updates as they are made via our [ChangeLog](https://flowfuse.com/changelog).

## What's next?

We're always working to enhance your experience with FlowFuse. Here's how you can stay informed and contribute:

- **Roadmap Overview**: Check out our [Product Roadmap Page](https://flowfuse.com/changelog/) to see what we're planning for future updates.
- **Entire Roadmap**: Visit our [Roadmap on GitHub](https://github.com/orgs/FlowFuse/projects/5){rel="&#x22;nofollow&#x22;"} to follow our progress and contribute your ideas.
- **Feedback**: We're interested in your thoughts about FlowFuse. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try it out

We're confident you can have self managed FlowFuse running locally in under 30 minutes.
You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

If you'd rather use our hosted offering: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} on FlowFuse Cloud.

## Upgrading FlowFuse

\[FlowFuse Cloud]\({{ site.appURL }}) is already running 2.5.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go to the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# Working with MQTT in Node-RED: Complete Guide (2026)

MQTT handles the messaging layer for most IoT deployments. Node-RED provides built-in nodes that connect to MQTT brokers, subscribe to topics, and publish messages, all through a visual interface.

:product-update-note

This guide walks through the configuration steps and common patterns you'll need for working implementations.

## What You'll Need

Before you start, make sure you have:

- **Node-RED Instance**: You need Node-RED running somewhere. Easiest option is FlowFuse, grab a [free trial](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"} and you get a cloud-hosted instance ready to go. No server setup, no port forwarding hassles.
- **MQTT Broker**: You'll need an MQTT broker to handle message routing. If you're on FlowFuse Pro tier, you get a built-in MQTT broker service, no separate setup needed.

## Getting Connected

Node-RED ships with MQTT nodes already installed. Open your Node-RED editor and look in the palette, you'll find **mqtt-in** and **mqtt-out** under the network section.

> If you're using FlowFuse's managed MQTT broker, this is straightforward. Use the [ff-mqtt-in](https://flowfuse.com/node-red/flowfuse/mqtt/mqtt-in/) and [ff-mqtt-out](https://flowfuse.com/node-red/flowfuse/mqtt/mqtt-out/) nodes instead of the standard MQTT nodes. Simply drag one onto the canvas, and the connection to FlowFuse's broker will be configured automatically.

For any other broker, drag an **mqtt-in** or **mqtt-out** node onto your workspace. Double-click it to open the configuration panel.

Click the pencil icon next to **Server**. You'll see two tabs: Connection and Security.

**Connection Tab**

![MQTT broker connection configuration screen showing server address, port, and protocol settings](https://flowfuse.com/blog/2024/06/images/mqtt-broker-config.png "MQTT Connection Tab - Configure broker address, port, and TLS settings"){dataZoomable=""}

1. **Server**: Enter your broker address (`broker.hivemq.com` for testing, or your broker's hostname)
2. **Port**: Use `8883` for encrypted connections, `1883` for unencrypted
3. **Enable TLS**: Check this if you're using port 8883
4. **Protocol**: Leave it at MQTT 3.1.1 unless you specifically need MQTT 5 features

**Security Tab**

![MQTT broker security configuration showing username and password fields](https://flowfuse.com/blog/2024/06/images/mqtt-configuration-security-tab.png "MQTT Security Tab - Enter credentials using environment variables for security"){dataZoomable=""}

Enter your username and password. For anything beyond local testing, use environment variables:

- Put `${MQTT_USER}` in the username field
- Put `${MQTT_PASSWORD}` in the password field

Set these in your Node-RED settings or FlowFuse environment config

> See [Using Environment Variables in Node-RED](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/) for setup details.

Click **Add**, then **Done**. Deploy your flow. If the node shows "connected" under it, you're in.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

## Publishing Data to a Topic on MQTT Broker

The mqtt-out node sends data from Node-RED to your MQTT broker. Configure the topic, quality of service level, and retention settings to control how your messages are delivered.

1. Drag an **mqtt-out** node onto the canvas.
2. Double-click the **mqtt-out** node and select your broker from the **Server** dropdown.
3. Enter your topic name in the **Topic** field. Use forward slashes for hierarchy like `factory/line1/temp`.
4. Set **QoS** to **2** for guaranteed delivery. Use **1** if you can tolerate occasional duplicates, or **0** for high-frequency data where missing readings don't matter.
5. Enable **Retain** if new subscribers should immediately receive the last published value.
6. Connect your data source to the mqtt-out node's input. The node expects `msg.payload` to contain your data.

![MQTT-out node configuration panel settings](https://flowfuse.com/blog/2024/06/images/mqtt-out.png "MQTT-out Node Configuration"){dataZoomable=""}

## Subscribing to a Topic on MQTT Broker

The mqtt-in node receives messages from topics you specify. You can subscribe to specific topics or use wildcards to monitor multiple topics at once.

1. Drag an **mqtt-in** node onto the canvas.
2. Double-click the **mqtt-in** node and select your broker from the **Server** dropdown.
3. Set **Action** to **subscribe to a single topic** and enter the topic name in the **Topic**field. You can use:
   - Specific topics: `factory/line1/temp`
   - Single-level wildcard: `factory/+/temp` (matches any value where + appears)
   - Multi-level wildcard: `factory/#` (matches everything under factory/)
4. Set **QoS** to **2**.
5. Set **Output** to **auto-detect** (it parses JSON automatically and passes through other formats as strings).
6. Connect the mqtt-in node's output to wherever you need the data.

![MQTT-in node configuration showing subscription settings with topic field and QoS options](https://flowfuse.com/blog/2024/06/images/mqtt-in-config.png "MQTT-in Node Configuration"){dataZoomable=""}

**For Dynamic Subscriptions:**

If you need to change subscriptions at runtime based on user input or system conditions, set **Action** to **dynamic** instead. You'll control subscriptions by sending messages with `msg.topic` and `msg.action` to the node's input.

![MQTT-in node configured for dynamic subscription mode with empty topic field](https://flowfuse.com/blog/2024/06/images/mqtt-in-dynamic.png "MQTT-in Dynamic Mode"){dataZoomable=""}

To subscribe dynamically, send a message like:

```javascript
msg.topic = "factory/line1/temperature";
msg.action = "subscribe";
```

To unsubscribe:

```javascript
msg.topic = "factory/line1/temperature";
msg.action = "unsubscribe";
```

This is useful when users select which equipment to monitor from a dashboard, when topics depend on database queries or API responses, or when you need to add and remove subscriptions without redeploying your flow.

## Deploying the Flow

Deploy your flow to activate the MQTT connection and start sending or receiving messages.

1. Click the **Deploy** button at the top-right corner.

*Tip: Check the node status below each MQTT node. It will display 'connected' if the connection is successful.*

![MQTT nodes in Node-RED editor showing green connected status indicators below each node](https://flowfuse.com/blog/2024/06/images/mqtt-node-status.png "MQTT Node Status - Green 'connected' indicator confirms successful broker connection"){dataZoomable=""}

## Best Practices

Production MQTT deployments need more than basic configuration. These practices separate hobby projects from industrial-grade systems that run 24/7 without issues.

### Security First

**Always use TLS encryption.** Unencrypted MQTT sends credentials and data in plain text across your network. Enable port 8883 with TLS on your broker, then check the **Enable TLS** box in your Node-RED broker configuration. No exceptions for production systems.

**Never hardcode credentials.** Putting usernames and passwords directly in nodes means anyone with access to your flows can see them. Use environment variables instead:

```text
Username: ${MQTT_USER}
Password: ${MQTT_PASS}
```

Set these in your Node-RED settings file or FlowFuse environment configuration. See [Using Environment Variables in Node-RED](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/) for the complete setup.

**Implement access control on your broker.** Not every device needs to publish and subscribe to every topic. Configure your MQTT broker's ACL (Access Control List) to restrict clients based on their role. Sensors should only publish to their specific topics. Dashboard applications should only subscribe to what they display. This limits damage if credentials get compromised.

### Choose the Right QoS

QoS isn't a "set it and forget it" decision. Each level trades reliability against network overhead and latency.

**QoS 0:** Fire and forget. Use for high-frequency sensor data where missing one reading doesn't matter.

**QoS 1:** Guaranteed delivery, possible duplicates. Good for status updates and notifications.

**QoS 2:** Exactly once delivery with higher latency. Use for commands that trigger actions or critical transactions.

Match QoS to your use case. Don't default everything to QoS 2 just to be safe, you'll waste bandwidth and add latency where it doesn't help.

### Design Your Topic Hierarchy Properly

Your topic structure determines how easy it is to filter, subscribe, and scale your system. A hierarchical approach mirrors your physical setup and makes wildcards useful.

**Structure topics from general to specific:**

```text
company/location/area/equipment/measurement
```

**Good hierarchy:**

```text
acme/chicago/packaging/filler-01/temperature
acme/chicago/packaging/filler-01/pressure
acme/denver/assembly/robot-03/temperature
acme/denver/assembly/conveyor-02/speed
```

**Poor hierarchy:**

```text
temp-sensor-1
temp-sensor-2
pressure-sensor-1
line1-data
```

The difference: with a proper hierarchy, you can subscribe at any level. Need all data from Chicago? Subscribe to `acme/chicago/#`. Want temperature readings across all sites? Use `acme/+/+/+/temperature`.

Flat topics force you to subscribe to dozens of individual topics and manage them manually. Hierarchical topics let the broker do the filtering.

**Keep it simple:** Use lowercase, separate levels with forward slashes, use hyphens within names. Topics are paths, not sentences.

## Conclusion

You now know how to connect Node-RED to MQTT brokers, publish data to topics, subscribe to incoming messages, and secure your deployment with TLS and proper credentials. That's the foundation.

Go build something. Connect a sensor, route the data, display it somewhere useful. The patterns you've learned here scale from a single device to entire factory floors.

When you hit the limits of managing individual instances (tracking deployments, coordinating updates, maintaining uptime across sites), that's when tools like [FlowFuse](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} become relevant. Until then, you have everything you need.


# Interacting with Google Sheets from Node-RED (2026)

Have you ever needed to integrate Google Sheets with your Node-RED application to track and manage data seamlessly? This guide will walk you through the process of integrating Google Sheets with Node-RED, enabling you to write, read, update, and delete data effortlessly.

## What is the Google Sheet?

[Google Sheets](https://www.google.com/sheets/about/){rel="&#x22;nofollow&#x22;"} is a cloud-based spreadsheet application developed by Google. It allows users to create, edit, and collaborate on spreadsheets in real-time over the Internet. This makes it an ideal option for easily and securely collaborating on data that is not large in size. In businesses, Google Sheets is commonly used for tasks such as analyzing daily profits, tracking expenses, and managing collaborative projects. However, for products or services with large user bases, businesses often prefer using databases, which are recommended for efficiently managing and scaling data operations.

## Prequisite

Before proceeding, make sure you have installed the following node from the pallet manager.

- [node-red-contrib-google-sheets](https://flows.nodered.org/node/node-red-contrib-google-sheets){rel="&#x22;nofollow&#x22;"}

## Interacting with Google Sheets with Node-RED

To integrate Google Sheets with our application we must first enable the Google Sheets API, and create the service account in the Google Cloud, before proceeding, make sure you have the Google Cloud account created.

1. Open your browser and go to [Service accounts](https://console.cloud.google.com/projectselector2/apis/library/sheets?supportedpurview=project&authuser=0){rel="&#x22;nofollow&#x22;"}.
2. Create a new project by clicking the "CREATE PROJECT" button in the top right corner. Enter the project details such as project name and organization.

![Screenshot showing the 'CREATE PROJECT' button](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_1.png "Screenshot showing the 'CREATE PROJECT' button"){dataZoomable=""}

!["Screenshot showing the Form to create the project"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_2.png "Screenshot showing the Form to create the project"){dataZoomable=""}

3. Go to the main menu by clicking the menu icon in the top left, then select "APIs & Services."

!["Screenshot showing the 'APIs & Services' from the menu"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_3.png "Screenshot showing the 'APIs & Services' option from the main menu"){dataZoomable=""}

4. Click on "Enable APIs and Services" in the header.

!["Screenshot showing the 'Enable APIs and Services' option](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_4.png "Screenshot showing the 'Enable APIs and Services' option"){dataZoomable=""}

5. In the search bar, type "Google Sheets" and select it from the results.

!["Screenshot showing the Google Sheet in the search result](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_5.png "Screenshot showing the Google Sheet in the search result"){dataZoomable=""}

6. Click the "Enable" button to enable the Google Sheets API.

!["Screenshot showing the 'Enable' button"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_6.png "Screenshot showing the 'Enable' button"){dataZoomable=""}

7. Go back to the main menu and click on "IAM & Admin," then select "Service Accounts" from the left sidebar.

!["Screenshot showing the 'IAM & Admin' from the menu"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_7.png "Screenshot showing the 'IAM & Admin' from the menu"){dataZoomable=""}

8. Click on "Create Service Account" in the header. Enter the necessary details and click "Create" to proceed.

!["Screenshot showing the 'Create Service Account' option"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_8.png "Screenshot showing the 'Create Service Account' option"){dataZoomable=""}

!["Screenshot showing the 'Create' button"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_9.png "Screenshot showing the 'Create' button"){dataZoomable=""}

9. Select the Role from the "Owner" and click on the "Continue" button.

!["Screenshot showing the 'Continue' button"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_10.png "Screenshot showing the 'Continue' button"){dataZoomable=""}

10. Click "Done." Make sure to copy the generated service account email and save it for later use.

!["Screenshot showing the 'Done' button"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_11.png "Screenshot showing the 'Done' button"){dataZoomable=""}

!["Screenshot showing the created service account email"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_14.png "Screenshot showing the created service account email"){dataZoomable=""}

11. To generate a private key, click on the three dots icon on the right of the newly created service account and select "Manage keys."

!["Screenshot showing the three dot icon"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_15.png "Screenshot showing the three dot icon"){dataZoomable=""}

12. Click on "Add key," choose "Create new key," select "JSON" as the key type, and click "Create." Your private key will be generated and downloaded.

!["Screenshot showing the 'Add key' and the 'Create new key'"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_15.png "Screenshot showing the 'Add key' and the 'Create new key'"){dataZoomable=""}

!["Screenshot showing the 'JSON' option and 'Create new key' button"](https://flowfuse.com/blog/2024/06/images/interacting-with-google-sheet-from-node-red-delete-page_13.png "Screenshot showing the 'JSON' option and 'Create new key' button"){dataZoomable=""}

### Configuring the Google Sheet Node

Before proceeding, ensure you have added the [environment variable](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/) for the private key that was generated. Additionally, grant the editor access to the sheet you want to interact with for that service account email we created in the above section.

1. Drag a GSheet node onto the canvas.
2. Double-click on the node and click on the pencil icon next to "creds."
3. Enter the environment variable added for the private key in the "creds" field and click "Add."
4. Go to the Google Sheet you want to interact with and copy its ID from the URL. The URL will be in this format: `https://docs.google.com/spreadsheets/d/<id_of_sheet>/`
5. Return to your Node-RED instance, double-click on the GSheet node again, and paste the spreadsheet ID into the "SpreadsheetID" field.
6. Enter the range of cells you want to work with using the syntax `<sheetname!first-cell-name:last-cell-name>`. For example, use `Sheet1!A1:C3` to specify that you are working with the "Sheet1" tab, starting from cell "A1" to cell "C3". This syntax allows you to define specific ranges such as a row (`A1:A5`), a column (`A1:E1`), or a block (`A1:C3`) within the spreadsheet.

### Writing Data to Cells

For demonstration purposes, I will write simulated sensor data which includes a timestamp and sensor data.

1. Drag the Inject node onto the canvas, and set `msg.payload` to `[$moment().format(), $random() * 100]` as a JSONata expression, and set it to repeat every 3 seconds of interval.
2. Double-click on the GSheet node, select the method to "Append Row" set the range to `<sheetname>!A2`, and replace `sheetname` with the name of your sheet. I have defined cell A2 because I want to start writing data from cell A2.
3. Drag the Debug node onto the canvas, which will help in debugging in case of any error.
4. Connect the output of the Inject node to the input of the GSheet node, and the output of the GSheet node to the input of the Debug node.

:video{ariaLabel="Video showing the write operation" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

This flow generates a timestamp and a random number. The data is formatted as an array because I want the timestamp (the first item of the array) to be placed in column A and the random number (the second item of the array) to be placed in column B. If you want to insert data into additional columns, you can add more items to the array. For example, if you add a third item to the array, it will be placed in column C, a fourth item will be placed in column D, and so on.

### Reading Data from Cells

1. Drag an Inject node onto the canvas.
2. Drag another GSheet node onto the canvas, and set the method to "Get Cells" and the range to `<sheetname>!A2:C1000`, as I wanted to read data from cell A2 to the next 1000 cells.
3. Drag a Debug node onto the canvas.
4. Connect the output of the Inject node to the input of the GSheet node, and the output of the GSheet node to the input of the Debug node.

:video{ariaLabel="Video showing the read operation" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

### Updating Data of Cells

1. Drag an Inject node onto the canvas, and set the updated value as the `msg.payload`.
2. Drag another GSheet node onto the canvas, and set the method to "Update Cells" and the range to `<sheetname>!A2`, as I wanted to update the value of cell A2.
3. Drag a Debug node onto the canvas.
4. Connect the output of the Inject node to the input of the GSheet node, and the output of the GSheet node to the input of the Debug node.

:video{ariaLabel="Video showing the update operation" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

### Deleting Data from Cells

1. Drag an Inject node onto the canvas.
2. Drag another GSheet node onto the canvas, and set the method to "Clear Cells" and the range to `<sheetname>!A2:C50`, as I wanted to clear the first 50 records.
3. Drag a Debug node onto the canvas.
4. Connect the output of the Inject node to the input of the GSheet node, and the output of the GSheet node to the input of the Debug node.

:video{ariaLabel="Video showing the delete operation" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

Below I have provided the complete flow that we have built through the guide, make sure to replace the environment variable with your environment variable added for the private key.

::render-flow
```json
[{"id":"7d0282761979574c","type":"inject","z":"baa50b8a4762ec1f","name":"Wrting data to the cells","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"[\t    $moment(),\t    $random()*100\t    \t]","payloadType":"jsonata","x":240,"y":140,"wires":[["eda23377d98e1a51"]]},{"id":"eda23377d98e1a51","type":"GSheet","z":"baa50b8a4762ec1f","creds":"d38cb80ae8574ea6","method":"append","action":"","sheet":"1TEEShkuxxrb3WH4NTFyk1COeDyWpgX1w6HN08ZezC7s","cells":"Sheet1!A2:C1000","flatten":false,"name":"","x":510,"y":140,"wires":[["3e670f575b8227d0"]]},{"id":"3e670f575b8227d0","type":"debug","z":"baa50b8a4762ec1f","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":760,"y":140,"wires":[]},{"id":"2c916b1d5c10dffe","type":"inject","z":"baa50b8a4762ec1f","name":"Read the cells data","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":210,"y":260,"wires":[["941c7fe7c7dbcbcd"]]},{"id":"941c7fe7c7dbcbcd","type":"GSheet","z":"baa50b8a4762ec1f","creds":"d38cb80ae8574ea6","method":"get","action":"","sheet":"1TEEShkuxxrb3WH4NTFyk1COeDyWpgX1w6HN08ZezC7s","cells":"Sheet1!A2:C3","flatten":false,"name":"","x":490,"y":260,"wires":[["f910d7637788361a"]]},{"id":"f910d7637788361a","type":"debug","z":"baa50b8a4762ec1f","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":760,"y":260,"wires":[]},{"id":"c20997333f9d4bda","type":"inject","z":"baa50b8a4762ec1f","name":"Updating the cells data","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"[\t   \"none\",\t   \"none\"\t    \t]","payloadType":"jsonata","x":220,"y":360,"wires":[["d9ca2a1e0614f764"]]},{"id":"d9ca2a1e0614f764","type":"GSheet","z":"baa50b8a4762ec1f","creds":"d38cb80ae8574ea6","method":"update","action":"","sheet":"1TEEShkuxxrb3WH4NTFyk1COeDyWpgX1w6HN08ZezC7s","cells":"Sheet1!A35","flatten":false,"name":"","x":510,"y":360,"wires":[["9febe629870b7a54"]]},{"id":"9febe629870b7a54","type":"debug","z":"baa50b8a4762ec1f","name":"debug 3","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":760,"y":360,"wires":[]},{"id":"c9ceec9844fa74a9","type":"inject","z":"baa50b8a4762ec1f","name":"Deleting the cells data","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":220,"y":460,"wires":[["b9cef9c376d1bea3"]]},{"id":"b9cef9c376d1bea3","type":"GSheet","z":"baa50b8a4762ec1f","creds":"d38cb80ae8574ea6","method":"clear","action":"","sheet":"1TEEShkuxxrb3WH4NTFyk1COeDyWpgX1w6HN08ZezC7s","cells":"Sheet1!A2:C20","flatten":false,"name":"","x":500,"y":460,"wires":[["a1766b498efb50f4"]]},{"id":"a1766b498efb50f4","type":"debug","z":"baa50b8a4762ec1f","name":"debug 4","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":780,"y":460,"wires":[]},{"id":"d38cb80ae8574ea6","type":"gauth","name":"Unknown"}]
```
::

## Conclusion

This guide demonstrated how to integrate Google Sheets with Node-RED for streamlined data management. We covered setting up the Google Sheets API, configuring Node-RED to interact with sheets, and performing actions like writing, reading, updating, and deleting data.


# Node-RED 4: Bringing better collaboration to FlowFuse Cloud

Node-RED 4.0 is the new major release of the project, which is at the heart of all we do at FlowFuse. It brings a range of new features that continue to make Node-RED the first choice for low-code development.

As [we wrote recently](https://flowfuse.com/blog/2024/05/product-strategy-updates/), our product mission statement is to provide the best way to build, manage and deploy Node-RED applications at scale, in reliable and secure production environments. This drives the work we do both within the FlowFuse platform and our contributions back into the Node-RED project.

The [Node-RED 4.0 release](https://nodered.org/blog/2024/06/20/version-4-0-released){rel="&#x22;nofollow&#x22;"} includes some of our recent contributions to improve the Build part of that mission - more specifically around the Collaborative Development part.

Within FlowFuse we already have features such as the [Team Library](https://flowfuse.com/docs/user/shared-library/) that help team members share their flows with each other. That works well when working across separate Node-RED instances, but we wanted to improve the experience when working with the *same* Node-RED instance.

There has been a common complaint from users in the community on how Node-RED handles multiple users editing flows at the same time. Our goal is to make collaboration as simple and natural as possible and Node-RED 4.0 brings us a big step forward.

## Multiplayer Mode

A key problem has been not knowing what other users were doing in the editor; not knowing that someone else was making changes until they deploy them, causing you to be interrupted in your own work to figure out how to pull their changes into your editor.

The new Node-RED Multiplayer Mode helps to address this by showing you who else has the editor open and 'where' they are in the editor - such as which tab they have open, or if they are currently editing a node.

!["Screenshot of Node-RED multiplayer in action"](https://flowfuse.com/blog/2024/06/images/nr4-multiplayer.png "Screenshot of Node-RED multiplayer in action")

This is just the first step to our eventual goal of being able to see the changes others are making in real-time.

## Concurrent Deploy Handling

A second thread to this work has been to improve the workflow when someone deploys changes whilst you're busy working on your own flows.

With previous versions of Node-RED, each time someone deployed changes, you would receive a notification you couldn't ignore - having to deal it before you could continue what you were doing. Getting one notification wasn't so bad, but if your team mate was being particularly productive, they might be hitting the deploy button regularly - each time interrupting your own flow.

With Node-RED 4.0, we've made some small adjustments that should have a big impact. The notification that someone has deployed changes in the background is now much more discrete - and can be ignored entirely. Only when you want to deploy your changes will you need to merge in their changes first. This lets you stay in the zone whilst working, keeping the interruptions to a minimum.

!["Screenshot of the new background deploy notification"](https://flowfuse.com/blog/2024/06/images/nr4-background-deploy.png "Screenshot of the new background deploy notification")

## Other Updates

There are of course many other great reasons to start using Node-RED 4.0. The [community blog post](https://nodered.org/blog/2024/06/20/version-4-0-released){rel="&#x22;nofollow&#x22;"} describes all the other great features in this release.


# Building on FlowFuse: Remote Device Monitoring

FlowFuse has established a rich ecosystem of products to help you build bespoke, powerful, low-code applications.

We've seen customers utilizing these to [revolutionise precision manufacturing](https://flowfuse.com/customer-stories/leveraging-node-red-and-flowfuse-to-automate-precision-manufacturing/), [automate building management](https://flowfuse.com/customer-stories/node-red-building-management/) and [modernize the distribution of global weather data](https://flowfuse.com/customer-stories/un-wmo-nr-data-sharing/), just to name a few examples.

In this series of articles, we'll be taking a look at the common architectures and design patterns we are seeing used across our customer base, and how you can use these to build your own applications. To kick things off, this article will focus on &#x2A;*"Remote Device Monitoring"**.

## Use Case

You have hundreds, if not, thousands of devices deployed remotely. These could be anything from sensors, to actuators, to entire machines. You need to monitor these devices, and potentially control them. It's important to know when they are online, that they're running optimally and if something is about to, or already has, gone wrong.

![Diagram showing the breakdown of each component that makes up a "Device Monitoring" use case.](https://flowfuse.com/blog/2024/07/images/device-monitoring-use-case.png){dataZoomable=""}&#x2A;Diagram showing the breakdown of each component that makes up a "Device Monitoring" use case.*

Breaking it down we have the following fundamental requirements:

- **Read:** Reading data from the devices using the relevant protocol
- **Parse:** Process the data into a computational format
- **Compute/Monitor:** Analysis & monitoring of the data from all devices
- **Action:** Taking action based on the data from the devices

Then, we have to consider that this functionality needs to be deployed out to thousands of devices. So, our final requirement is:

- **Maintain:** If we update functionality on one device, we may need to be able to easily roll those updates out to other devices. We need to sure it's easy to update and deploy to our devices, and if anything goes wrong, we should be able to easily find out what the problem is, and get easy access to fix it.

## Architecture

Let's consider an example architecture set in an automotive plant:

![Diagram showing the architecture of a "Device Monitoring" use case in an automotive plant.](https://flowfuse.com/blog/2024/07/images/device-monitoring-architecture.png){dataZoomable=""}&#x2A;Diagram showing an example architecture of a "Device Monitoring" use case in an automotive plant.*

- **Laser Welding Machine:** Here we have a small system built around a single piece of laser welding hardware. The hardware is connected to a PLC via local network, and the PLC is connected to a local server. Each component here can have Node-RED installed, managed by FlowFuse and accessible via the Device Agent. Node-RED would enable extraction of data from the hardware, and provide a local, bespoke, Dashboard on a nearby PC for monitoring the hardware.
- **Body Shop:** Here we have several piece of machinery, each with the "FlowFuse Device Agent" installed. This allows us to manage the Node-RED deployments on these machines remotely from FlowFuse, and easily extract data from the machines for analysis.
- **Plant:** We have multiple servers running at the Planet-level, generally one for each "Shop", each with their own Device Agent installed, again for easy remote management and deployment of Node-RED, e.g. Dashboards that provide a single HMI for monitoring hardware across a full shop. Here, we also have our instance of FlowFuse. This is the central point for managing all of our Node-RED deployments across the factory floor.
- **Company IT Dept:** The general IT department of the company would provide multiple servers and services, accessible to a range of departments and the plant. Node-RED could act as a bridge between the Plant and the Company IT Dept, allowing us to easily extract data from the Plant and send it to the Company IT Dept, and vice-versa.
- **Cloud:** Here we demonstrate how a company may have external Cloud-based services they're dependent upon. For example, image analytics services. Node-RED can be used to parse machine imagery, and integrate straight with these external services from the FlowFuse server.

This diagram also demonstrates a sample of the rich ecosystem of communication protocols that Node-RED can support:

- **TCP:** Read and process data from from bespoke and custom devices
- **EtherNet/IP:** Collect data from Allen Bradley and other EtherNet/IP devices
- **MQTT:** Modern devices and factory generated IIoT data
- **OPC-UA:** Communicate with newer PLCs and OPC Servers
- **Modbus:** Data collection from existing Modbus enabled devices like Temperature Probes, Invertors, Encoders
- **MC Protocol:** Gather data from Mitsubishi PLCs
- **FINS:** Gather data from OMRON PLCs
- **Siemens S7:** Gather data from Siemens PLCs using the S7 Protocol

### FlowFuse Technology Stack

Given the above architecture, let's take a look at the relevant FlowFuse offerings and see what they're contributing:

![Lineup of each of the FlowFuse offerings](https://flowfuse.com/blog/2024/07/images/ff-ecosystem-lineup.png){dataZoomable=""}

- **Node-RED:** Low-code, drag-and-drop integration platform. Here we'd be using it in multiple places to read and parse data from the hardware, define the application logic, conduct analysis and provide alerting.
- **FlowFuse Dashboard:** An add-on to Node-RED for building interactive user interfaces and dashboards. We use this here to provide visual feedback on local Dashboards for some devices, as well as at the Planet-level to provide an at-a-glance view of our plant.
- **FlowFuse:** Centralized platform that provides a single entry point to manage all of your Node-RED applications and deployments, from your device inetrgators, through to your dashboards. FlowFuse provides role-based access control out of the box, so we can easily control who has access to flows, Dashboards and other configurations.
- **FlowFuse Device Agent:** Installed onto the relevant servers and hardware, this links you directly, and securely to FlowFuse. Here, we're deploying it to multiple pieces of machinery, as well as local servers, such that we can easily manage (deploy, upgrade, debug) all of those Node-RED deployments remotely from FlowFuse.
- **FlowFuse Project Nodes:** A small collection of nodes for Node-RED, running on FlowFuse, that provide communication over a secure (MQTT-based) connection between devices (our Node-RED deployments on our hardware in this case) and our hosted instances of Node-RED on FlowFuse. Extremely useful for reporting live sensor data back to FlowFuse for analysis, and for reporting information back to our devices.


# Calling a Python script from Node-RED (2026)

Python's robust data processing capabilities and extensive libraries are well-known in programming. When combined with Node-RED, these technologies can synergize to elevate data analytics and automation. This guide walks you through integrating Python scripts with Node-RED. You'll gain practical insights, troubleshooting tips, and effective techniques for executing scripts, enabling you to leverage this powerful combination for your IoT projects.

## Why use python with Node-RED

Integrating Python and Node-RED can significantly enhance your IoT and automation initiatives by leveraging their distinct strengths. Node-RED excels in creating easy workflows, efficiently processing data streams, and integrating hardware, APIs, and. Meanwhile, Python offers a rich set of libraries for advanced tasks such as machine learning and AI, pivotal in realizing Industry 4.0 concepts.

This combination allows developers to build robust and flexible solutions. For instance, while Node-RED manages data flow and device communication, Python can perform complex analytics, and predictive modeling, or integrate with AI frameworks. This integration bridges the gap between data collection and actionable insights, enabling systems to make informed decisions autonomously.

## Installing Python

When executing Python scripts, it's essential to have the Python runtime installed on your system. Before proceeding, make sure you have it installed. You can follow the [official guide](https://wiki.python.org/moin/BeginnersGuide/Download){rel="&#x22;nofollow&#x22;"} for instructions.

To verify if Python is installed, open your terminal and execute:

```bash
python --version
```

!["Screenshot of terminal showing the python version installed, conforming it is installed"](https://flowfuse.com/blog/2024/07/images/calling-python-script-from-node-red-py-conformation.png "Screenshot of terminal showing the python version installed, conforming it is installed"){dataZoomable=""}

The above command displays the version of Python installed on your system as shown in the above image. If the above command doesn't work, try:

```bash
python3 --version
```

The specific command to use depends on how Python was installed and configured on your system. However, make sure to use `python <filename>.py` if the first command works, or `python3 <filename>.py` if the second command works, while executing Python scripts.

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

## Executing Python Script from Node-RED

Let's now see how to call a Python script from Node-RED. First, we'll create a basic script file that contains a function to print text in the console based on input. Currently, the function uses hardcoded input. To create this file using Node-RED, import the following flow, deploy it, and press the inject button:

::render-flow
```json
[{"id":"b9d7d6aff0016631","type":"inject","z":"FFF0000000000001","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":240,"y":100,"wires":[["2e1daccf2a7b3d0f"]]},{"id":"d2d1450deaa588f4","type":"file","z":"FFF0000000000001","name":"","filename":".\\example.py","filenameType":"str","appendNewline":true,"createDir":false,"overwriteFile":"true","encoding":"none","x":570,"y":100,"wires":[["e140a8508fb10d96"]]},{"id":"e140a8508fb10d96","type":"debug","z":"FFF0000000000001","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":760,"y":100,"wires":[]},{"id":"2e1daccf2a7b3d0f","type":"template","z":"FFF0000000000001","name":"","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"def main():\n    # Hardcoded value\n    user_input = 20  \n    \n    # Check if the input is numeric\n    if isinstance(user_input, int) or (isinstance(user_input, str) and user_input.isdigit()):\n        number = int(user_input) if isinstance(user_input, str) else user_input\n        \n        # Conditionally render based on the input value\n        if number < 0:\n            print(\"Negative number entered\")\n        elif number == 0:\n            print(\"Zero entered\")\n        else:\n            print(\"Positive number entered\")\n    else:\n        print(\"Invalid input. Please enter a valid number.\")\n\nif __name__ == \"__main__\":\n    main()\n","output":"str","x":400,"y":100,"wires":[["d2d1450deaa588f4"]]}]
```
::

Now, let's execute this Python script from Node-RED. To do that, we will use Node-RED's [Exec](https://flowfuse.com/node-red/core-nodes/exec/) node, which allows running commands on your system.

1. Drag an Inject node onto the canvas.
2. Drag an Exec node onto the canvas and Configure the command to `python ./example.py -u`. The -u flag prevents potential output buffering issues when executing Python scripts via exec.

!["Screenshot of the Exec node executing python file"](https://flowfuse.com/blog/2024/07/images/calling-python-scrpt-from-node-red-exec-node.png "Screenshot of the Exec node executing python file"){dataZoomable=""}

3. Drag a Debug node onto the canvas.
4. Connect the output of the Inject node to the input of the Exec node, and the output of the Exec node to the input of Debug node.

::render-flow
```json
[{"id":"2e26b84c0ce17312","type":"exec","z":"FFF0000000000001","command":"python ./example.py -u","addpay":"","append":"","useSpawn":"false","timer":"","winHide":false,"oldrc":false,"name":"","x":460,"y":300,"wires":[["89589c56117004e0"],["7fdb901b144749c2"],["3f49b49308941782"]]},{"id":"739e08c1ec77c2a1","type":"inject","z":"FFF0000000000001","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":240,"y":300,"wires":[["2e26b84c0ce17312"]]},{"id":"89589c56117004e0","type":"debug","z":"FFF0000000000001","name":"Output","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":690,"y":260,"wires":[]},{"id":"7fdb901b144749c2","type":"debug","z":"FFF0000000000001","name":"Error","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":690,"y":300,"wires":[]},{"id":"3f49b49308941782","type":"debug","z":"FFF0000000000001","name":"Return code","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":710,"y":340,"wires":[]}]
```
::

Now, when you deploy this flow and click on the inject node to execute the file, you should see the text 'Positive number entered' and `{ code: 0 }`, which indicates your script has been successfully executed.

## Reading Temperature Sensor using Python script

Having explored how to run a Python script within Node-RED with the basic practical example, let's move to a real-world scenario. We'll demonstrate how to read sensor data using Python, despite Node-RED providing numerous community-built nodes for this purpose. This approach provides deeper insights into integrating external scripts, showcasing the flexibility of Node-RED for custom solutions.

Before proceeding, ensure that Node-RED is running on a device connected to a temperature sensor. For detailed instructions, refer to [Setting Up Node-RED on Different Hardware](https://flowfuse.com/node-red/hardware/), In this case, we are running Node-RED on a Raspberry Pi 5 with a DHT11 sensor connected to it.

1. Drag an Inject node onto the canvas, and set repeat to 1 seconds of interval.
2. Drag an Exec node and set the path to `python <filename>.py`, replace the filename with the name of the file which reads the sensor data, and make sure the python file doesn't contain the loop.
3. Drag the JSON node onto the canvas and set the action to "Always convert to JSON object".
4. Drag the Debug node onto the canvas.
5. Connect the output of the Inject node to the input of the Exec node and output of the Exec node to the input of the JSON node, and finally the JSON node's output to the input of the Debug node.

Below is the complete flow which creates the Python file to read the DHT11 sensor and executes that file after 1 second of interval. After deploying the flow you should able to see the sensor data on the debug sidebar as shown in the below image.

:video{ariaLabel="Video showing the Node-RED flow executing the python script that reads the sensor data" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}

Note: The Python script uses the [adafruit-circuitpython](https://docs.circuitpython.org/projects/dht/en/latest/index.html){rel="&#x22;nofollow&#x22;"} to read the sensor data so make sure to install it. Additionally, the code contained in the template node in the following flow considers that your sensor's signal pin is connected to GPIO 4.

::render-flow
```json
[{"id":"94bc6fa766c4b397","type":"file","z":"FFF0000000000001","name":"","filename":"~/sensor.py","filenameType":"str","appendNewline":false,"createDir":false,"overwriteFile":"true","encoding":"none","x":610,"y":520,"wires":[["9b08eee57f666de5"]]},{"id":"37453becdf842bd7","type":"template","z":"FFF0000000000001","name":"","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"import time\nimport board\nimport adafruit_dht\nimport json\n\ndef publish():\n    dhtDevice = adafruit_dht.DHT11(board.D4)\n    try:\n        temperature_c = dhtDevice.temperature\n        humidity = dhtDevice.humidity\n\n        # Create JSON object\n        data = {\n            \"temperature_c\": temperature_c,\n            \"humidity\": humidity\n        }\n\n        # Convert JSON object to string and print\n        print(json.dumps(data))\n\n    except RuntimeError as error:\n        print(error.args[0])\n    except Exception as error:\n        dhtDevice.exit()\n        raise error\n    finally:\n        dhtDevice.exit()\n\ndef run():\n    publish()\n\nif __name__ == '__main__':\n    run()\n","output":"str","x":380,"y":520,"wires":[["94bc6fa766c4b397"]]},{"id":"5b3642d39c122576","type":"debug","z":"FFF0000000000001","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":880,"y":660,"wires":[]},{"id":"88144cbc887aada9","type":"inject","z":"FFF0000000000001","name":"","props":[],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":150,"y":660,"wires":[["c896267214914641"]]},{"id":"1b1d792011ffac2c","type":"inject","z":"FFF0000000000001","name":"","props":[{"p":"kill","v":"g","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":150,"y":520,"wires":[["37453becdf842bd7"]]},{"id":"c896267214914641","type":"exec","z":"FFF0000000000001","command":"python ~/sensor.py -u","addpay":"payload","append":"","useSpawn":"false","timer":"5","winHide":false,"oldrc":false,"name":"","x":400,"y":660,"wires":[["1d02a33a018f0f8d"],[],[]]},{"id":"1d02a33a018f0f8d","type":"json","z":"FFF0000000000001","name":"","property":"payload","action":"","pretty":false,"x":650,"y":660,"wires":[["5b3642d39c122576"]]},{"id":"9b08eee57f666de5","type":"debug","z":"FFF0000000000001","name":"debug 3","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":880,"y":520,"wires":[]},{"id":"343a9f704951f3ed","type":"comment","z":"FFF0000000000001","name":"Create python file that reads the sensor data","info":"","x":510,"y":440,"wires":[]},{"id":"216eb1333b2c264c","type":"comment","z":"FFF0000000000001","name":"Execute the python file that read the data","info":"","x":500,"y":580,"wires":[]}]
```
::

## Executing Python Script with Arguments from Node-RED

Now, let's revisit our first example. In that example, we executed a simple Python file with a hardcoded value. Now, we'll learn how to pass arguments or inputs to the Python script when executing from Node-RED. For this, we'll need to update the file. Import the following flow, deploy it, and click on the inject button to create the file.

::render-flow
```json
[{"id":"b9d7d6aff0016631","type":"inject","z":"FFF0000000000001","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":300,"y":440,"wires":[["2e1daccf2a7b3d0f"]]},{"id":"d2d1450deaa588f4","type":"file","z":"FFF0000000000001","name":"","filename":"./example.py","filenameType":"str","appendNewline":true,"createDir":false,"overwriteFile":"true","encoding":"none","x":630,"y":440,"wires":[["e140a8508fb10d96"]]},{"id":"e140a8508fb10d96","type":"debug","z":"FFF0000000000001","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":820,"y":440,"wires":[]},{"id":"2e1daccf2a7b3d0f","type":"template","z":"FFF0000000000001","name":"","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"import sys\n\ndef main():\n    if len(sys.argv) != 2:\n        print(\"Usage: python your_script.py <number>\")\n        return\n    \n    user_input = sys.argv[1]\n    \n    # Check if the input is numeric\n    if user_input.isdigit() or (user_input[0] == '-' and user_input[1:].isdigit()):\n        number = int(user_input)\n        \n        # Conditionally render based on the input value\n        if number < 0:\n            print(\"Negative number entered\")\n        elif number == 0:\n            print(\"Zero entered\")\n        else:\n            print(\"Positive number entered\")\n    else:\n        print(\"Invalid input. Please enter a valid number.\")\n\nif __name__ == \"__main__\":\n    main()\n","output":"str","x":460,"y":440,"wires":[["d2d1450deaa588f4"]]}]
```
::

1. Drag the Inject node onto the canvas.
2. Drag the Exec node onto the canvas, set the command to `python -u ./example.py <arg>`, and replace the `<arg>` with your argument.
3. Now Drag the Debug node onto the canvas.
4. Connect the output of the Inject node to the input of the Exec node, and the output of the Exec node to the input of the Debug node.

If you examine the Python file we've created, you'll notice the use of the 'sys' module, which allows us to read command-line arguments. In our context, we execute the command `python ./example.py -30`. By accessing `sys.argv[1]`, we retrieve the argument -30. The index 1 is used because `sys.argv[0]` provides the filename of the script being executed. Additionally, Python supports passing multiple arguments, so that you can pass as many arguments as you want.

::render-flow
```json
[{"id":"2e26b84c0ce17312","type":"exec","z":"FFF0000000000001","command":"python -u ./example.py  -30","addpay":"","append":"","useSpawn":"false","timer":"","winHide":false,"oldrc":false,"name":"","x":520,"y":580,"wires":[["89589c56117004e0"],["7fdb901b144749c2"],["3f49b49308941782"]]},{"id":"739e08c1ec77c2a1","type":"inject","z":"FFF0000000000001","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":280,"y":580,"wires":[["2e26b84c0ce17312"]]},{"id":"89589c56117004e0","type":"debug","z":"FFF0000000000001","name":"Output","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":730,"y":540,"wires":[]},{"id":"7fdb901b144749c2","type":"debug","z":"FFF0000000000001","name":"Error","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":730,"y":580,"wires":[]},{"id":"3f49b49308941782","type":"debug","z":"FFF0000000000001","name":"Return code","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":620,"wires":[]}]
```
::

## Conclusion

In this guide, we've demonstrated how to seamlessly execute Python scripts from Node-RED, along with troubleshooting tips and instructions on passing arguments to scripts. By leveraging Python's extensive libraries for data processing, machine learning, and other tasks in conjunction with Node-RED, developers can build powerful IoT solutions with ease.


# New Charts Available in FlowFuse Dashboard

It's been a while coming, but we've finally introduced a new set of chart types to FlowFuse Dashboard. We've added Pie, Donut and Grouped (Stacks and Side-by-Side) Bar charts to the UI Chart node. We've also shipped plenty of other improvements and fixes in this release, so let's dive in.

## Grouped Bar Charts

We now have the option "Group By" available when building Bar Charts, with the options "Stacks" and "Side-by-Side". This allows you to group data in a more meaningful way, and is particularly useful when comparing multiple data sets.

### Stacks

![Screenshot showing a stacked bar chart with Dashboard](https://flowfuse.com/blog/2024/07/images/ui-chart-bar-grouped-finance-stacks.png){dataZoomable=""}*Screenshot showing a stacked bar chart with Dashboard*

### Side-by-Side

![Screenshot showing a side-by-side grouped bar chart with Dashboard](https://flowfuse.com/blog/2024/07/images/ui-chart-bar-grouped-finance.png){dataZoomable=""}*Screenshot showing a side-by-side grouped bar chart with Dashboard*

## Pie & Donut Charts

Radial charts are now available in Dashboard, with the introduction of Pie and Donut charts. These are particularly useful when you want to show the proportion of a single data set.

If you're using multiple "Series" here, then you'll get multiple nested radial charts, which can be particularly useful when comparing multiple data sets.

![Screenshot showing the new Pie and Donut charts available with Dashboard](https://flowfuse.com/blog/2024/07/images/ui-chart-pie-doughnut.png){dataZoomable=""}*Screenshot showing the new Pie and Donut charts available with Dashboard*

## General Chart Changes & Improvements

### Breaking Changes - Bar Charts

With the introduction of the new chart types, we've generalised the key mapping features for charts. Previously, Bar Charts were using the "Series" property to define how data is rendered onto the x-axis. In hindsight, this didn't really make any sense, it should be the "X" property that defines the data used on the x-axis, so we've corrected that going forward, but it did mean introducing a breaking change. We don't do this lightly, but in this case, it was necessary to ensure the charting experience is consistent across all chart types.

It does however mean that Bar Charts created in `1.13.0` or below will need to be updated to reflect this. You just need to set "X" to whatever you have in the "Series" property, and then set "Series" to "None".

### Mapping Your Data

#### Series

This property is now, consistently, how you want to group your data. If a new `msg` is coming in, and a property on that `msg` defines its group, then you can set "Series" to something like `msg.myCategory`.

If a single data point needs to plot multiple points/bars onto a chart, then you can use the "JSON" type here, and list the different properties you want to plot, one for each category.

For Radial charts (Pie & Donut), having multiple series would provide multiple, nested radial charts.

#### X

With this, we define which property (or *properties* if a single piece of data needs to plot multiple points/bars) we want to plot on the x-axis.

Note that on Radial charts (Pie & Donut), this is the value that defines the label of the segment.

#### Y

Which property should be used to define the y-axis value, i.e. height of the bar or the y-coordinate of a point on a scatter chart.

Note that on Radial charts (Pie & Donut), this is the value that defines the size of the segment.

#### Example: Plotting Star Wars Character Heights

The [Star Wars API](https://swapi.dev/){rel="&#x22;nofollow&#x22;"} is a free, open API that provides data on the Star Wars universe, an example API call can return details about particular characters, and the response is as follows:

```json
[{
    "name":"Luke Skywalker",
    "height":"172",
    "mass":"77",
    "hair_color":"blond",
    "skin_color":"fair",
    "eye_color":"blue",
    "birth_year":"19BBY",
    "gender":"male",
    ...
}, {
    ...
}]
```

We can configure a chart with the following "Mapping" options:

![Example mapping of data to a UI Chart for data coming from the Star Wars API](https://flowfuse.com/blog/2024/07/images/ui-chart-bar-sw-config.png){dataZoomable=""}*Example mapping of data to a UI Chart for data coming from the Star Wars API*

and this would then be the resulting chart:

![Example bar chart showing heights of Star Wars characters](https://flowfuse.com/blog/2024/07/images/ui-chart-bar-sw.png){dataZoomable=""}*Example bar chart showing heights of Star Wars characters*

Note, the chart takes in all of the data sent to it, uses the `name` field to define where on the x-axis the data should be plotted, and the `height` field to define the height of the bar (the y-axis).

You can read more about this example, and access the flow itself in our documentation [here](https://dashboard.flowfuse.com/nodes/widgets/ui-chart.html#bar-charts){rel="&#x22;nofollow&#x22;"}

## Live Dashboard Demo

![Screenshot of our new interactive Dashboard to demonstrate how charts render in FlowFuse Dashboard](https://flowfuse.com/blog/2024/07/images/dashboard-interactive-docs.png){dataZoomable=""}*Screenshot of our new interactive Dashboard to demonstrate how charts render in FlowFuse Dashboard*

With the new release also comes a new [Public Demo Dashboard](https://dashboard-demos.flowfuse.cloud/dashboard/charts-example){rel="&#x22;nofollow&#x22;"} that we've made available for all to use and play with.

You can try it out, and interact with a range of different chart types, including the new Pie, Donut and Grouped Bar charts. We'll also be extending this soon to cover the full range of widgets available in FlowFuse Dashboard.

If you want more technical detail, you can also check out our online documentation [here](https://dashboard.flowfuse.com/nodes/widgets/ui-chart.html){rel="&#x22;nofollow&#x22;"}.

## What else is new?

You can find the full 1.14.0 Release Notes [here](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v1.14.0){rel="&#x22;nofollow&#x22;"}.

Just to highlight a few, particularly valuable, updates and fixes:

- UI Button Group - Now supports `msg.enabled` to enable/disable the widget.
- UI Form - Now supports `msg.enabled` to enable/disable the widget.
- UI Button - Color customisation now available, without needing to write overriding CSS.
- UI Switch - Fix missing `msg.topic` when setting the topic to a static string.

## What's Next?

Work has already begun on the next release, `1.15.0`, you can see what items we have queued up [here](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}, if you've got any feedback or suggestions, please do let us know, and feel free to open new issues on our [GitHub](https://github.com/FlowFuse/node-red-dashboard/issues){rel="&#x22;nofollow&#x22;"}


# Deploying FlowFuse with Docker on an Ubuntu server

With Node-RED's increasing role in IoT, FlowFuse Cloud has become a favored platform for deploying production Node-RED applications. It offers [extensive features](https://flowfuse.com/platform/features/) at a low cost, reducing operational overhead. However, the cloud is not the only option we provide; we also offer a self-hosted option for users who prefer to deploy FlowFuse on their servers. This guide demonstrates how to deploy FlowFuse on your Ubuntu server using Docker, covering key aspects such as domain setup, email, SSL, and more for real-world production scenarios

*Note: While the approach provided in this article is an older method for deploying FlowFuse and still works, I recommend following the newer, simpler, and quicker approach. For more details, refer to the official [Docker documentation](https://flowfuse.com/docs/install/docker/).*

## What is Docker?

[Docker](https://docs.docker.com/guides/docker-concepts/the-basics/what-is-an-image/){rel="&#x22;nofollow&#x22;"} is an open-source platform that simplifies how applications are deployed, scaled, and managed through containerization. It enables you to package all components required by your project such as code, libraries, and dependencies into a single, portable unit known as a [Docker container](https://docs.docker.com/guides/docker-concepts/the-basics/what-is-a-container/){rel="&#x22;nofollow&#x22;"}. These containers ensure consistency in application environments and ease deployment by ensuring that applications run predictably across different computing environments, whether on a developer's laptop, a server, or a cloud platform.

## Deploying FlowFuse on Ubuntu server with Docker

Before proceeding, ensure you have your domain and a server with Ubuntu installed, and Docker is installed on it. For more information, refer to [Docker Compose Installation](https://docs.docker.com/compose/install/){rel="&#x22;nofollow&#x22;"}. Furthermore, If your server has Ubuntu installed without a GUI, you can connect to it from your computer using [SSH](https://itsfoss.com/set-up-ssh-ubuntu/){rel="&#x22;nofollow&#x22;"}, allowing you to run commands from your local computer on the server.

### Adding DNS records for your domain

To make your application accessible on the internet via your domain name, adding DNS records is crucial. These records serve as a vital link between your domain name (like example.com) and your server's IP address. They ensure that when users type your domain into their browsers, they're directed to the correct location where your application is hosted.

!["Screenshot of panel to add dns records provided by my domain provider"](https://flowfuse.com/blog/2024/07/images/domain-provider-panel.png "Screenshot of panel to add dns records provided by my domain provider")

1. Log in to your Domain Provider's Panel and access the DNS settings of the domain you want to use for the FlowFuse platform.
2. Add entry first entry type: "A", enter "@" into the name field (it points to the domain name itself), and the public IP of your Ubuntu server into the data field.
3. Add entry second entry type: "A", enter "\*" into the name field (adding \* serves as the [wildcard domain entry](https://docs.digitalocean.com/glossary/wildcard-record/){rel="&#x22;nofollow&#x22;"} to the IP address of the host running Docker, we are doing this because the FlowFuse application will be hosted on the `forge.your-domain-name.com` and when creating instances for each, our FlowFuse application will use unique subdomain ) and public IP of your Ubuntu server into the data field.
4. Add the last entry type: "A", and enter "www" into the name field (we are adding this because previously domain names used to have the www prefix) and the public IP of your Ubuntu server into the data field.

### Installing and configuring FlowFuse

FlowFuse uses Docker Compose to install and manage the required components. We have built and maintaining that Docker Compose project.

1. Download the latest release `tar.gz` from our [Docker Compose project](https://github.com/FlowFuse/docker-compose/releases/latest){rel="&#x22;nofollow&#x22;"}.

```bash
cd /opt
```

```bash
wget <link of the latest tar.gz release>
```

2. Unpack this release with the following command. Make sure to replace the release name with the actual release name that you downloaded:

```bash
    tar -xvzf vx.x.x.tar.gz
```

3. Enter the folder with the following command. Again, don't forget to replace the release name with the actual release name that you downloaded:

```bash
    cd docker-compose-x.x.x
```

4. Now, update the FlowFuse configuration file `flowforge.yml` with your domain name. Currently, it is configured with `example.com`. To update it quickly, use the following command:

```bash
    sed -i 's/example.com/<replace-with-your-domain-name>/g' ./etc/flowforge.yml
```

5. Next, update the Docker Compose configuration file `docker-compose.yml` with your domain:

```bash
    sed -i 's/example.com/<replace-with-your-domain-name>/g' ./docker-compose.yml
```

!["Screenshot the terminal showing the updates made in docker-compose.yml file"](https://flowfuse.com/blog/2024/07/images/docker-compose-update.png "Screenshot the terminal showing the updates made in docker-compose.yml file")

!["Screenshot the terminal showing the updates made in 'docker-compose.yml' file"](https://flowfuse.com/blog/2024/07/images/docker-compose-update-2.png "Screenshot the terminal showing the updates made in 'docker-compose.yml' file")

The `flowforge.yml` file was updated to include our domain in key fields: `domain`, `base_url`, and `broker.public_url`. These adjustments ensure that instance names on Docker platforms incorporate your domain, provide accurate URLs for accessing the platform, and specify the correct URL for devices to connect to the broker if different from `broker.url`. Additionally, in the `docker-compose.yml` file, we configured `VIRTUAL_HOST` and `LETSENCRYPT_HOST` to reflect our domain.

For more details on these configuration changes, refer to the [documentation](https://flowfuse.com/docs/install/configuration/#configuring-flowfuse).

### Securing Communication with SSL

Securing communication with [SSL (Secure Sockets Layer)](https://www.youtube.com/watch?v=SJJmoDZ3il8){rel="&#x22;nofollow&#x22;"} is crucial for protecting data transmitted between your users and the server. Adding SSL requires obtaining a certificate from a trusted certificate authority (CA) and configuring your server to use this certificate. Configuring SSL manually can be a headache, so we have provided a setup you need to enable.

1. Open the Docker Compose file in your editor:

```bash
    nano docker-compose.yml
```

2. Uncomment the following lines by removing the `#` symbol:

```yaml
    # - "./certs:/etc/nginx/certs"
```

```yaml
    # - "443:443"
    # environment:
      # - "HTTPS_METHOD=redirect"
```

```yaml
    # acme:
    #   image: nginxproxy/acme-companion
    #   restart: always
    #   volumes:
    #     - "/var/run/docker.sock:/var/run/docker.sock:ro"
    #     - "./acme:/etc/acme.sh"
    #   volumes_from:
    #     - nginx:rw
    #   environment:
    #     - "DEFAULT_EMAIL=mail@example.com"
    #   depends_on:
    #     - "nginx"
```

3. Update the lines with your domain and email associated with the domain, then save the file:

```yaml
    - "DEFAULT_EMAIL=your-email@example.com"

    - "LETSENCRYPT_HOST=mqtt.yourdomain.com"

    - "LETSENCRYPT_HOST=forge.yourdomain.com"
```

!["Screenshot the terminal showing the update made in docker-compose.yml file for ssl configuration"](https://flowfuse.com/blog/2024/07/images/docker-compose-yml-acme-update.png "Screenshot the terminal showing the update made in `docker-compose.yml` file for ssl configuration")

4. Open the `flowforge.yml` file in your editor:

```bash
    nano /etc/flowforge.yml
```

5. Update the `base_url` to start with `https://` instead of `http://` and the `broker.public_url` entry to start with `wss://` instead of `ws://`, then save the file.

```yaml
    base_url: https://yourdomain.com

    broker:
      public_url: wss://mqtt.yourdomain.com
```

!["Screenshot of the terminal showing the update made in 'broker's public\_url' in the flowforge.yml file for SSL configuration"](https://flowfuse.com/blog/2024/07/images/flowforge-yml-https-update.png "Screenshot of the terminal showing the update made in 'broker's public_url' in the `flowforge.yml` file for SSL configuration")

!["Screenshot of the terminal showing the update made in 'base\_url' in the flowforge.yml file for SSL configuration"](https://flowfuse.com/blog/2024/07/images/flowforge-yml-https-update2.png "Screenshot of the terminal showing the update made in 'base_url' in the `flowforge.yml` file for SSL configuration")

Now, when we start our application the acme container will also start and will generate the certificates with let's encrypt on demand for the forge app and then for each of the instances as they are started.

### Configuring FlowFuse to Enable and Use the Email Feature

FlowFuse platform allows you to send invitations to other users within the platform and via email. It also supports receiving critical alerts and resetting passwords through email. To use these features, you need to enable and configure email in FlowFuse with your email address. Before you begin, make sure you have an email ID with an app password. FlowFuse supports Gmail and Outlook emails.

#### Creating an App Password for Your Email

If you're unfamiliar with generating an app password, watch these helpful videos:

- [Creating a Gmail app password](https://www.youtube.com/watch?v=hXiPshHn9Pw){rel="&#x22;nofollow&#x22;"}
- [Creating an Outlook app password](https://www.youtube.com/watch?v=5ukSRLRDQIw){rel="&#x22;nofollow&#x22;"}

#### Enabling and Configuring Email in FlowFuse

1. Open the `flowforge.yml` config file in your editor:

```bash
    nano /etc/flowforge.yml
```

2. Update the email configuration section with your email details:

**For Gmail:**

```yaml
email:
  enabled: true
  debug: false
  smtp:
    host: smtp.gmail.com
    port: 465
    secure: true
    auth:
      user: your-email@gmail.com
      pass: your-app-password
```

**For Outlook:**

```yml
email:
  enabled: true
  debug: false
  smtp:
    host: smtp.office365.com
    port: 587
    secure: false
    tls:
      ciphers: "SSLv3"
      rejectUnauthorized: false
    auth:
      user: your-email@outlook.com
      pass: your-app-password
```

### Running FlowFuse Application

We have completed the basic production-level configuration for running the FlowFuse application. Before running it, we need to ensure that we have the `flowfuse/node-red` container downloaded, which will be used as the default Node-RED stack.

1. To download the Node-RED container, run the following command:

```bash
    docker pull flowfuse/node-red
```

2. Now, to run the FlowFuse application, execute the following command:

```bash
    docker compose -p flowforge up -d
```

If you see an output similar to the following image, it indicates that all containers that are required for the flowfuse application to run correctly are running.

!["Screenshot of the terminal showing the all containers are running successfully that are required for the flowfuse to run"](https://flowfuse.com/blog/2024/07/images/flowforge-yml-successfully-running-container.png "Screenshot of the terminal showing the all containers are running successfully that are required for the flowfuse to run")

You can now access your self-hosted FlowFuse platform on the internet using the URL `forge.<yourdomain>.com`, and if your website shows the `https` as following that means the SSL configurations are also correct.

!["Screenshot of the browser window with flowfuse platform opened"](https://flowfuse.com/blog/2024/07/images/deploying-flowfuse-successfull-with-ssl.png "Screenshot of the browser window with flowfuse platform opened")

### Setting up the FlowFuse Platform

When you open the platform in your browser for the first time, you'll need to create an administrator account and perform initial configurations:

1. Open the platform in your browser.
      
2. Click on the "START SETUP" button.
3. Enter the username, full name, email, and password, and confirm the password to the administrator user account. This first user will have full access to the platform, allowing them to configure settings, and manage users and teams.
4. Next, If you intend to use the FlowFuse Enterprise Edition, enter your license details.
5. Alternatively, you can continue with the FlowFuse Community Edition (CE), which is free, by clicking "Continue with FlowFuse CE".

## Additional resources

- [Deploying FlowFuse with Docker Documentation](https://flowfuse.com/docs/install/docker/): This documentation covers everything in detail on how to install FlowFuse using Docker.
- [Deploying FlowFuse with Docker on Ubuntu youtube video](https://www.youtube.com/watch?v=qQwAPuz9bEk){rel="&#x22;nofollow&#x22;"}: This YouTube video demonstrates how to deploy FlowFuse using Docker on an Ubuntu server for your server's local network.
- [Form for requesting Installation Service](https://flowfuse.com/docs/install/introduction/#do-you-need-help-installation-service): Fill this form if you need assistance with the installation process.


# Evolution of Technology: Impact on Job Roles and Companies

Throughout history, technology has continuously transformed industries, job roles, and entire companies. While these changes often evoke fear and resistance, they also create new jobs, opportunities for innovation and growth. This post will explore how historical technological advancements have reshaped both individual job roles and entire companies, examine current trends like AI and low-code tools, and discuss the critical importance of adaptability for both individuals and businesses in navigating technological disruption, Importantly, we will address the pressing question of our time: &#x2A;**"How can AI and low-code tools both enhance and challenge human capabilities, creativity, and the job market, and is this the next frontier in manufacturing or just hype"***

## Historical Examples of Technological Disruption and Business Impact

The Industrial Revolution serves as a powerful example of how technological advancements disrupted entire industries and reshaped business landscapes. In the late 18th and early 19th centuries, mechanized manufacturing replaced traditional artisanal crafts and manual labor. Companies that embraced these new technologies, such as textile mills and steam-powered factories, experienced unprecedented growth and profitability. Conversely, businesses that clung to outdated methods faced decline or closure as they struggled to compete with more efficient and scalable production methods.

The advent of the automobile in the early 20th century brought about another wave of technological disruption. As cars replaced horse-drawn carriages, companies in the transportation and manufacturing sectors had to adapt or risk becoming obsolete. Established businesses that successfully transitioned to automotive manufacturing thrived, while those that resisted change faced significant challenges. For instance, companies that continued to produce horse-drawn carriages struggled to maintain market relevance and profitability.

The digital revolution of the late 20th century further accelerated technological disruption across industries. The introduction of computers, the internet, and digital communication transformed how businesses operated, communicated, and conducted commerce. Companies that embraced digital technologies gained competitive advantages in efficiency, customer engagement, and global market reach. In contrast, businesses that resisted digital transformation struggled to keep pace with rapidly evolving consumer expectations and market dynamics.

## Current Trends: AI, Low-Code Tools, and Strategic Adaptation

Today, we are witnessing a new era of technological disruption driven by artificial intelligence (AI) and low-code/no-code development platforms. AI technologies are revolutionizing business operations by automating routine tasks, analyzing vast amounts of data, and enhancing decision-making processes. Companies that strategically integrate AI into their operations can optimize productivity, personalize customer experiences, and gain valuable insights into market trends and consumer behavior. However, businesses that hesitate to adopt AI risk falling behind competitors who leverage these technologies to innovate and drive business growth.

Low-code and no-code development platforms represent another transformative trend reshaping how companies approach software development and innovation. These platforms empower business users and citizen developers to create applications and automate workflows with minimal coding knowledge. By democratizing software development, low-code tools enable faster application deployment, greater agility in responding to market demands, and enhanced collaboration between IT and business teams. Companies that embrace low-code platforms like Node-RED can accelerate digital transformation initiatives, streamline business processes, and drive innovation across the organization.

Furthermore, AI and low-code tools disrupt traditional job roles and create new opportunities across various fields. Roles such as AI Integration Specialists, Data Scientists, and Machine Learning Engineers, prompt engineers are increasingly in demand as companies seek to enhance efficiency and productivity. Similarly, the adoption of low-code tools like Node-RED is leading to the creation of positions such as Automation Engineers, IoT Developers, and Integration specialists, and Node-RED is becoming a standard requirement in jobs across manufacturing and IoT industries.

## The Importance of Adaptability and Strategic Vision

Historically, individuals and businesses that fail to adapt to technological change or embrace innovation risk becoming obsolete in competitive markets. A notable example is Nokia, once a dominant player in the mobile phone industry. Nokia initially thrived by pioneering mobile technology and establishing a strong market presence. However, the company's reluctance to embrace the shift to smartphones and its adherence to outdated business models ultimately led to its decline. In contrast, competitors like Apple and Samsung seized opportunities in the smartphone market, leveraging innovation and consumer-centric strategies to surpass Nokia in market share and profitability. There are numerous such examples, one being Xerox. Watch this short video where Steve Jobs, founder of Apple, explains [Why Xerox failed](https://www.youtube.com/watch?v=X3NASGb5m8s&t=2s){rel="&#x22;nofollow&#x22;"}.

The strategic adoption of AI and low-code tools is critical for maintaining competitive advantage and driving sustainable growth. While concerns about AI ethics and reliability are valid, businesses that implement AI technologies responsibly can enhance operational efficiency, improve decision-making processes, and deliver superior customer experiences. Similarly, companies that embrace low-code development platforms can accelerate time-to-market for new applications, reduce development costs, and empower business units to innovate and iterate more rapidly. Amazon, for instance, exemplifies this adaptability by evolving from an online bookstore to a global leader in e-commerce and cloud computing through strategic technology integration.

## FlowFuse: The perfect combo of Low-code and AI

FlowFuse is a cloud-based platform for Node-RED, a popular low-code tool. It enhances Node-RED with real-time collaboration, version control, and remote edge device programming.

With the capability to integrate over 5000 applications, protocols, and technologies, FlowFuse empowers businesses to innovate and streamline operations.
Recently, FlowFuse has integrated AI features like the [Function GPT](https://flowfuse.com/blog/2023/05/chatgpt-nodered-fcn-node/) and [Node-RED Builder](https://flowfuse.com/blog/2023/11/chatgpt-gpt/) and the [FlowFuse Expert](https://flowfuse.com/changelog/2024/07/flowfuse-assistant/). These tools allow users to automate flow creation, significantly boosting productivity. This combination of low-code development and AI positions FlowFuse as a transformative tool for modern businesses.

Manufacturing companies are already adopting these advanced features to optimize their operations and stay competitive. Tech professionals should also prepare to leverage these tools to harness the full potential of AI and low-code development.

FlowFuse provides businesses, particularly those in the manufacturing sector, with a revolutionary solution powered by artificial intelligence and effective low-code platforms that make operations more efficient and increase output. This combination promotes quick innovation and flexibility, essential for maintaining a competitive edge in the era of Industry 4.0. FlowFuse's strong integration features guarantee the ability to expand successfully and maintain smooth connections across various applications, enabling manufacturing companies to improve their operations, enhance teamwork, and provide outstanding products and services.

## Conclusion

Technology has always driven change, disrupting traditional models and opening new growth avenues. From the Industrial Revolution to today's AI and low-code tools, adaptability, strategic vision, and innovation remain key to success. By embracing emerging technologies and a forward-thinking mindset, individuals and companies can lead in innovation, customer focus, and sustainable growth in a competitive global economy.


# FlowFuse 2.6: AI Infused Node-RED, Persistent File Storage & Lots More

FlowFuse 2.6 is packed with great new features, and in this release we've had a heavy focus on improving the development experience of Node-RED, lowering the barrier to entry for new users and aligning to our [Simplified Hosting](https://flowfuse.com/handbook/engineering/product/) and [Low-Code](https://flowfuse.com/handbook/engineering/product/) plans from our [Product Strategy](https://flowfuse.com/handbook/engineering/product/).

## Improving the Node-RED Experience

Whilst a big part of FlowFuse is the ability to run Node-RED, we're also focussing on how to improve the experience of *building* with Node-RED on FlowFuse too.

### AI-Infused Node-RED

![Screenshot showing the "FlowFuse Expert" dialog box](https://flowfuse.com/blog/2024/07/images/assistant-dialog-function-node-builder.png){dataZoomable=""}&#x2A;Screenshot of an example instruction sent to FlowFuse Expert.*

One of the joys of Node-RED is how it empowers users not experienced with development to create bespoke applications. A popular and very powerful node in Node-RED is the "function" node. This node allows users to write JavaScript code to manipulate messages. However, this can be daunting for users who are not familiar with JavaScript, it's a steep learning curve. As such, when you run Node-RED in FlowFuse, you'll be able to use the **Node-RED Assistant** in both the Editor toolbar, and the function nodes:

![Screenshot showing the "FlowFuse Expert" button available in the Editor Toolbar](https://flowfuse.com/blog/2024/07/images/assistant-toolbar.png){dataZoomable=""}*Screenshot showing the "FlowFuse Expert" button available in the Editor Toolbar*

![Screenshot showing the "Ask the FlowFuse Expert" button available in the function node](https://flowfuse.com/blog/2024/07/images/assistant-function-node-inline-code-lens.png){dataZoomable=""}*Screenshot showing the "Ask the FlowFuse Expert" button available in the function node*

The Node-RED Assistant is an AI-powered tool that can help you write JavaScript code in the function node. It can suggest code snippets, help you debug your code, and even write code for you. This is a game-changer for users who are inexperienced with JavaScript, as it lowers the barrier to entry and makes it easier to create applications.

### Immersive Editor Experience

During our investigation on how FlowFuse and Node-RED are used together, we found out that many users have to frequently switch between the Node-RED Editor and FlowFuse UI. This back-and-forth movement was often necessary to view logs, save snapshots, restart the Editor after updates, and perform other tasks.

We're always seeking to reduce friction in the FlowFuse user experience, and as such, we've introduced a large overhaul of the developer experience for Node-RED when running in FlowFuse, in what we're calling the "Immersive Editor".

![Screenshot showing the "Immersive Editor" view](https://flowfuse.com/blog/2024/07/images/immersive-editor.png){dataZoomable=""}&#x2A;Screenshot showing the "Immersive Editor" view, where the FlowFuse navigation is available as a floating bar.*

Now, the instances tabs are all available in the *same* view as the Editor.

![Screenshot showing the "Collapsed" FlowFuse bar](https://flowfuse.com/blog/2024/07/images/immersive-editor-collapsed.png){dataZoomable=""}&#x2A;Screenshot showing the "FlowFuse" button at the bottom of the Node-RED Editor.*

Don't worry though, if you want the full editor experience again, you can just collapse the FlowFuse menus down to a little "FlowFuse" button at the bottom.

The new Immersive Editor is available for instances running Node-RED 4.0.2 or later - older versions of Node-RED will still use the separate views.

## Persistent File Storage

Since the early days of FlowFuse, we have provided custom File nodes that can be used to read and write individual files from a flow. This was necessary because the local file system was not considered persistent; restarting an instance would reset the file system back to how it was when the instance first started.

Whilst this solved the immediate problem for the File nodes, we know there were 3rd party nodes that would want to use the file system as well - and we couldn't expect them to update to work with our custom solution.

With the 2.6 release, each instance now gets a piece of persistent file system they can read and write to normally, from any node - with full confidence those files will be persisted between restarts.

This unlocks lots of new capabilities using nodes from the community. For example, the [SQLite](https://flows.nodered.org/node/node-red-node-sqlite){rel="&#x22;nofollow&#x22;"} nodes can be used to quickly add a locally managed database to store your data in.

All newly created instances of FlowFuse Cloud from today will have this storage enabled. If you have an existing instance you'd like to move over, then do get [in touch](https://flowfuse.com/contact-us/) and we can help move you over.

## Other Highlights

### Compact Applications View

This is a great example of collaboration with our customers. Three weeks ago, a customer reached out to us with a design proposal for the main "Applications" view. Within three weeks it's not only been implemented, but is now live, running in FlowFuse Cloud, and available in FlowFuse 2.6.

![Screenshot of new "Applications" view for a given Team in FlowFuse.](https://flowfuse.com/blog/2024/07/images/compact-applications-view.png){dataZoomable=""}&#x2A;Screenshot of new "Applications" view for a given Team in FlowFuse.*

The improvement here is that we've moved instances and devices to be shown as a maximum of three per row (rather than the one perviously) meaning you can see far more content at a glance, and hopefully, get to where you need to go in fewer clicks.

### Import/Export Blueprints

![Screenshot showing the admin page for "Flow Blueprints" with the new "Import"/"Export" buttons](https://flowfuse.com/blog/2024/07/images/blueprint-import-export.png){dataZoomable=""}*Screenshot showing the admin page for "Flow Blueprints" with the new "Import"/"Export" buttons*

Administrators of FlowFuse instances can now import and export Blueprints. This is the first stage of a larger feature set for Blueprints that will make it easier to share common flows and patterns across FlowFuse instances, and see many extensions to our [Blueprint Library](https://flowfuse.com/blueprints/).

### Multi-line Environment Variables

![Screenshot showing the "Environment Variables" table in the Instance's Settings](https://flowfuse.com/blog/2024/07/images/multiline-env-vars.png){dataZoomable=""}*Screenshot showing the "Environment Variables" table in an Instance's Settings*

We now support the use of multi-line environment variables for your Node-RED instances running on FlowFuse. This unlocks the ability to store certs or multi-line values like JSON as environment variables.

We've also improved the `.env` importing to support the use of multi-line values too.

### And Much More...

For a full list of everything that went into our 2.6 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.6.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try it out

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse yourself via a variety of install options. You can find out more details [here](https://flowfuse.com/docs/install/introduction/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.

## Upgrading FlowFuse

If you're using \[FlowFuse Cloud]\({{ site.appURL }}), then there is nothing you need to do - it's already running 2.6, and you may have already been playing with the new features.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go to the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# How to Set Up SSO LDAP for Node-RED

A few days ago, we published a [blog](https://flowfuse.com/blog/2024/07/how-to-setup-sso-saml-for-the-node-red/) explaining SSO and how to set up SAML for your self-hosted FlowFuse. Now, in this guide, we will walk you through the process of setting up SSO with LDAP for your self-hosted FlowFuse. We will use OpenLDAP as the provider and cover everything from introducing LDAP, how it works, installing and configuring OpenLDAP, managing users (create, delete, update), and finally setting up FlowFuse for SSO with LDAP.

## Understanding LDAP SSO?

### What is LDAP

LDAP (Lightweight Directory Access Protocol) is a protocol used to access and manage directory information. In the context of network administration, a directory service acts as a specialized database that stores and organizes information about users, devices, and other resources. Think of it as a digital phonebook for your network, allowing centralized management and efficient access to information.

LDAP enables applications and services to query, add, update, and delete directory entries stored on LDAP servers. It simplifies identity management by enabling easy authentication, authorization, and quick access to information across distributed systems.

### How LDAP SSO works

1. **User Authentication Request:** A user attempts to access a service or application that requires authentication.
2. **SSO Initiation:** The application forwards the authentication request to the Identity Provider (IdP) configured with LDAP, such as OpenLDAP.
3. **LDAP Authentication:** The IdP (LDAP server) verifies the user's credentials against its directory.
4. **Authentication Response:** If the credentials are valid, the LDAP server sends an authentication response (usually a token or assertion) back to the application.
5. **Access Granted:** The application grants access to the user based on the authentication response received from the LDAP server.

## Setting up SSO LDAP for FlowFuse

Before we proceed, ensure that FlowFuse is deployed on your server with an Enterprise license and you have ssh connection with it so that you can run commands on the server. If you haven't installed it yet, please check out our [documentation on installing FlowFuse](https://flowfuse.com/docs/install/introduction/) or our blog on [deploying FlowFuse on Ubuntu with Docker](https://flowfuse.com/blog/2024/07/deploying-flowfuse-with-docker/).

### Installing and Configuring OpenLDAP

Throughout this section, we will install and configure OpenLDAP on your Ubuntu server. Make sure to replace the commands and configs with your details. If you are using a different distribution, you can follow other resources available on the internet for installation and configuration, as well as managing of users.

1. Set the hostname for your LDAP server:
   ```bash
   hostnamectl set-hostname ldap.<your-domain>.com
   ```
2. Add the server IP to `/etc/hosts`:
   ```bash
   echo '<your_server_ip> ldap.<your-domain>.com' >> /etc/hosts
   ```
3. Install OpenLDAP and related utilities:
   ```bash
   apt install slapd ldap-utils
   ```
4. Set an administrator password for LDAP during installation and confirm it in the next prompt.

!["Screenshot of prompt asking to set the administrator password while installation"](https://flowfuse.com/blog/2024/07/images/Ldap-Server-Admin-Password-Ubuntu.png "Screenshot of prompt asking to set the administrator password")

!["Screenshot of prompt asking to conform the administrator password"](https://flowfuse.com/blog/2024/07/images/Confirm-Ldap-Admin-Passsword-Ubuntu.png "Screenshot of prompt asking to conform the administrator password")

5. Reconfigure the slapd package:
   ```bash
   dpkg-reconfigure slapd
   ```
6. When asked to omit server configuration, select ‘NO’

!["Screenshot of prompt asking to omit the server configuration"](https://flowfuse.com/blog/2024/07/images/Cofiguring-slapd-ubuntu.png "Screenshot of prompt asking to omit the server configuration")

7. Configure the base DN (Distinguished Name) for your LDAP directory:
   - Use your domain name to construct the base DN. For example, if your domain is `my-flows.site`, the base DN would be `dc=my-flows,dc=site` and press 'ENTER' to confirm.

![Screenshot of prompt asking to enter your domain to construct the base DN"](https://flowfuse.com/blog/2024/07/images/prompt-for-domain.jpeg "Screenshot of prompt asking to enter your domain to construct the base DN")

- Provide a name for your organization, which will also be part of the base DN and press 'Enter.'

!["Screenshot of prompt asking to enter your org name"](https://flowfuse.com/blog/2024/07/images/prompt-for-org.jpeg "Screenshot of prompt asking to enter your org name")

9. Enter the Administrator password for your LDAP directory.

!["Screenshot of prompt asking to set the administrator password"](https://flowfuse.com/blog/2024/07/images/Ldap-Server-Admin-Password-Ubuntu.png "Screenshot of prompt asking to set the administrator password")

10. Confirm the password.

!["Screenshot of prompt asking to conform the administrator password"](https://flowfuse.com/blog/2024/07/images/Confirm-Ldap-Admin-Passsword-Ubuntu.png "Screenshot of prompt asking to conform the administrator password")

11. When asked to remove the database when slapd is purged, select ‘NO’.

!["Screenshot of the prompt asking to remove the database when slapd is purged"](https://flowfuse.com/blog/2024/07/images/Database-Removal-Slapd-Ubuntu.png "Screenshot of the prompt asking to remove the database when slapd is purged")

12. Select ‘Yes’ to remove the old database to create room for a new database.

!["Screenshot of the prompt asking to remove the old database"](https://flowfuse.com/blog/2024/07/images/Select-Yes-Move-Old-Databases-Slapd-Ubuntu.png "Screenshot of the prompt asking to remove the old database")

13. Edit the main OpenLDAP configuration file:

```bash
sudo nano /etc/ldap/ldap.conf
```

14. Uncomment the lines beginning with “BASE” and “URI”, for example, my domain is `my-flows.site`, we have updated the file as below, but you have to update it according to your domain:

```text
BASE `dc=my-flows,dc=site.`
URI `ldap://ldap.my-flows.site.`
```

### Adding, Updating, and Deleting Groups and Users

#### Adding Groups and Users

1. Create a file for the base groups and open the editor:
   ```bash
   nano groups.ldif
   ```
2. Add the following content to `groups.ldif`, which will create the `users` group, make sure when you create a new group the gidNumber and ou is unique:
   ```text
   dn: ou=users,dc=my-flows,dc=site
   objectClass: organizationalUnit
   ou: users
   gidNumber: 7000
   ```
3. Add the groups to the LDAP directory:
   ```bash
   ldapadd -x -D cn=admin,dc=my-flows,dc=site -W -f groups.ldif
   ```
4. Create a password for the user and store the encrypted password:

```bash
Slappasswd -g
```

4. Create a file for the user:
   ```bash
   nano user.ldif
   ```
5. Add the following content to user.ldif. Replace the placeholders with actual values for `uid`, `sn`, `givenName`,`displayName`,`cn` ,`gecos` , `homeDirectory`, and set userPassword to the password generated earlier. Ensure each user has a unique `uidNumber`, and you can keep the gidNumber the same if users belong to the same primary group
   ```text
   dn: uid=sumit,ou=users,dc=my-flows,dc=site
   objectClass: inetOrgPerson
   objectClass: posixAccount
   objectClass: shadowAccount
   uid: sumit
   sn: shinde
   givenName: sumit
   cn: sumit shinde
   displayName: sumit shinde
   uidNumber: 1000
   gidNumber: 7000
   userPassword: {SSHA}uQVjd8MLaJ7AXEd/grqViuKnk9tNojdy
   gecos: sumit shinde
   loginShell: /bin/bash
   homeDirectory: /home/sumit
   ```
6. Save and exit the configuration file.
7. Add the user to the LDAP directory:
   ```bash
   ldapadd -x -D cn=admin,dc=my-flows,dc=site -W -f user.ldif
   ```

#### Updating Groups and Users

1. Create a file for the user update:
   ```bash
   nano user_update.ldif
   ```
2. Add the following content to `user_update.ldif` to update the user's details (e.g., changing the display name):
   ```text
   dn: uid=sumit,ou=users,dc=my-flows,dc=site
   changetype: modify
   replace: displayName
   displayName: Sumit Rupesh Shinde
   ```
3. Save and exit the configuration file.
4. Apply the update to the LDAP directory:
   ```bash
   ldapmodify -x -D cn=admin,dc=my-flows,dc=site -W -f user_update.ldif
   ```
5. Create a file for the group update:
   ```bash
   nano group_update.ldif
   ```
6. Add the following content to `group_update.ldif` to update the group's details (e.g., changing the organizational unit name):
   ```text
   dn: ou=users,dc=my-flows,dc=site
   changetype: modify
   replace: ou
   ou: staff
   ```
7. Save and exit the configuration file.
8. Apply the update to the LDAP directory:
   ```bash
   ldapmodify -x -D cn=admin,dc=my-flows,dc=site -W -f group_update.ldif
   ```

#### Deleting Groups and Users

1. Delete a user from the LDAP directory:
   ```bash
   ldapdelete -x -D cn=admin,dc=my-flows,dc=site -W "uid=sumit,ou=users,dc=my-flows,dc=site"
   ```
2. Delete a group from the LDAP directory:
   ```bash
   ldapdelete -x -D cn=admin,dc=my-flows,dc=site -W "ou=users,dc=my-flows,dc=site"
   ```

### Configuring and Enabling SSO in FlowFuse

1. To configure FlowFuse with SSO, make sure you are logged in as an administrator.
2. Go to Admin settings by clicking on the profile icon in the top-right corner and then selecting "Admin settings".

!["Screenshot showing the admin settings option in the profile icon"](https://flowfuse.com/blog/2024/07/images/admin-setting-option.png "Screenshot showing the admin settings option in the profile icon")

3. Click on "Settings" from the left sidebar and switch to the SSO section.

!["Screenshot showing the sso section in the admin settings"](https://flowfuse.com/blog/2024/07/images/settings-sso-setting-section.png "Screenshot showing the sso section in the admin settings")

4. Click on the top-right "Create SSO configuration".

!["Screenshot showing the 'create sso configuration' button"](https://flowfuse.com/blog/2024/07/images/create-sso-config-button.png "Screenshot showing the 'create sso configuration' button")

5. Enter the name for your configuration, then enter the domain with `@` prefix and select the "LDAP" option. Click on the "Create configuration" button.

!["Screenshot showing the initial form to create ldap sso configuration"](https://flowfuse.com/blog/2024/07/images/sso-config-ldap.png "Screenshot showing the initial form to create ldap sso configuration")

6. In the next form, in the server field enter `your-server-ip:389`. 389 is the default port for LDAP but make sure to check it. If you are going to enable TLS, replace the port with 636.

!["Screenshot showing the advance form to create ldap sso configuration"](https://flowfuse.com/blog/2024/07/images/ldap-advance-config-tag.png "Screenshot showing the advance form to create ldap sso configuration")

7. Enter the the bind DN into the username field.
8. Enter the password for the LDAP administrator in the password field.
9. Enter the Base DN. For example, if your domain is `my-flows.site`, the Base DN will be `dc=my-flows,dc=site`.
10. Click on the "Update configuration" button.

### Signing in Using SSO

To sign in using SSO, users of your self-hosted FlowFuse must have a FlowFuse account created with an email ID associated with the domain configured with SSO. For more information, refer to [creating users in FlowFuse](https://flowfuse.com/docs/admin/user-management/#creating-new-users).

1. Open your platform in the browser. Enter the username in the username/email field.
2. Click on "Login".
3. Then enter the password set in the LDAP directory for that user.

*Note: Admin users will still be able to log in with their original FlowFuse username/password - this ensures they don't get locked out of the platform if there is a problem with the SSO configuration*

## Conclusion

In this guide, we covered how to set up SSO with LDAP for your self-hosted FlowFuse platform using OpenLDAP. We installed and configured OpenLDAP, learned to managed groups and users, and configured SSO within FlowFuse. This setup enhances security by centralizing user authentication and simplifies access across applications, ensuring efficient user management in your FlowFuse deployment.


# How to Set Up SSO SAML for Node-RED

SSO plays a crucial role in modern enterprise environments by simplifying user authentication across multiple applications. At FlowFuse, we recognize the significance of SSO and offer robust support for integrating it with your self-hosted platform. In this comprehensive guide, we will focus on configuring SSO SAML, specifically using Google as the Identity Provider (IdP). We also support SSO with LDAP. For more information, refer to [Setting up LDAP SSO for your Self-Hosted FlowFuse](https://flowfuse.com/docs/admin/sso/ldap/).

## What is SSO?

Single Sign-On (SSO) is a technology that allows users to access multiple applications or services with one set of login credentials. When a user logs in to one central system, known as the Identity Provider (IdP) such as Google, Microsoft Azure AD, or Okta, it authenticates the user and creates a session token. This token is then used to access other connected applications without requiring the user to log in again. The IdP verifies the token and shares the authentication information with other applications, ensuring secure and seamless access across multiple platforms. This reduces the need to remember multiple passwords and enhances security by centralizing authentication.

## Understanding SAML

SAML (Security Assertion Markup Language) is a protocol used in SSO scenarios to exchange authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). Here’s how it works step-by-step:

!["Image showing the working process of SSO SAML"](https://flowfuse.com/blog/2024/07/images/SAML-SSO.png "Image showing the working process of SSO SAML"){dataZoomable=""}

1. **User Request**: A user attempts to access a service or application that is protected by SAML-based SSO.
2. **Redirect to IdP**: The Service Provider (SP), recognizing that the user needs authentication, redirects them to the Identity Provider (IdP).
3. **User Authentication**: The IdP prompts the user to authenticate themselves. This authentication can involve various methods, such as username/password, multi-factor authentication (MFA), or other authentication mechanisms supported by the IdP.
4. **Generating SAML Assertion**: Upon successful authentication, the IdP generates a SAML assertion. This assertion contains information about the user's identity (like username, email) and any attributes or roles associated with the user.
5. **Sending SAML Assertion**: The IdP sends this SAML assertion back to the Service Provider (SP), typically through the user's browser. The assertion is digitally signed by the IdP to ensure its authenticity and integrity.
6. **Assertion Validation**: The Service Provider (SP) receives the SAML assertion. It validates the assertion to ensure it comes from a trusted IdP and that the assertions' contents are accurate and have not been tampered with.
7. **Granting Access**: If the assertion is valid, the SP grants access to the user based on the information in the SAML assertion. This allows the user to access the protected application or service without needing to provide separate credentials to the SP.

## Benefits of Using SSO in the Workspace

1. **Improved User Experience**: Users only need to remember one set of credentials, making the login process simpler and reducing password fatigue. For instance, In a manufacturing environment, employees often need to access multiple systems, such as Node-RED, ERP systems, and quality control applications. With SSO, they only need to remember one set of credentials, simplifying the login process and reducing password fatigue.
2. **Simplified Management**: Administrators can manage user access and permissions from a single platform, making it easier to onboard new employees and revoke access when someone leaves. This centralized management ensures that only authorized personnel can access the application flows.
3. **Increased Security**: Centralized authentication via SSO reduces the risk of weak or reused passwords, allowing for the implementation of stronger security policies. This is critical in a workspace where sensitive data and operational systems must be protected against unauthorized access.
4. **Enhanced Productivity**: SSO allows employees to log in once and gain access to all necessary applications, saving time and reducing interruptions.

## Setting up SSO For Your Self-Hosted FlowFuse Platform

Before proceeding, ensure you have deployed FlowFuse on your server with an Enterprise license and configured it with email. Without email configuration, the SSO setup option won't appear in your FlowFuse.Furthermore, Make sure you have a [Google Workspace account created](https://www.youtube.com/watch?v=Rc7BT7PDqFs){rel="&#x22;nofollow&#x22;"} and [verified your domain](https://www.youtube.com/watch?v=JIOaLKsz2R0){rel="&#x22;nofollow&#x22;"} within Google Workspace. FlowFuse supports other providers for SAML SSO as well; check our [documentation on supported providers](https://flowfuse.com/docs/admin/sso/saml/#providers) for details.

If you haven't deployed FlowFuse yet, refer to our [documentation on installing FlowFuse](https://flowfuse.com/docs/install/introduction/) or our blog on [deploying FlowFuse on Ubuntu with Docker](https://flowfuse.com/blog/2024/07/deploying-flowfuse-with-docker/).

### Configuring SSO in your Self-Hosted FlowFuse

1. To configure FlowFuse with SSO, make sure you are logged in as an administrator.
2. Go to Admin settings by clicking on the profile icon in the top-right corner and then selecting "Admin settings".

!["Screenshot showing the admin settings option in the profile icon"](https://flowfuse.com/blog/2024/07/images/admin-setting-option.png "Screenshot showing the admin settings option in the profile icon")

3. Click on "Settings" from the left sidebar and switch to the SSO section.

!["Screenshot of platform showing the 'admin settings' 'SSO' tab option"](https://flowfuse.com/blog/2024/07/images/settings-sso-setting-section.png "Screenshot of platform showing the 'admin settings' 'SSO' tab option"){dataZoomable=""}

4. Click on the top-right "Create SSO configuration".

!["Screenshot of platform showing the 'Creating configuration' button"](https://flowfuse.com/blog/2024/07/images/create-sso-config-button.png "Screenshot of platform showing the 'Creating configuration' button"){dataZoomable=""}

5. Enter a name for your configuration, then enter the domain that the platform will use for SSO and select "SAML" option and click on "create configuration" button.

!["Screenshot of platform form for creating sso configuration"](https://flowfuse.com/blog/2024/07/images/sso-config-initial-form.png "Screenshot of platform form for creating sso configuration"){dataZoomable=""}

5. In the next tab, you'll find the ACS URL and Entity ID. Copy and save them somewhere in the notepad.

!["Screenshot of advance sso form showing the ACS URL and Entity ID and other feilds for configuration"](https://flowfuse.com/blog/2024/07/images/sso-config-next-form.png "Screenshot of advance sso form showing the ACS URL and Entity ID and other feilds for configuration"){dataZoomable=""}

6. Tick "Manage roles using group assertions" if needed. If enabled, keep the Group Assertion Name to its default value and select the team scope:
   - "Apply to selected teams" restricts management to the provided list of groups, For adding the list refer to [SAML Groups configuration](https://flowfuse.com/docs/admin/sso/saml/#saml-groups-configuration), suitable for shared-tenancy platforms like FlowFuse Cloud.
   - "Apply to all teams" allows SAML groups to manage all teams, suitable for a self-hosted installation with a single SSO configuration.
7. Click on "Update configuration", we will back to update this configuration with our configuration provided by our Google workpsace later.

### Creating the SAML APP in Google Workspace.

1. Open the main menu from the top-right corner by clicking on menu icon.

!["Screenshot showing the 'web and mobile apps' option in the sidebar in the Google workspace admin console"](https://flowfuse.com/blog/2024/07/images/main-menus-web-and-mobile-apps-option.png "Screenshot showing the 'web and mobile apps' option in the sidebar in the Google workspace admin console"){dataZoomable=""}

2. Click on the "Apps" icon, which expands additional choices. Then click on the "Web and mobile apps."
3. Then the new tab opens, click on to the "Add app" from the top.

!["Screenshot showing the 'Add app' and 'Add custom SAML apps' option in the Google workspace admin console"](https://flowfuse.com/blog/2024/07/images/add-custom-saml-apps-option.png "Screenshot showing the 'Add custom SAML apps' option in the Google workspace admin console"){dataZoomable=""}

4. The options open select the "Add custom SAML apps."
5. Enter the app name description and upload an icon for the app.

!["Screenshot showing the form asking for app information for we are going to create the SAML app configuration in the Google workspace admin console"](https://flowfuse.com/blog/2024/07/images/form-to-add-app-info.png "Screenshot showing the form asking for app information for we are going to create the SAML app configuration in the Google workspace admin console"){dataZoomable=""}

6. Now copy your Copy the SSO URL, entity ID and certificate or you can simply download it in the one file by clicking on the Download metadata button.

!["Screenshot configuration provided the Google workspace admin console for SSO SAML"](https://flowfuse.com/blog/2024/07/images/config-details-for-sso.png "Screenshot configuration provided the Google workspace admin console for SSO SAML"){dataZoomable=""}

7. Click on the continue.
8. In the next tab, enter the ACS URL and entity id provided by your self-hosted flowfuse platform.

!["Screenshot form asking for the configuration detailes provided by your self-hosted FlowFuse"](https://flowfuse.com/blog/2024/07/images/form-to-add-the-config-provided-flowfuse.png "Screenshot form asking for the configuration detailes provided by your self-hosted FlowFuse"){dataZoomable=""}

9. Enter the start URL as `forge.<your-domain>.com`, we are specify that after successfull sign in the user should be redirected to this url.
10. Next, click on "Continue" button and then click on "finish".

### Updating the FlowFuse SSO configuration and enabling it

Now that we have created the SAML app in the workspace, we need to update the FlowFuse configuration and connect it to the app created in the workspace to enable SSO.

1. Go to the SSO section of the admin settings in your self-hosted FlowFuse platform. Click on the three-dot icon located at the right corner of the added configuration and select "Edit."

!["Screenshot showing three dot icons in your self-hosted FlowFuse"](https://flowfuse.com/blog/2024/07/images/edit-sso-config.png "Screenshot showing three dot icons in your self-hosted FlowFuse"){dataZoomable=""}

2. Add the copied values for the fields: Identity Provider Single Sign-On URL, Identity Provider Issuer ID / URL, and X.509 Certificate Public Key provided by the provider. I instructed you in the above section to copy or download them.

!["Screenshot showing the form updated with configuration provided by Google workspace"](https://flowfuse.com/blog/2024/07/images/sso-config-form.png "Screenshot showing the form updated with configuration provided by Google workspace"){dataZoomable=""}

3. Click on the "Active" option to enable the SSO in the same form.
4. Click on "Update configuration".

### Signing in Using SSO

To sign in using SSO, users of your self-hosted FlowFuse must have a FlowFuse account created with an email ID associated with the domain configured with SSO. For more information, refer to [creating users in FlowFuse](https://flowfuse.com/docs/admin/user-management/#creating-new-users). Additionally, the user must already be logged in with that email in the browser.

1. Open your platform in the browser, Enter the email address in the username/email field.
2. Click on "Login".
3. A Google tab will open, displaying the email addresses you are signed in with. Select the email address you entered into the username/email field.

*Note: Admin users will still be able to log in with their original FlowFuse username/password - this ensures they don't get locked out of the platform if there is a problem with the SSO configuration*

## Conclusion

In this guide, we've covered setting up SSO SAML for your self-hosted FlowFuse platform, exploring how SSO and SAML enhance user experience, improve security, and simplify management. You've learned to create an SSO configuration in FlowFuse, set up a SAML app in Google Workspace, and enable seamless authentication.


# FlowFuse Dashboard vs UI-Builder: A Comprehensive Comparison

When choosing a dashboard solution for Node-RED, two popular options are FlowFuse Dashboard (also known as Dashboard 2.0) and UI-Builder. This article compares these tools across several key areas, including installation, ease of use, development activity, and customizability, to help you decide which one best suits your needs.

## How Easy is it to Install?

### FlowFuse Dashboard

When searching for `flowfuse/node-red-dashboard` on Google, the first result we get to the documentation, which is useful. However, in the Node-RED Palette Manager, finding the correct package can be confusing because there are many community third-party nodes and plugins that work with FlowFuse Dashboard. This can make it bit confusing for new users to locate the right package.

### UI-Builder

Finding UI-Builder is straightforward, as its package name `node-red-contrib-uibuilder` is distinct and easily identifiable both on Google and in the Node-RED Palette Manager. This clear naming helps users quickly locate the correct package.

## How Easy is it to Get Started?

### FlowFuse Dashboard

Getting started with FlowFuse Dashboard is relatively easy due to its low-code approach. It features a sidebar for managing UI widgets, themes, configurations, and settings, with intuitive navigation to the dashboard page. This makes it accessible for users with varying levels of technical expertise.

### UI-Builder

UI-Builder can be more challenging to start with, as it does not follow a low-code approach and lacks a separate sidebar for managing UI elements. Navigating dashboards built with UI-Builder can be less straightforward, and it requires users to have a deeper understanding of coding and UI design principles.

## Migrating from Node-RED Dashboard (Dashboard 1.0)

[Node-RED Dashboard](https://flows.nodered.org/node/node-red-dashboard){rel="&#x22;nofollow&#x22;"} is a module that provides a set of nodes in Node-RED to quickly create user interfaces or live data dashboards. It was developed by one of the creators of Node-RED and is the most used and downloaded package in the Node-RED ecosystem. However, it is now deprecated. For more information, refer to [Node-RED Dashboard Formally Deprecated](https://flowfuse.com/blog/2024/06/dashboard-1-deprecated/).

### FlowFuse Dashboard

FlowFuse Dashboard is developed to replace the the deprecated standard Node-RED Dashboard. It retains the core concepts and UI elements but introduces more advanced options and configurations.

To facilitate the transition, FlowFuse, the creator of FlowFuse Dashboard, provides a [migration service](https://flowfuse.com/platform/dashboard/#migration-service) that simplifies migration of flows or projects from the Node-RED Dashboard to FlowFuse Dashboard. This service helps ensure a smoother migration process with minimal disruption.

### UI-Builder

Migrating from Node-RED Dashboard 1 to UI-Builder is significantly more complex. UI-Builder does not follow the same concepts or provide the same UI elements as the Node-RED Dashboard.

Users will need to recreate their dashboards from scratch, as UI-Builder relies on custom coding and frontend frameworks rather than the predefined, low-code widgets of Node-RED Dashboard. This process can be overwhelming and requires a solid understanding of HTML, CSS and the frontend frameworks if you wanted use.

## How Active is the Project's Development?

### FlowFuse Dashboard

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

[FlowFuse Dashboard](https://github.com/FlowFuse/node-red-dashboard/graphs/contributors){rel="&#x22;nofollow&#x22;"}, which replaced Node-RED Dashboard 1.0 in 2023, has shown consistent and high development activity. The project benefits from a dedicated team that regularly updates and improves it, ensuring it remains current with user needs and technological advancements.

![Screenshot of the FlowFuse Dashboard GitHub commit chart](https://flowfuse.com/blog/2024/08/images/dashboard-2-commits.png):br&#x2A;Screenshot of the FlowFuse Dashboard GitHub commit chart.*

### UI-Builder

[UI-Builder](https://github.com/TotallyInformation/node-red-contrib-uibuilder/graphs/contributors){rel="&#x22;nofollow&#x22;"} has been an active project for a long time and remains active. However, there has been a noticeable decline in development activity starting in early 2024. While the project continues to be maintained, it does not have a dedicated, full-time team.

![Screenshot of the UI-Builder GitHub commit chart](https://flowfuse.com/blog/2024/08/images/ui-builder-commits.png):br&#x2A;Screenshot of the UI-Builder GitHub commit chart.*

## Pre-Built UI Elements

### FlowFuse Dashboard

FlowFuse Dashboard offers an extensive set of UI elements, including forms, dropdowns, tables, charts, and gauges that are super easy to use. These widgets are built with complex Vue.js components, but users are completely shielded from this complexity, allowing them to focus on ease of use. Additionally, if you want to create your own custom widget, you can do so with the ui-template node that accepts complete Vue components. By default, FlowFuse Dashboard supports the Vuetify library, which provides an extensive set of UI components.

### UI-Builder

UI-Builder also offers a number of widgets, but these are not as user-friendly as those in FlowFuse Dashboard. Users must send a JSON config object, which can be complex for new users who lack knowledge of HTML/CSS. Additionally, handling widget data requires using UI-Builder's methods, which can further increase complexity. However, UI-Builder's strength lies in its flexibility, allowing any HTML element to be used as a component, and it also supports the W3C standard web components. Despite this, users need to perform a lot of additional tasks to get everything set up and will have the hassle of writing things.

## Changing the UI at Runtime

### FlowFuse Dashboard

FlowFuse Dashboard supports dynamic control of the UI via the msg object. Each UI widget supports the `msg.ui_update` property, which allows you to control and update UI components dynamically. For example, you can update form fields based on user input, dynamically insert or update options in a dropdown, or change the appearance of the UI by sending CSS classes or selecting options in dropdowns or radio buttons through msg.

### UI-Builder

UI-Builder also supports dynamic UI updates and control. Similar to FlowFuse Dashboard, you can use messages to control the state and content of UI elements.

## Data Visualization

### FlowFuse Dashboard

Monitoring devices is one of the core use cases for Node-RED, and FlowFuse Dashboard makes it easy to monitor device metrics with its built-in [chart](https://dashboard.flowfuse.com/nodes/widgets/ui-chart.html){rel="&#x22;nofollow&#x22;"} and [gauge widgets](https://dashboard.flowfuse.com/nodes/widgets/ui-gauge.html){rel="&#x22;nofollow&#x22;"}. The chart widgets support various types, including line, bar, scatter, pie, and donut charts, while the gauge widgets offer options like tile, 3/4 gauge, and half gauge. This range of built-in options simplifies the creation of visualizations for monitoring device metrics. Additionally, you can use Vuetify or other third-party libraries in the ui-template node if you need different types of charts.

### UI-Builder

UI-Builder does not provide built-in charting options. However, you can add charts using third-party JavaScript libraries. This approach requires additional effort to integrate and configure the libraries, as well as writing the relevant JavaScript to render the charts. While this increases the complexity of creating visualizations, it offers more control and customization.

## Building Layout

### FlowFuse Dashboard

FlowFuse Dashboard offers a collection of pre-defined layouts to make it easy for users to get started quickly. These are available as a configuration for each "Page" of your application.

These predefined layouts provide a solid foundation for most applications. If you need a different layout, FlowFuse Dashboard is limited in it's customization in terms of positioning of elements.

### UI-Builder

UI-Builder does not come with predefined layouts, which can make it more complex for users to get started. it does however, provides the flexibility to completely define your own layout using CSS. This approach allows for complete customization, but it requires users to have a good understanding of HTML and CSS. The lack of predefined layouts means users have to create their own from scratch, which can be time-consuming.

## Responsiveness on Mobile

### FlowFuse Dashboard

FlowFuse Dashboard is designed with [responsiveness](https://dashboard.flowfuse.com/layouts/){rel="&#x22;nofollow&#x22;"} in mind. It ensures that dashboards automatically adapt to different screen sizes and devices, providing a consistent user experience across desktops, tablets, and mobile devices. The dashboard elements are automatically adjusted to fit various resolutions, making it user-friendly for a wide audience.

### UI-Builder

UI-Builder's support for different devices depends on the user's implementation. While it offers the potential for responsive designs, achieving this requires a good understanding of responsive design principles and CSS.

## How Much Customization is Available?

### FlowFuse Dashboard

FlowFuse Dashboard, built on Vue.js, offers a range of customization options through its widget configurations and settings.

While it provides predefined UI elements, users can override CSS and theming using the [ui\_template](https://flowfuse.com/blog/2023/12/dashboard-0-10-0/) widget to enhance the dashboard's appearance.

This same widget also provides functionality to develop custom components or widgets for your Dashboard. These must be built with a VueJS core, but do support the integration of third-party JavaScript libraries.

### UI-Builder

UI-Builder provides extensive customization capabilities, enabling users to build and style UI elements from scratch. This flexibility is advantageous for those with a strong background in frontend development, as it supports any frontend framework or custom design approach. However, achieving the desired results requires significant time and expertise, as users need to handle the coding and styling for each UI element they create.

## Can it be Installed on Mobile?

### FlowFuse Dashboard

FlowFuse Dashboard is built and deployed as a Progressive Web App. This means whilst it's built as a web application, it can be [installed on your mobile device](https://dashboard.flowfuse.com/user/pwa.html#installing-dashboards-on-mobile){rel="&#x22;nofollow&#x22;"} and run as a standalone application, behaving as if it was a native app.

### Ui-Builder

Dashboards built with UI-Builder, on the other hand, cannot be installed as an app. It is designed as a web-based tool for building custom UIs and does not support installation as a standalone application.

## How About Performance and Speed?

### FlowFuse Dashboard

FlowFuse Dashboard provides reliable performance with efficient real-time updates. Initial page load times might be slower, particularly on mobile, but the overall performance is consistent and effective for dynamic dashboards.

### UI-Builder

UI-Builder provides faster initial load times and smooth performance across customizations, ensuring high-speed interactions.

## How is the Overall User Experience?

### FlowFuse Dashboard

FlowFuse Dashboard offers a user-friendly experience with its low-code approach, intuitive UI, and extensive documentation. Users can quickly create and customize dashboards without needing advanced coding skills, making it accessible to a wide range of users, from beginners to experienced developers. This allows users to focus on solving business problems and IoT tasks rather than getting bogged down by complex coding requirements.

### UI-Builder

UI-Builder provides a more flexible but complex user experience. While it allows for greater customization and the use of any frontend framework, it requires a solid understanding of coding and design principles. This can be daunting for users without a background in web development, but it offers powerful capabilities for those who are comfortable with custom coding.

## How Active is the User Community?

### FlowFuse Dashboard

FlowFuse Dashboard boasts a large and active user community. Users frequently participate in forums, contribute to discussions, and share custom solutions. The number of weekly downloads is growing rapidly, reflecting its high activity and popularity.

!["Screenshot of the FlowFuse Dashboard package's weekly download chart from npm"](https://flowfuse.com/blog/2024/08/images/dashboard-2-download.png)*Screenshot of the FlowFuse Dashboard package's weekly download chart from npm*

### UI-Builder

UI-Builder has a smaller but still active user community. While not as large as FlowFuse Dashboard's, it includes dedicated users who also engage in forums, contribute to discussions, and share their use cases and solutions.

!["Screenshot of the Ui-Builder package's weekly download chart from npm"](https://flowfuse.com/blog/2024/08/images/ui-builder-downloads.png)*Screenshot of the Ui-Builder package's weekly download chart from npm*

## How Good is the Support and Documentation?

### FlowFuse Dashboard

Support for FlowFuse Dashboard is robust, with assistance from both the FlowFuse team and the active Node-RED community. The documentation is comprehensive, easy to understand, and regularly updated. The team is also working on an interactive dashboard solution for previewing examples.

### UI-Builder

UI-Builder also has good support, with active contributions from the author and the Node-RED community. The documentation is detailed but can be complex due to extensive use of technical language.

## What are the future development plans?

### FlowFuse Dashboard

FlowFuse Dashboard is actively working on enhancing its feature set. With extensive functionality already in place, the project also has ambitious plans to introduce more advanced features to better serve its users. You can track these developments on the [FlowFuse Dashboard GitHub project board](https://github.com/orgs/FlowFuse/projects/15/views/4){rel="&#x22;nofollow&#x22;"}, where ongoing and upcoming features are documented.

!["Screenshot of the FlowFuse Dashboard GitHub project board"](https://flowfuse.com/blog/2024/08/images/dashboard-2-project-plan.png)*Screenshot of the FlowFuse Dashboard GitHub project board*

Additionally, updates about new features and enhancements are also provided through social media, blogs, and the Node-RED forums, ensuring that users stay informed about the latest developments.

### UI-Builder

UI-Builder does not have a publicly accessible project roadmap or a dedicated planning board for future updates. While development continues, details about forthcoming features and enhancements are regularly updated on the Node-RED Discourse forums by its author.

## Summary Table

| Feature                               | FlowFuse Dashboard                                                                                                                       | UI-Builder                                                                                                               |
| ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Ease of Installation**              | **Moderately easy**: Search for `flowfuse/node-red-dashboard` can be confusing due to multiple nodes; useful documentation available     | **Easy**: Clear package name `node-red-ui-builder` makes it straightforward to find                                      |
| **Ease of Getting Started**           | **Easy**: Low-code interface with a sidebar for managing UI elements; intuitive for users of varying technical skills                    | **Challenging**: Requires understanding of coding and UI design; lacks a low-code approach                               |
| **Migration from Node-RED Dashboard** | **Smooth**: Migration service provided to transition from Node-RED Dashboard 1 to FlowFuse Dashboard                                     | **Complex**: Requires rebuilding dashboards from scratch; significant effort needed for migration                        |
| **Development Activity**              | **High**: Regular updates and improvements; actively maintained by a dedicated team                                                      | **Moderate**: Active but shows a decline in updates; less frequent enhancements                                          |
| **UI Elements Collection**            | **Extensive**: Includes a wide range of widgets like forms, charts, and gauges; built on Vue.js with Vuetify support                     | **Flexible but complex**: Allows any HTML element; requires custom coding and handling of UI elements                    |
| **Visualization**                     | **Easy**: Built-in charting options for various types; additional options with third-party libraries                                     | **Complex**: No built-in charts; requires integration of third-party libraries for visualization                         |
| **Dynamic UI Control**                | **Supported**: Can dynamically control and update UI components using `msg.ui_update` property                                           | **Supported**: Dynamic updates possible, but can be more complex to implement                                            |
|                                       |                                                                                                                                          |                                                                                                                          |
| **Web Layout Support**                | **Predefined**: Offers three main layouts with some options for custom styling                                                           | **Customizable**: No predefined layouts; users must create their own using CSS                                           |
| **Device and Screen Size Support**    | **Excellent**: Responsive design adapts well to various devices and screen sizes                                                         | **Variable**: Responsiveness depends on user's implementation and knowledge of CSS                                       |
| **Customization**                     | **Good**: Offers customization through widget settings and custom CSS and ui-template; supports Vue components and third-party libraries | **High**: Full control over UI design and layout with custom coding; requires expertise in frontend development          |
| **App Installation**                  | **Available**: Can be installed as a Progressive Web App (PWA) for use as a standalone application                                       | **Not available**: Designed as a web-based tool; cannot be installed as an app                                           |
| **Performance and Speed**             | **Reliable**: Good performance with consistent updates; may have slower initial load times on mobile                                     | **Good**: Generally good performance on both desktop and mobile                                                          |
| **Support and Documentation**         | **Robust**: Comprehensive, regularly updated documentation and active community support                                                  | **Good**: Detailed but may be complex; documentation includes technical jargon                                           |
| **Overall User Experience**           | **User-friendly**: Accessible and easy to use with low-code approach; suitable for a wide range of users                                 | **Flexible but complex**: Offers greater customization but requires coding expertise; can be daunting for non-developers |
| **User Community Activity**           | **Large and active**: High engagement in forums and discussions; growing number of downloads                                             | **Smaller but dedicated**: Active users, but less engagement compared to FlowFuse Dashboard                              |
| **Future Development Plans**          | **Active**: Continuous enhancements and new features planned; updates tracked on GitHub project board                                    | **Less transparent**: No detailed roadmap; future features are less clearly communicated                                 |

## Conclusion

FlowFuse Dashboard is well-suited for users seeking a user-friendly, low-code solution with a wide range of pre-built elements and strong community support. Its ease of use and active development make it ideal for quick deployment and minimal technical overhead.

UI-Builder, however, offers nice performance and customization, benefiting users with coding expertise who need highly tailored UIs. Despite its flexibility and faster load times, it requires more complex setup and migration.


# Customise theming in your FlowFuse Dashboard (2026)

A recent release of FlowFuse Dashboard (Dashboard 2.0) has taken customization to the next level.

Previously, users enjoyed the flexibility of tweaking navigation sidebars, themes, and group and page padding. With the new update, you can fully personalize the header too, adding unique elements to enhance your dashboard experience and customize your application to your own branding.

In this article, we'll delve into these exciting new features, including theme adjustments, custom styling, and layout modifications, that empower you to tailor your Node-RED Dashboard like never before.

## Adding Elements in the Header

To add elements to the header, we can use [Teleports](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html#teleports){rel="&#x22;nofollow&#x22;"} within the `ui-template` node. This allows elements to be seamlessly rendered in specific areas of the dashboard. This method simplifies the process compared to manually positioning items with CSS, which can be complex, time-consuming, and potentially disruptive to other dashboard elements.

### Left Side of the Header

To render content on the left side of the header, we can teleport content into the `#app-bar-title` element, where our page name is displayed.

!["Screenshot of Dashboard showing the #app-bar-title container"](https://flowfuse.com/blog/2024/08/images/left-side-area.png "Image of Dashboard showing the #app-bar-title container"){dataZoomable=""}*Image of Dashboard showing the #app-bar-title container*

#### Hiding the Page Name in the Header

Before proceeding, you should hide the page name on the left side of the header by default. This will ensure that when you add elements to the header, they do not clash with the page name.

To hide the page name:

1. Go to the FlowFuse Dashboard sidebar
2. Click on to the "Edit settings" option located at the top of the FlowFuse Dashboard sidebar.

!["Screenshot showing the 'edit setting' option in the dashboard sidebar"](https://flowfuse.com/blog/2024/08/images/edit-setting-button.png "Screenshot showing the 'edit setting' option in the dashboard sidebar"){dataZoomable=""}*Screenshot showing the 'edit setting' option in the dashboard sidebar*

3. Untick the option "Show page name in the header bar".
   !["Screenshot showing the 'Show page name in the header bar' option in the dashboard settings"](https://flowfuse.com/blog/2024/08/images/settings.png "Screenshot showing the 'Show page name in the header bar' option in the dashboard settings"){dataZoomable=""}*Screenshot showing the 'Show page name in the header bar' option in the dashboard settings*

#### Example: Adding Buttons

1. Drag a `ui-template` node onto the Node-RED Editor canvas.
2. Double-click on it and select the scope to either `ui-scope` or `page-scope`. Selecting `ui-scope` will render this content on *all* pages. `page-scope` will just render to a specified page.
3. Choose the page on which you want to render the buttons if you selected `page-scope`, or choose correct ui if `ui-scope` is selected.
4. Paste the following Vue snippet into the template widget. In this snippet, note how we specify the "to" attribute targeting the `#app-bar-title` ID in the teleport tag:

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

```html
<template>
    <!-- Teleport the button to the #app-bar-actions area when mounted -->
    <Teleport v-if="mounted" to="#app-bar-title">
        <v-btn>Button 1</v-btn>
        <v-btn>Button 2</v-btn>
        <v-btn>Button 3</v-btn>
    </Teleport>
</template>

<script>
    export default {
        data() {
            return {
                mounted: false
            }
        },
        mounted() {
            // Set mounted to true when the component is mounted
            this.mounted = true
        }
    }
</script>
```

5. Next, you can customize further by adding more buttons or different elements inside the `<Teleport>` element.

!["Screenshot of Dashboard showing the added buttons in the header"](https://flowfuse.com/blog/2024/08/images/button-added-dashboard.png "Screenshot of Dashboard showing the added buttons in the header"){dataZoomable=""}*Screenshot of Dashboard showing the added buttons in the header*

#### Example: Adding Logo

If you want to add your brand's logo, you can replace the element inside `<Teleport>` with an `<img>` tag. You can do this in the same ui-template widget or in a different ui-template widget:

1. Drag the `ui-template` node onto the canvas.
2. Select the correct scope for that widget to render.
3. Select the correct page or UI in which you want to render the element.
4. Paste the same Vue snippet given in the above section into the `ui-template` widget and replace the code inside `<Teleport>` with the following element:

```html
<img height="32px" src="https://app.flowfuse.com/ff-logo--wordmark-caps--dark.png"></img>
```

You can replace the URL with your logo's URL or set it using the `msg.payload` as shown in examples given [documentation](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html#page-name-app-bar-title){rel="&#x22;nofollow&#x22;"}.

!["Screenshot of the Dashboard displaying the added logo in the header"](https://flowfuse.com/blog/2024/08/images/logo-added-dashboard.png "Screenshot of the Dashboard displaying the added logo in the header"){dataZoomable=""}*Screenshot of the Dashboard displaying the added logo in the header*

### Right Side of the Header

To render elements on the right side of the header, you can use the empty div element having the `#app-bar-actions` ID, in which we can add elements.

!["Screenshot of Dashboard showing the #app-bar-actions container"](https://flowfuse.com/blog/2024/08/images/right-side-area.png "Screenshot of Dashboard showing the #app-bar-actions container"){dataZoomable=""}*Screenshot of Dashboard showing the #app-bar-actions container*

#### Example: Adding logged in user profile

!["Screenshot of Dashboard displaying the logged in user profile at the right side of header"](https://flowfuse.com/blog/2024/08/images/user-profile.png "Screenshot of Dashboard displaying the logged in user profile at the right side of header"){dataZoomable=""}*Screenshot of Dashboard displaying the logged in user profile at the right side of header*

In this section, we will add the user profile of the currently logged-in user to the right side of the header. Make sure you have installed "@flowfuse/node-red-dashboard-2-user-addon" via the palette manager and enabled [FlowFuse User Authentication](https://flowfuse.com/docs/user/instance-settings/#flowfuse-user-authentication). Each message emitted by the FlowFuse Dashboard widget will include the logged-in user information under `msg._client.user`. Additionally the [setup object](https://dashboard.flowfuse.com/contributing/guides/state-management.html#setup-store){rel="&#x22;nofollow&#x22;"} will also contain this information under `setup.socketio.auth.user`.

1. Drag the ui-template widget onto the canvas.
2. Select the correct scope for that widget to render.
3. Select the correct page or UI in which you want to render the element.
4. Paste the same Vue snippet given below into the `ui-template` widget:

```html
<template>
    <!-- Teleporting user info to #app-bar-actions, which is the ID of the action bars' right corners area -->
    <Teleport v-if="loaded" to="#app-bar-actions">
        <div class="user-info">
            <!-- Displaying user image -->
            <img :src="setup.socketio.auth.user.image" />
            <!-- Greeting the user -->
            <span>Hi, {{ setup.socketio.auth.user.name }}</span>
        </div>
    </Teleport>
</template>

<script>
export default {
    data() {
        return {
            // Flag to indicate if the component is loaded
            loaded: false
        };
    },
    mounted() {
        // This function is called when the component is inserted into the DOM.
        // Setting loaded to true here ensures the component is ready to access #app-bar-actions,
        // as it's now part of the same DOM structure.
        // Accessing it before mounted() would cause an error because the component wouldn't be initialized in the DOM yet.
        this.loaded = true; // Setting loaded to true to indicate that the component has been mounted successfully
    }
}
</script>

<style>
/* Styling for user info display */
.user-info {
    display: flex;
    align-items: center;
    gap: 8px;
}
/* Styling for user avatar image*/
.user-info img {
    width: 24px;
    height: 24px;
}
</style>
```

For detailed guide on this section, refer to the guide on [Displaying logged in user on FlowFuse Dashboard](https://flowfuse.com/blog/2024/04/displaying-logged-in-users-on-dashboard/). Furthermore, if you want to add logos or buttons on the right side similar to the left side of the header, you just need to replace the to attribute with the `#app-bar-actions`.

### Centering Header Items

Sometimes you may want to center or position items added to either the `#app-bar-title` or the `#app-bar-actions`. By default, these elements do not have a specified width, and when you add items into them, they grow to fit their content. To center the elements, you first need to ensure that they are sized appropriately.

#### Centering Items in the Left Side of the Header

To center items added to the `#app-bar-title`, apply the following CSS in the `<style>` tag of the `ui-template` widget:

```css
#app-bar-title {
    flex-grow: 1;
    justify-content: center;
}
```

#### Centering Items in the Right Side of the Header

To center items in the `#app-bar-actions` area, add the following CSS to the `<style>` tag of the `ui-template` widget:

```css
#v-toolbar__append {
    flex-grow: 1;
}
```

## Styling Header

One of the significant customization features we've added recently is the ability to style the header in different ways.

To style the header:

1. Go to the FlowFuse Dashboard sidebar
2. Click on to the "Edit settings" option located at the top of the FlowFuse Dashboard sidebar.

!["Screenshot showing the 'edit setting' option in the dashboard sidebar"](https://flowfuse.com/blog/2024/08/images/edit-setting-button.png "Screenshot showing the 'edit setting' option in the dashboard sidebar"){dataZoomable=""}*Screenshot showing the 'edit setting' option in the dashboard sidebar*

3. Select the desired option from the "Header Options" dropdown.

!["Screenshot showing the header style options in the dashboard settings"](https://flowfuse.com/blog/2024/08/images/header-style-options.png "Screenshot showing the header style options in the dashboard settings"){dataZoomable=""}*Screenshot showing the header style options in the dashboard settings*

The following options are available for header styling:

### Default

This option as it name suggest it is the default option set for header. In which the header will get hidden if we scrolled down.

:video{ariaLabel="Video showing the dashboard with default header" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}*Video showing the dashboard with default header*

### Hidden

Selecting this option completely hides the header, allowing you to use that space for other purposes.

!["Image showing the dashboard with hidden header"](https://flowfuse.com/blog/2024/08/images/hidden-header.png "Image showing the dashboard with hidden header"){dataZoomable=""}*Image showing the dashboard with hidden header*

### Fixed

Selecting this option keeps the header fixed at the top. This means that when you scroll the page down, the header will remain visible.

:video{ariaLabel="Video showing the dashboard with fixed header" autoPlay="true" height="450" loop="true" muted="true" playsInline="true" preload="none" width="800"}*Video showing the dashboard with fixed header*

## Changing Dashboard Theme

In this section of the guide, you will learn how to change the Dashboard theme, where you can adjust the colors of the header, navigation sidebar, group and page backgrounds, the border color of groups, and the padding, sizing, and gaps between pages, groups, and widgets.

To edit the existing theme:

1. Go to the FlowFuse Dashboard sidebar.
2. Switch to the "Theme" tab.

!["Screenshot showing the dashboard theme tab in the sidebar"](https://flowfuse.com/blog/2024/08/images/dashboard-theme-tab.png "Screenshot showing the dashboard theme tab in the sidebar"){dataZoomable=""}*Screenshot showing the dashboard theme tab in the sidebar*

3. Click on the edit button next to the theme.
4. You can adjust the header color and the primary color (which applies to the navigation sidebar and elements like buttons and dropdowns) under the "Primary" section. In the "Pages" section, set the background color for pages, and in the "Groups" section, adjust the background color and border color of groups.

!["Screenshot showing the theme properties dialog"](https://flowfuse.com/blog/2024/08/images/dashboard-theme-settings.png "Screenshot showing the theme properties dialog"){dataZoomable=""}*Screenshot showing the theme properties dialog*

5. Under "Sizing," adjust the page padding (the space between dashboard groups), the page border, group gap, group border radius (the thickness of the group border), and widget gap.

For more information on theme, how to add new themes, and set themes for pages, refer to the [Comprehensive guide: FlowFuse Dashboard layout, sidebar, and styling](https://flowfuse.com/blog/2024/05/node-red-dashboard-2-layout-navigation-styling/#understanding-dashboard-20-theme). Additionally, this guide covers FlowFuse Dashboard layouts, themes, and custom styling in detail.

## Conclusion

In this article, we explored FlowFuse Dashboard's new customization features. We focused on adding elements like buttons and logos to the header, and discussed styling options such as default, hidden, and fixed for headers. We also covered how to adjust dashboard themes to personalize colors and layout. These insights empower users to create more personalized and functional Node-RED dashboards.


# New Layout, Widget and Gauges Now Available in FlowFuse Dashboard

At FlowFuse, we're constantly evolving to make sure your dashboard experience is seamless and efficient. This month, we're excited to introduce several new features that enhance your interaction with the platform. From organizing your data with Tabs to visualizing critical information with new Gauges, we've got you covered.

## New Layout: Tabs

We know that managing multiple data sources and visualizations can get overwhelming. To streamline your workflow, we've introduced a new layout: Tabs.

Tabs allow you to organize your widgets into separate, easily navigable sections, reducing clutter and making it easier to focus on specific datasets. Whether you're monitoring system performance, tracking KPIs, or managing IoT devices, Tabs will help you stay organized and efficient.

![Screenshot showing a tab layout in Dashboard](https://flowfuse.com/blog/2024/08/images/layout-tab-dashboard.png){dataZoomable=""}*Screenshot showing a tab layout in Dashboard*

## New Widget: Number Input

Introducing the Number Input widget, a versatile addition that allows users to input numerical values directly into the dashboard. Whether you're setting thresholds, configuring parameters, or simply inputting data, this widget makes it easy to adjust values with precision. It’s ideal for use cases where user interaction with numerical data is required, such as controlling devices or updating settings in real time.

![Screenshot showing a number input widget with Dashboard](https://flowfuse.com/blog/2024/08/images/ui-number-input-widget.png){dataZoomable=""}*Screenshot showing a number input widget with Dashboard*

You can try the Number Input now in our [live Dashboard running on FlowFuse](https://dashboard-demos.flowfuse.cloud/dashboard/number-input){rel="&#x22;nofollow&#x22;"}

## New Gauges

Data visualization is a cornerstone of any effective dashboard. We’re excited to introduce two new gauges designed to provide at-a-glance insights into your key metrics.

### Battery Charge

Monitoring battery levels is crucial for applications that rely on mobile or remote devices. Our new Battery Gauge provides a clear visual representation of battery status, allowing you to quickly assess power levels and take action if necessary. It’s perfect for IoT deployments, mobile sensors, or any system where battery life is a key consideration.

![Screenshot showing a battery gauge with Dashboard](https://flowfuse.com/blog/2024/08/images/ui-gauge-battery.png){dataZoomable=""}*Screenshot showing a battery gauge with Dashboard*

You can try the Tank Level now in our [live Dashboard running on FlowFuse](https://dashboard-demos.flowfuse.cloud/dashboard/gauge#battery-charge){rel="&#x22;nofollow&#x22;"}

### Tank Level

Managing fluid levels in tanks is a common requirement across industries. The new Tank Level Gauge gives you a straightforward way to monitor liquid or gas levels in real time. Whether you're tracking water in a reservoir, fuel in a tank or any other fluid. this gauge provides the precision and clarity you need to maintain operational efficiency.

![Screenshot showing a partially filled tank level gauge with Dashboard](https://flowfuse.com/blog/2024/08/images/ui-gauge-tank-filled.png){dataZoomable=""}*Screenshot showing a partially filled tank level gauge with Dashboard*

You can try the Tank Level now in our [live Dashboard running on FlowFuse](https://dashboard-demos.flowfuse.cloud/dashboard/gauge#tank-level){rel="&#x22;nofollow&#x22;"}

## What else is new?

You can find the full 1.15.0 Release Notes [here](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v1.15.0){rel="&#x22;nofollow&#x22;"}.

Just to highlight a few, particularly valuable, updates and fixes:

- UI Switch - Introduced an "Indicator" mode and enhanced memory handling for better performance.
- UI Table - Added a "Button" column type for improved interactivity.
- UI Button - Color customisation now available, without needing to write overriding CSS.
- Dynamic Properties - Added dynamic property support for `UI-Text-Input` widget.

## What's Next?

Work has already begun on the next release, `1.16.0`, you can see what items we have queued up [here](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}, if you've got any feedback or suggestions, please do let us know, and feel free to open new issues on our [GitHub](https://github.com/FlowFuse/node-red-dashboard/issues){rel="&#x22;nofollow&#x22;"}


# FlowFuse 2.7: Improved management at scale & AI JSON Editor

FlowFuse 2.7 has had a big focus on user experience improvements, particularly centered around teams running at large scales, with over a thousand devices and instances. With this in mind, we've introduced a new search feature that allows you to search across all of your FlowFuse instances, devices and applications from a single place, made it easier to manage your devices with bulk actions, introduced a new notifications inbox to give you a clearer picture on activity across your team, and just for good measure, we've also extended the AI-infused Node-RED experience to the JSON Editor.

## FlowFuse Expert in the JSON Editor

Last release we saw the introduction of the FlowFuse Expert, and in this release we're rolling this out further to include Node-RED's JSON Editor.

![(Left) Screenshot of the AI prompt for a list of 4-legged creatures and (Right) the resulting JSON generated by the FlowFuse Expert](https://flowfuse.com/blog/2024/08/images/ask-assistant-json.jpg){dataZoomable=""}*(Left) Screenshot of the AI prompt for a list of 4-legged creatures and (Right) the resulting JSON generated by the FlowFuse Expert*

![(Left) Screenshot of the AI prompt input for a list of simulated devices and (Right) the resulting JSON generated by the FlowFuse Expert](https://flowfuse.com/blog/2024/08/images/ask-assistant-json-2.png){dataZoomable=""}*(Left) Screenshot of the AI prompt input for a list of simulated devices and (Right) the resulting JSON generated by the FlowFuse Expert*

This new feature empowers you to create custom data sets within seconds, meaning you can sketch out Dashboards or test Node-RED flows before connecting to real, production environments.

## Managing Resources at Scale

As mentioned in the introduction, a big focus on this release, and moving forward into the next couple too, is around improving the user experience when managing large numbers of devices and instances.

### Centralized Search

We have customers with over a thousand devices and instances running in FlowFuse. It can be very difficult to find the resource you're looking for. That's why we've introduced a new search feature that allows you to search across all of your FlowFuse instances, devices and applications from a single place.

![Screenshot showing the new Application Search feature in FlowFuse](https://flowfuse.com/changelog/2024/07/images/applications-search.png){dataZoomable=""}*Screenshot showing the new Application Search feature in FlowFuse*

The search filters as you type, making it easy to find the resource you're looking for. It will keep reference to any applications and or child instances/devices where appropriate too.

### Notifications Inbox

![Screenshot showing the new Notifications Inbox in FlowFuse](https://flowfuse.com/changelog/2024/07/images/notifications-inbox.png){dataZoomable=""}*Screenshot showing the new Notifications Inbox in FlowFuse*

This is a first step in introducing richer notifications across FlowFuse. We've introduced a new notifications inbox that will show you all the activity across your team. Currently, this just shows new team invites, but will soon show instance/device activity that needs your attention and more.

### Bulk Device Actions

We've now enabled the ability to perform bulk actions on devices in FlowFuse. This is particularly useful for managing large numbers of devices, where you might want to update the settings, or delete multiple devices at once.

![Screenshot showing the new Bulk Device Actions feature in FlowFuse](https://flowfuse.com/changelog/2024/07/images/bulk-delete-1.png){dataZoomable=""}*Screenshot showing the new Bulk Device Actions feature in FlowFuse*

For now, we just support bulk delete, but we're planning to add [more bulk actions](https://github.com/FlowFuse/flowfuse/issues/2381){rel="&#x22;nofollow&#x22;"} in the very near future.

### And Much More...

For a full list of everything that went into our 2.7 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.7.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try it out

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.

## Upgrading FlowFuse

If you're using \[FlowFuse Cloud]\({{ site.appURL }}), then there is nothing you need to do - it's already running 2.7, and you may have already been playing with the new features.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a
guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go to the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# FlowFuse 2.8: Static File Service, LDAP Updates & More

FlowFuse 2.8 sees a new major feature introduced to the platform. The first iteration of the "Static Assets Service" is now available, allowing you to host and serve static files from your FlowFuse instance, giving you easy access to file storage for your applications, and seamless integration of those assets and files within Node-RED.

## Static Assets Service

The Static Assets Service allows you to host and serve static files from your FlowFuse instance. This feature is particularly useful for applications that require file storage, such as images, videos, or static data sets.

With the Static Assets Service, you can upload files directly to your FlowFuse instance and access them from your Node-RED flows, like so:

:video[
Your browser does not support the video tag.
]{controls="true"}

This is the first step in this new feature set, with more enhancements planned for future releases, whereby you'll also be able to configure access control to public HTTP endpoints for easy access in your Dashboards.

## LDAP Service Improvements

Team Membership in FlowFuse can now be automatically managed using LDAP groups. This means that you can now assign roles to LDAP groups, and when a user is added to that group in your LDAP server, they will automatically be assigned the respective role in FlowFuse.

This also extends to the management of FlowFuse Admin users, which was previously only supported for SAML SSO.

The Admin management feature is available for those running self-hosted FlowFuse.

## Notifications Improvements

Last release we introduced the [Notifications Inbox](https://flowfuse.com/blog/2024/08/flowfuse-2-7-release#notifications-inbox), and in this release we're starting to expand on the notifications that you wil receive in FlowFuse, starting with alerts when your Node-RED instances and devices crash unexpectedly, and when instances start in "Safe Mode".

![Screenshot showing some example notifications to inform users of unexpected crashes](https://flowfuse.com/blog/2024/08/images/2-8-release-notifications.png){dataZoomable=""}*Screenshot showing some example notifications to inform users of unexpected crashes*

We're also added filters to show "Read" notifications, and grouping together similar notifications so that it's easy to parse if you have many notifications of the same type.

## Managing Devices at Scale

As promised in the [FlowFuse 2.7 Release](https://flowfuse.com/blog/2024/08/flowfuse-2-7-release#bulk-device-actions), we've expanded the actions you can take when working with many Devices at once, which now includes the ability to move Devices between Applications and Instances.

![Screenshot to show the new "Move to Instance" and "Move to Application" bulk actions](https://flowfuse.com/blog/2024/08/images/2-8-release-bulk-move.png){dataZoomable=""}*Screenshot to show the new "Move to Instance" and "Move to Application" bulk actions*

## Stricter Approach to Expired Licenses

We've made some changes to how FlowFuse handles expired licenses for self-hosted users.

If your license has expired, you will now be unable to access your FlowFuse instance until you renew your license. This is to ensure that you are always using the latest version of FlowFuse and have access to the latest features and security updates.

If you are currently running an older version of FlowFuse with an expired license please [contact the Sales team](https://flowfuse.com/contact-us/) to discuss renewing your license before upgrading to FlowFuse 2.8. You can check your current license on the "Admin Settings" > "Overview" page.

## And Much More...

For a full list of everything that went into our 2.8 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.8.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try it out

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud: [Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.

## Upgrading FlowFuse

If you're using \[FlowFuse Cloud]\({{ site.appURL }}), then there is nothing you need to do - it's already running 2.8, and you may have already been playing with the new features.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

If you have an Enterprise license please make sure to review this [changelog entry](https://flowfuse.com/changelog/2024/08/enterprise-license-update)

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go to the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# Bridging OPC UA Data to MQTT with Node-RED (2026)

Have you ever found yourself trying to connect old industrial systems with new IoT tools? This is a common scenario when trying to digitally transform while setting up your Unified Name Space. Maybe you have machinery that uses OPC UA, but your data is sent through MQTT. How do you make these systems work together smoothly?

In this guide, we'll demonstrate how to use Node-RED to bridge OPC UA data to MQTT. This integration will streamline your data flow and enhance real-time monitoring, helping you modernize your setup and improve communication between systems.

### Why Bridge OPC UA to MQTT

![Diagram showing the data flow when bridging OPC UA to MQTT to enable communication between non-OPC UA compatible systems and devices](https://flowfuse.com/blog/2024/08/images/opc-ua-to-mqtt.png){dataZoomable=""}&#x2A;Diagram showing the data flow when bridging OPC UA to MQTT to enable communication between non-OPC UA compatible systems and devices.*

In modern industrial environments, integrating systems with different communication protocols can be a significant challenge. For example, a CNC machine on the factory floor might use OPC UA, while some cloud solutions, edge devices, and other systems, such as custom ERP solutions and IoT applications, might rely on MQTT protocol. This is where bridging OPC UA to MQTT becomes highly beneficial.

By converting OPC UA data into MQTT messages, you make the data from the CNC machine accessible to a broader range of systems that use MQTT, which is a more universally supported messaging protocol. This bridging solution simplifies the integration process, allowing diverse systems to communicate effectively without needing direct OPC UA support.

**Node-RED** is perfect for this job. It can connect both OPC UA and MQTT, making it easy to transform and route data between different systems. Its flexibility and support for many protocols make it great for integrating various industrial hardware and software. For more on how Node-RED can improve industrial operations, check out [Building on FlowFuse: Remote Device Monitoring](https://flowfuse.com/blog/2024/07/building-on-flowfuse-devices/).

[STFI's Model Factory uses this same bridging pattern in its textile manufacturing operations](https://flowfuse.com/customer-stories/stfi-future-of-textile-powered-by-node-red/), connecting proprietary equipment protocols to OPC-UA with Node-RED.

## Bridging OPC UA Data to MQTT with Node-RED

In this section, I'll demonstrate how to bridge OPC UA data to MQTT using Node-RED. We will use simulated OPC UA server data from a CNC machine as an example. The goal is to show how you can efficiently transfer this data to an MQTT broker, making it accessible to various applications and systems.

### Prerequisite

- OPC UA Server: Make sure you have an OPC UA server configured and running with the necessary data. For this blog, we'll use the Prosys OPC UA Simulation Server, which simulates data from CNC machines designed for testing OPC UA client applications and learning the technology. You can download it from [here](https://prosysopc.com/products/opc-ua-simulation-server/){rel="&#x22;nofollow&#x22;"}.
- FlowFuse Account: A FlowFuse account lets you quickly create, deploy, and manage Node-RED instances in the cloud. [sign up now](https://app.flowfuse.com/account/create?utm_campaign=60718323-BCTA&utm_source=blog&utm_medium=cta&utm_term=high_intent&utm_content=Bridging%20OPC%20UA%20Data%20to%20MQTT%20with%20Node-RED){rel="&#x22;nofollow&#x22;"}.
- [node-red-contrib-opcua](https://flows.nodered.org/node/node-red-contrib-opcua){rel="&#x22;nofollow&#x22;"}: install the node-red contrib package that will enable integration of opcua in Node-RED.
- MQTT Broker: We’ll need an MQTT broker for data communication. FlowFuse offers an integrated MQTT Broker Service within Platform for easy setup. For more details, check out [FlowFuse's MQTT Broker Announcement](https://flowfuse.com/blog/2024/10/announcement-mqtt-broker/).

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

### Retrieving Data from the OPC UA Server

To begin retrieving data from your OPC UA server using Node-RED, follow these steps:

1. Drag the **inject** node onto the canvas.
2. Drag the **change** node onto the canvas and double-click on the node to open its configuration settings. Set the `msg.topic` to the node ID and datatype of the property you wish to read.

![(Left) Image of the Change node setting the 'msg.topic' to retrieve the cycle time data and (Right) the OPC UA Prosys interface.](https://flowfuse.com/blog/2024/08/images/change-node-setting-nodeid-datatype.png){dataZoomable=""}&#x2A;(Left) Image of the Change node setting the 'msg.topic' to retrieve the cycle time data and (Right) the OPC UA Prosys interface.*

2. Drag the **OpcUa-Client** node onto the canvas. Double-click on it to open its configuration settings. Click the "+" icon next to the Endpoint field and enter the URL of your running OPC UA server. Configure the security policy and mode according to your server setup. If you use the Prosys OPC UA Simulation Server and have not enabled any security features, you can leave the security policy and mode as "None."

![Configuring opc-ua client node with the opc ua server endpoint](https://flowfuse.com/blog/2024/08/images/opc-ua-config.png){dataZoomable=""}*Configuring opc-ua node with the opc ua server endpoint*

3. In the **OpcUa-Client** node settings, select the action type as "READ." This instructs Node-RED to read data from the OPC UA server.

![Configuring OpcUa-Client node to select the read operation](https://flowfuse.com/blog/2024/08/images/opc-ua-config2.png){dataZoomable=""}*Configuring OpcUa-Client node to select the read operation*

4. If your OPC UA server uses security features, specify the path to your certificate files in the relevant fields. If no security is configured, this step can be skipped.
5. Drag the **debug** node onto the canvas. The output will help you verify the data retrieved from the OPC UA server.
6. Connect the output of the **inject** node to the input of the **change** node and the output of the **change** node to the input of the **OpcUa-Client** node. Then, connect the output of the **OpcUa-Client** node to the input of the **debug** node. This setup ensures that when the **inject** node triggers, it sends data to the **OpcUa-Client** node, and the results are displayed in the Debug node.
7. Deploy the flow by clicking the "Deploy" button in the top right corner. To test the setup, press the Inject button.

You can follow the same steps to retrieve other property values from the OPC UA server. In this example, we are retrieving four simulated data properties: the cycle time, temperature, and spindle speed of the simulated CNC machine. Your setup might differ depending on the properties and data available on your OPC UA server.

### Transforming and Aggregating Data

Once you have successfully retrieved data from your OPC UA server, the next step is to transform and aggregate this data to make it suitable for publishing to an MQTT broker. This demonstration, we will aggregate the retrieved individual property values into a single object. Depending on your specific needs, you might choose to split the object properties and send them separately or perform various calculations and transformations on the data.

1. Drag the **change** node onto the canvas.
2. Double-click on the node and set `msg.topic` to the name of the property you want to set for the retrieved data. In this context, set `msg.topic` to `'cycle-time'`, which will be the key in the object that we will create.

![Setting the msg.topic with the Change node to retrieve data from the OPC UA server.](https://flowfuse.com/blog/2024/08/images/change-node-setting-nodeid-datatype.png){dataZoomable=""}&#x2A;Setting the msg.topic with the change node to retrieve data from the OPC UA server.*

3. Drag the **join** node onto the canvas. Set the mode to manual, with the option to create `msg.payload` using the values of `msg.topic` as keys. Set the count to 3 and ensure that the interval for all of the **inject** nodes triggering data retrieval is the same. This ensures that the data is collected and aggregated correctly at the same time.
4. Connect the output of the **OpcUa-Client** node (which retrieves the data) to the input of the **change** node. For example, if I have set the **change** node for the 'cycle-time' data property, connect it to the **OpcUa-Client** node that retrieves this data.
5. Connect the output of the **change** node to the input of the **join** node.
6. Repeat this process for all of your data properties.

### Sending Data to the MQTT Broker

Now, in this section, we will show you how to send the collected data to an MQTT broker:

1. Drag the **mqtt out** node onto the canvas.
2. Double-click on it and configure it with your MQTT broker details.

![Configuring the mqtt out node with broker information](https://flowfuse.com/blog/2024/08/images/mqtt-out-node-config.png){dataZoomable=""}*Configuring the mqtt out node with broker information*

3. Set the topic for your data in the **mqtt out** node.
4. Connect the output of the **join** node to the input of the **mqtt out** node.
5. Deploy the flow. After deploying, you will see the status "connected" with a green dot at the bottom of each node, indicating that you have successfully connected to your MQTT broker.

:video{ariaLabel="Video showing the successful bridging of OPC UA data to MQTT" autoPlay="true" height="956" loop="true" muted="true" playsInline="true" preload="none" width="1904"}*Video showing the successful bridging of OPC UA data to MQTT*

::render-flow
```json
[{"id":"a099aefb08837e70","type":"OpcUa-Client","z":"807758ec576fbfd8","endpoint":"9dd56eda04f5c5b5","action":"read","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"name":"","x":480,"y":320,"wires":[["f5fd1ffafdfe790f"],[]]},{"id":"1aa02b27b99dfe9d","type":"mqtt out","z":"807758ec576fbfd8","name":"","topic":"/manufacturing/cnc","qos":"2","retain":"true","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"abd4e6202945fee3","x":1390,"y":380,"wires":[]},{"id":"d565ae620d90498a","type":"OpcUa-Client","z":"807758ec576fbfd8","endpoint":"9dd56eda04f5c5b5","action":"read","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"name":"","x":480,"y":400,"wires":[["fc4b83a8a0be3a35"],[]]},{"id":"0e0614ada3269627","type":"OpcUa-Client","z":"807758ec576fbfd8","endpoint":"9dd56eda04f5c5b5","action":"read","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"name":"","x":480,"y":480,"wires":[["e1c4fe72e4f37b6a"],[]]},{"id":"f5fd1ffafdfe790f","type":"change","z":"807758ec576fbfd8","name":"Set the topic for the data","rules":[{"t":"set","p":"topic","pt":"msg","to":"cycle-time","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":730,"y":300,"wires":[["913e9de1324a6f21"]]},{"id":"fc4b83a8a0be3a35","type":"change","z":"807758ec576fbfd8","name":"Set the topic for the data","rules":[{"t":"set","p":"topic","pt":"msg","to":"spindle-speed","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":730,"y":380,"wires":[["913e9de1324a6f21"]]},{"id":"e1c4fe72e4f37b6a","type":"change","z":"807758ec576fbfd8","name":"Set the topic for the data","rules":[{"t":"set","p":"topic","pt":"msg","to":"temperature","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":730,"y":460,"wires":[["913e9de1324a6f21"]]},{"id":"913e9de1324a6f21","type":"join","z":"807758ec576fbfd8","name":"Create object from those three data property ","mode":"custom","build":"object","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","useparts":false,"accumulate":false,"timeout":"","count":"3","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":1080,"y":380,"wires":[["1aa02b27b99dfe9d"]]},{"id":"3339483f64116fce","type":"mqtt in","z":"807758ec576fbfd8","name":"","topic":"/manufacturing/cnc","qos":"2","datatype":"auto-detect","broker":"abd4e6202945fee3","nl":false,"rap":true,"rh":0,"inputs":0,"x":170,"y":660,"wires":[["d881d251071bd317"]]},{"id":"d881d251071bd317","type":"debug","z":"807758ec576fbfd8","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":460,"y":660,"wires":[]},{"id":"55f43460af9601ec","type":"comment","z":"807758ec576fbfd8","name":"Retrieving the data from mqtt","info":"","x":320,"y":600,"wires":[]},{"id":"628ab54495901021","type":"comment","z":"807758ec576fbfd8","name":"Bridging OPC UA data to MQTT","info":"","x":350,"y":240,"wires":[]},{"id":"ce6b8a0e2c8a895d","type":"change","z":"807758ec576fbfd8","name":"","rules":[{"t":"set","p":"topic","pt":"msg","to":"ns=3;i=1010,datatype=float","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":290,"y":320,"wires":[["a099aefb08837e70"]]},{"id":"50fe2b9310d3bb3f","type":"change","z":"807758ec576fbfd8","name":"","rules":[{"t":"set","p":"topic","pt":"msg","to":"ns=3;i=1011,datatype=basedatatype","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":290,"y":400,"wires":[["d565ae620d90498a"]]},{"id":"9cf691f55748d013","type":"change","z":"807758ec576fbfd8","name":"","rules":[{"t":"set","p":"topic","pt":"msg","to":"ns=3;i=1012,datatype=float","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":290,"y":480,"wires":[["0e0614ada3269627"]]},{"id":"de74dabc616c3094","type":"inject","z":"807758ec576fbfd8","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":120,"y":400,"wires":[["ce6b8a0e2c8a895d","50fe2b9310d3bb3f","9cf691f55748d013"]]},{"id":"9dd56eda04f5c5b5","type":"OpcUa-Endpoint","endpoint":"opc.tcp://Roni:53530/OPCUA/SimulationServer","secpol":"None","secmode":"None","none":true,"login":false,"usercert":false,"usercertificate":"","userprivatekey":""},{"id":"abd4e6202945fee3","type":"mqtt-broker","name":"","broker":"http://broker.hivemq.com","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closeRetain":"false","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willRetain":"false","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":""}]
```
::

## Bridging MQTT Data to OPC UA

In addition to bridging data from OPC UA to MQTT, you might also need to send data from MQTT back to an OPC UA server. This is often required in scenarios where external systems, such as Manufacturing Execution Systems (MES), need to update or control machinery settings.

For example, an MES can send commands or configuration changes via MQTT, which then need to be applied to an OPC UA-controlled machine.

1. Drag an **mqtt in** node onto the Node-RED canvas and configure it with your MQTT broker details and the appropriate topic where the MES publishes commands.
2. Drag the **change** node onto the canvas, Set the `msg.topic` to the node ID and datatype of the property you wish to update.
3. Add an **OpcUa-Client** node to the canvas and configure it with your OPC UA server. Set the action type to "WRITE" to send the received data.
4. Connect the output of the **mqtt in** node to the input of the **change** node, and the output of the **change** node to the input of the **OpcUa-Client** node.

:video{ariaLabel="Video showing the successful bridging of MQTT data to OPC UA" autoPlay="true" height="820" loop="true" muted="true" playsInline="true" preload="none" width="1910"}*Video showing the successful bridging of OPC UA data to MQTT*

::render-flow
```json
[{"id":"a099aefb08837e70","type":"OpcUa-Client","z":"FFF0000000000001","endpoint":"9dd56eda04f5c5b5","action":"write","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"name":"","x":760,"y":220,"wires":[[],[]]},{"id":"628ab54495901021","type":"comment","z":"FFF0000000000001","name":"Bridging MQTT to OPC UA","info":"","x":510,"y":140,"wires":[]},{"id":"ce6b8a0e2c8a895d","type":"change","z":"FFF0000000000001","name":"","rules":[{"t":"set","p":"topic","pt":"msg","to":"ns=3;i=1010,datatype=Boolean","tot":"str"},{"t":"set","p":"payload","pt":"msg","to":"paylad","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":540,"y":220,"wires":[["a099aefb08837e70"]]},{"id":"0a89ebd0d9f6f577","type":"mqtt in","z":"FFF0000000000001","name":"","topic":"command/cnc/","qos":"2","datatype":"auto-detect","broker":"abd4e6202945fee3","nl":false,"rap":true,"rh":0,"inputs":0,"x":300,"y":220,"wires":[["ce6b8a0e2c8a895d"]]},{"id":"4cf4e425d075722a","type":"mqtt out","z":"FFF0000000000001","name":"","topic":"command/cnc/","qos":"1","retain":"","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"abd4e6202945fee3","x":660,"y":400,"wires":[]},{"id":"8e339e511c573905","type":"inject","z":"FFF0000000000001","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"false","payloadType":"bool","x":330,"y":400,"wires":[["4cf4e425d075722a"]]},{"id":"9c33cff54b0aca15","type":"comment","z":"FFF0000000000001","name":"Sending Command","info":"","x":490,"y":340,"wires":[]},{"id":"9dd56eda04f5c5b5","type":"OpcUa-Endpoint","endpoint":"opc.tcp://Roni:53530/OPCUA/SimulationServer","secpol":"None","secmode":"None","none":true,"login":false,"usercert":false,"usercertificate":"","userprivatekey":""},{"id":"abd4e6202945fee3","type":"mqtt-broker","name":"","broker":"http://broker.hivemq.com","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closeRetain":"false","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willRetain":"false","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":""}]
```
::

### Up Next

- [Using MQTT with Node-RED](https://flowfuse.com/node-red/protocol/mqtt/)
  Learn how to integrate MQTT with Node-RED to enhance your IoT solutions with real-time data messaging.
- [How to Build an OPC UA Client Dashboard in Node-RED](https://flowfuse.com/blog/2023/07/how-to-build-a-opc-client-dashboard-in-node-red/)
  Follow a step-by-step guide to create a comprehensive OPC UA client dashboard in Node-RED for effective monitoring and control.
- [Building a Secure OPC UA Server in Node-RED](https://flowfuse.com/node-red/protocol/opc-ua/)
  Explore best practices for configuring a secure OPC UA server in Node-RED to ensure safe and reliable data exchange.
- [How to Deploy a Basic OPC UA Server in Node-RED](https://flowfuse.com/blog/2023/07/how-to-deploy-a-basic-opc-ua-server-in-node-red/)
  Learn how to quickly deploy a basic OPC UA server in Node-RED for testing and development purposes.
- [Node-RED as a No-Code EtherNet/IP to S7 Protocol Converter](https://flowfuse.com/blog/2023/06/node-red-as-a-no-code-ethernet_ip-to-s7-protocol-converter/)
  Discover how to use Node-RED to seamlessly convert EtherNet/IP to S7 protocols with Node-RED.


# Monitoring and Optimizing Node-RED Flows with Open Telemetry (2026)

Have you ever found yourself frustrated by unexpected delays in your Node-RED flows, wondering where the bottlenecks are hiding? Even small latency issues can have a big impact on your system's performance. That's where Open Telemetry comes in. With its powerful distributed tracing capabilities, you can finally take control and get a clear view of how your flows are performing in real time.

Integrating Open Telemetry with Node-RED allows you to monitor latency across your flows. By implementing distributed tracing, you’ll gain the ability to see exactly where delays occur, helping you optimize performance and ensure your IoT applications run efficiently.

## What is Distributed Tracing and How Does Open Telemetry Help?

Distributed tracing is a method used to track and observe the flow of requests through different services within a distributed system. It provides insights into how requests are handled, where delays occur, and how different components interact. By visualizing the path of a request across your system, distributed tracing helps you identify performance bottlenecks and optimize the overall efficiency of your applications.

### What is OpenTelemetry?

Open Telemetry is an open-source framework designed to help you monitor and understand your software systems. It collects and organizes data on how your applications perform and behave, allowing you to track requests as they move through various services. Open Telemetry provides a standardized way to gather and analyze telemetry data, including traces, metrics, and logs, to give you a comprehensive view of your system’s performance.

In Node-RED The Open Telemetry module helps track messages by creating "spans" that record details about each message's journey. Every time a message moves from one node to another, a span is created to capture where it came from, where it’s going, and how long it took. These spans are linked together, showing the entire path of the message through the system. This makes it easier to spot slowdowns, fix problems, and improve how data moves through Node-RED. The module also makes sure this tracking information follows the message as it moves across different nodes and external services.

## Tracing in Node-RED Flows using Opentelemetry

:cta-image{alt="Power Workplace relies on FlowFuse for scalability, reliability and security audits - book a demo" cta="demo" src="https://flowfuse.com/images/cta/power-workplace-book-demo.png"}

In a manufacturing plant, Node-RED manages different machines and sensors. Suppose there's a problem with the production line, such as a delay in processing or a GPIO node experiencing issues reading data. With Open Telemetry integrated, you can trace the data flow through the system to see exactly where the issue is happening. This helps you quickly identify whether the problem is with a specific node that is reading the machine data or a delay in data processing, allowing you to fix the issue faster and keep the production line running smoothly.

For demonstration purposes, we will use a flow that simulates sensor reading and data processing. We will monitor this flow using Open Telemetry to track data across the system, identify bottlenecks, and optimize performance.

::render-flow
```json
[{"id":"78e4a1255f9d0ad1","type":"group","z":"45e56b4089cada94","name":"","style":{"label":true},"nodes":["636ac7b4d798a5c4","ac87db82c2ab66f5","c8a1749629359031","c0d30281031f07db"],"x":34,"y":139,"w":852,"h":82},{"id":"636ac7b4d798a5c4","type":"inject","z":"45e56b4089cada94","g":"78e4a1255f9d0ad1","name":"Temperature sensor","props":[{"p":"payload"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"300","payloadType":"jsonata","x":180,"y":180,"wires":[["c8a1749629359031"]]},{"id":"ac87db82c2ab66f5","type":"debug","z":"45e56b4089cada94","g":"78e4a1255f9d0ad1","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":780,"y":180,"wires":[]},{"id":"c8a1749629359031","type":"change","z":"45e56b4089cada94","g":"78e4a1255f9d0ad1","name":"Kelvin to Celsius","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload - 273.15","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":400,"y":180,"wires":[["c0d30281031f07db"]]},{"id":"c0d30281031f07db","type":"delay","z":"45e56b4089cada94","g":"78e4a1255f9d0ad1","name":"","pauseType":"delay","timeout":"2","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":600,"y":180,"wires":[["ac87db82c2ab66f5"]]}]
```
::

Deploy the flow above, and you might see a delay in the data shown on the debug panel. For this example, we added a Delay node before the Change node that converts temperature data from Kelvin to Celsius. While this delay is visible here, finding such delays in larger flows with many nodes can be difficult and time-consuming. Open Telemetry makes this easier by giving you detailed traces that show where delays or issues are happening

### Prerequisite

Before you start, ensure you have the following:

- [node-red-contrib-opentelemetry](https://flows.nodered.org/node/node-red-contrib-opentelemetry){rel="&#x22;nofollow&#x22;"} : Install this Node-RED module via the Node-RED Palette Manager.
- Open Telemetry exporter: Set up an Open Telemetry exporter to send trace data to a backend. For details on available exporters, visit [Open Telemetry Exporters](https://opentelemetry.io/docs/instrumentation/js/exporters/){rel="&#x22;nofollow&#x22;"}. For this guide, I have set up the [Jaeger](https://jaegertracing.io/){rel="&#x22;nofollow&#x22;"}.

### Setting Open Telemetry in Node-RED

!["Screenshot showing the configuration of opentelmetry node"](https://flowfuse.com/blog/2024/08/images/opentelmetry-node.png "Screenshot showing the configuration of opentelmetry node")*Screenshot showing the configuration of opentelmetry node*

1. Drag an `OTEL` node onto the canvas.
2. Double-click on the node and set the URL to your exporter endpoint (e.g., `http://localhost:4318/v1/traces` for a locally running Jaeger exporter). Provide a name for the service according to your preference, and set the Prefix, which will be added to the root Node-RED span name before the initial node name (you can keep it as "Message" if preferred).
3. In the Ignore field, add the names of nodes you want to exclude from Open Telemetry tracing.
4. In the Propagate field, add the names of nodes if you want them to forward trace headers to external systems or other nodes in the flow. This ensures that these nodes participate in the distributed trace, allowing the trace context to be maintained across different components.
5. Set the Timeout to define how long (in seconds) the OTEL node should wait before ending and discarding a message that has not been modified.
6. Now deploy the flow by clicking on the top-right deploy button.

Once the flow is deployed, Open Telemetry will start collecting and sending trace data to your specified exporter.

### Monitoring Performance Using the Exporter Web UI

Now, let's monitor the performance and latency between each node to identify delays. For this section, I am assuming you have Jaeger running as your exporter.

1. Open the Jaeger web UI in your browser. By default, it will be available at `http://localhost:16686/`.
2. Navigate to the "Search" by clicking on the "Search" option at the top.
3. Select the service name that you configured in the OTEL node from the service field. Once selected, you will see all the traces for each interaction in the flow. You can filter the traces by specific nodes using the operation field.
4. To monitor and find issues, select the desired trace and click on the "Find Trace" button. Click on the first trace to examine it.

Once the trace opens, you will see the duration taken by each node to process and pass data. Notice the time taken by the delay node, which is 2 seconds, indicating the problem. By clicking on the green line corresponding to this delay node, you can view more detailed information about the trace.

!["Image showing the total duration taken by the flow"](https://flowfuse.com/blog/2024/08/images/before.png "Image showing the total duration taken by the flow")*Image showing the tototal duration taken by the flow*

Since the issue was identified with the delay node, let's remove that delay node.

::render-flow
```json
[{"id":"636ac7b4d798a5c4","type":"inject","z":"350fb9fbb98012be","name":"Temperature sensor","props":[{"p":"payload"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"300","payloadType":"jsonata","x":200,"y":100,"wires":[["c8a1749629359031"]]},{"id":"ac87db82c2ab66f5","type":"debug","z":"350fb9fbb98012be","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":640,"y":100,"wires":[]},{"id":"c8a1749629359031","type":"change","z":"350fb9fbb98012be","name":"Kelvin to Celsius","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload - 273.15","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":420,"y":100,"wires":[["ac87db82c2ab66f5"]]}]
```
::

After updating the flow, redeploy the flow and check the traces again. You should see that the total time has been reduced significantly, with the overall flow now taking around 8 milliseconds instead of the previous 2 seconds. This demonstrates how Open Telemetry helps in identifying and resolving performance issues in your Node-RED flows.

!["Image showing the total duration taken by the flow after fixing the issue"](https://flowfuse.com/blog/2024/08/images/after.png "Image showing the total duration taken by the flow after fixing the issue")*Image showing the total duration taken by the flow after fixing the issue*

Throughout this guide, we’ve interacted with an exporter which is running locally. However, by deploying and setting up your exporter on a server, you can remotely monitor the performance of your Node-RED flows. This setup enables you to oversee your system's performance from anywhere, making it easier to detect and address issues promptly.

## Enhancing Monitoring and Optimization with FlowFuse

While OpenTelemetry excels at tracing and optimizing Node-RED flows, FlowFuse offers a powerful solution for managing and monitoring Node-RED instances. It streamlines the creation, deployment, and management of instances, allowing you to deploy your applications with a single click and minimizing deployment complexity and errors.

FlowFuse also boosts collaboration and security through features like team management, role-based access control, multi-factor authentication, and snapshot recovery. These capabilities ensure effective management, secure access, and easy recovery from changes, making FlowFuse an essential tool for optimizing and overseeing your Node-RED deployments.

## Conclusion

Integrating OpenTelemetry with Node-RED enables you to efficiently trace and resolve delays in your flows, ensuring smoother and more efficient operation of your IoT applications. By following the steps outlined in this guide, you can leverage distributed tracing to identify performance bottlenecks and optimize your flows effectively. With OpenTelemetry's detailed insights and FlowFuse's robust features, you'll be well-equipped to maintain peak performance and manage your Node-RED environment seamlessly.


# MQTT Sparkplug B Implementation: Protocol, Architecture & Best Practices

Connected devices can generate a lot of data, but without a standardized format, managing and consuming it can be tricky. MQTT certainly simplifies getting your messages delivered but it does not enforce any structure. This is where MQTT Sparkplug B helps by providing a clear, standardized format for data. In this guide, we’ll show you how to use MQTT Sparkplug B with Node-RED to make managing your device data easier and more organized.

## What is MQTT Sparkplug?

MQTT Sparkplug B is an open-source specification governed by the [Eclipse Foundation Specification Process (EFSP)](https://www.eclipse.org/projects/efsp/){rel="&#x22;nofollow&#x22;"}. It defines a standardized MQTT topic namespace and payload format specifically designed for Industrial IoT (IIoT), with particular focus on real-time [SCADA](https://flowfuse.com/use-cases/scada/), control systems, and [HMI](https://flowfuse.com/blog/2025/11/building-hmi-for-equipment-control/) solutions.

At its core, Sparkplug B extends MQTT 3.1.1 by adding structured topic namespace conventions, Google Protocol Buffer encoded payloads, state-aware birth and death certificates, metric aliasing for bandwidth optimization, and store-and-forward capabilities for intermittent connectivity. These additions transform MQTT from a simple messaging protocol into a complete industrial communication framework.

### The Industrial Integration Problem

In typical factory environments, every machine manufacturer implements MQTT differently. Consider a real-world scenario where Machine A publishes temperature data to `factory/line1/temp` with a JSON payload containing the temperature value. Meanwhile, Machine B sends its data to `sensors/machineB/env` with a completely different JSON structure that includes both temperature and timestamp. Machine C takes yet another approach, publishing raw numeric values to `data/mc/status` with no context or metadata.

Each device requires custom parsing logic, error handling, and documentation. Integration complexity grows exponentially with each new device type. Your development team spends weeks building and maintaining custom parsers instead of focusing on business logic.

![Manufacturing dashboard struggling with non-standardized MQTT data from multiple sources](https://flowfuse.com/blog/2024/08/images/with-plane-mqtt.png)*Dashboard complexity increases exponentially without standardized data formats*

With Sparkplug B standardization, all devices publish to structured topics following the format `spBv1.0/Factory/DDATA/Line1/MachineA` with consistent Protocol Buffer payloads. Each message contains typed metrics, timestamps, and quality indicators. Integration becomes predictable and maintainable. When you add a new device, it automatically describes its capabilities through birth certificates, eliminating the need for custom integration code.

![Manufacturing dashboard efficiently processing standardized Sparkplug B data](https://flowfuse.com/blog/2024/08/images/with-sparkplug.png)*Standardized format enables reliable data aggregation across heterogeneous devices*

## Sparkplug B Architecture Patterns

Several architectural patterns have emerged from production Sparkplug B deployments. Understanding these patterns helps you design scalable, maintainable systems.

### Edge Node Architecture

The edge node serves as the gateway between physical devices and the MQTT broker. A single edge node typically manages multiple devices, publishing aggregate birth certificates and handling communication for all attached devices. This centralized approach simplifies device management and reduces broker connections.

Edge nodes implement store-and-forward buffering to handle temporary connectivity loss. When the broker becomes unreachable, the edge node buffers data locally. After reconnection, it publishes buffered data with historical flags set, allowing applications to distinguish between real-time and historical data.

The edge node monitors broker connectivity and automatically publishes `NBIRTH` after reconnection. It manages sequence numbers across all messages from its devices, enabling applications to detect lost messages. Many edge nodes implement local data processing, filtering, and aggregation before publishing to reduce bandwidth and broker load.

### Primary Application Pattern

The primary application concept allows edge nodes to adapt their behavior based on application state. A designated primary application publishes STATE messages indicating its operational status. Edge nodes subscribe to these STATE messages and adjust their reporting frequency or metrics based on whether the primary application is online.

For example, an edge node might publish data every second when the primary SCADA application is connected but reduce to every 60 seconds when no primary application is available. This adaptive behavior conserves bandwidth and broker resources while ensuring data availability when needed.

### Command and Control Flow

Sparkplug B enables bidirectional communication through `NCMD` and `DCMD` messages. Applications publish commands to specific topics, and edge nodes or devices execute the commands and respond with updated metric values in `NDATA` or `DDATA` messages.

Command messages use the same Protocol Buffer format as data messages but flow in the opposite direction. Applications might send a write command to change a setpoint, a rebirth command to request fresh birth certificates, or a custom command to trigger device-specific actions. The standardized command structure enables generic control applications that work with any Sparkplug-compliant device.

:cta-image{alt="Arch Systems scales automation across complex manufacturing environments with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/arch-systems-book-demo.png"}

## The MQTT Sparkplug Specification for IIoT

Now that we have an overview of Sparkplug B and its role in standardizing data formats, it’s time to dive deeper into how this protocol structures its payloads and topics. Understanding these details will give you insight into how Sparkplug B efficiently manages data in complex industrial environments and will assist you in implementing it effectively in your own projects.

Sparkplug B utilizes Google Protocol Buffers (Protobufs) for encoding its messages. Protobufs offer a compact and fast way to serialize structured data, preserving MQTT's lightweight nature while introducing a robust framework for handling complex data.

### The MQTT Sparkplug Specification for IIoT

The Sparkplug B specification addresses critical industrial requirements that standard MQTT implementations typically handle inconsistently. The specification is built around several core concepts that work together to create a robust industrial messaging framework.

### Topic Namespace Architecture

Sparkplug B enforces a hierarchical topic namespace that follows a specific pattern: `spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}`. The namespace starts with the protocol version identifier `spBv1.0`, ensuring clients can identify Sparkplug messages. The group\_id provides logical grouping such as factory, building, or region. The message\_type specifies whether this is a birth certificate, data update, death notification, or command. The edge\_node\_id identifies the gateway or edge node, and optionally, a device\_id can specify individual devices under that edge node.

For example, a temperature sensor in a manufacturing facility might publish to `spBv1.0/Manufacturing/DDATA/Gateway01/TempSensor05`. This structured approach eliminates ambiguity and enables automatic topic subscription patterns.

### Protocol Buffer Payloads

Rather than using JSON or other text-based formats, Sparkplug B employs [Google Protocol Buffers](https://flowfuse.com/blog/2025/12/node-red-buffer-parser-industrial-data/) for message encoding. This choice delivers several advantages in industrial environments. The compact binary format produces significantly smaller messages than JSON, reducing bandwidth consumption on constrained networks. Protocol Buffers provide strongly typed data fields, eliminating parsing ambiguities. The format supports backward compatibility, allowing older clients to work with newer message versions. Finally, efficient parsing performance matters when handling thousands of messages per second.

### State Management System

The specification includes explicit state awareness through birth and death certificates. When an edge node or device connects to the broker, it publishes a birth certificate (`NBIRTH` for nodes, `DBIRTH` for devices) that declares all available metrics, their data types, and initial values. This self-description capability means applications can discover device capabilities automatically without external configuration files.

When devices disconnect, either gracefully or due to network failure, death certificates (`NDEATH`/`DDEATH`) signal the disconnection to all subscribers. The MQTT Last Will and Testament feature ensures death certificates publish even when devices lose connectivity unexpectedly. Sequence numbers in every message enable detection of lost messages, while timestamps provide temporal context for all data points.

### Metric Definition Framework

Each metric in Sparkplug B carries comprehensive metadata beyond just a name and value. The specification supports a wide range of data types including various integer sizes (Int8 through Int64, both signed and unsigned), floating-point numbers (Float and Double), Boolean values, strings, timestamps, UUIDs, binary data, and complex structures like datasets and templates.

Every metric includes a timestamp indicating when the value was captured, not just when it was transmitted. Quality flags indicate whether data is historical (stored and forwarded), transient (not to be stored), or null (sensor failure). This rich metadata enables applications to make informed decisions about data processing and storage.

### Message Types and Their Purposes

Sparkplug B defines specific message types for different communication needs. `NBIRTH` messages announce edge node connection and available metrics. `NDATA` messages carry periodic metric updates from edge nodes. `NDEATH` messages signal edge node disconnection. `DBIRTH`, `DDATA`, and `DDEATH` provide the same functions for devices under edge nodes.`NCMD` and `DCMD` enable command and control, allowing applications to send instructions to nodes and devices. STATE messages, published by primary applications, indicate application health and readiness.

## Sparkplug B vs Plain MQTT: Understanding the Differences

While both [plain MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/) and Sparkplug B use the same MQTT transport protocol, they solve **very different problems**.
Plain MQTT focuses on moving messages reliably, whereas Sparkplug B defines **how industrial data should be structured, identified, and managed** across devices and applications.

The table below highlights the practical differences that matter when designing real-world IIoT and SCADA systems.

| Category                   | Plain MQTT                                | MQTT Sparkplug B                               |
| -------------------------- | ----------------------------------------- | ---------------------------------------------- |
| **What it is**             | Messaging protocol                        | Industrial IoT specification built on MQTT     |
| **Primary purpose**        | Message transport                         | Standardized industrial data exchange          |
| **Topic structure**        | Fully custom, no enforced rules           | Strict, standardized namespace (`spBv1.0/...`) |
| **Payload format**         | JSON, text, or custom binary              | Google Protocol Buffers (binary, compact)      |
| **Payload consistency**    | Varies by device and vendor               | Guaranteed consistent structure                |
| **Data typing**            | Not enforced                              | Strongly typed metrics                         |
| **Device discovery**       | Manual configuration                      | Automatic via NBIRTH / DBIRTH                  |
| **State awareness**        | Limited (LWT only)                        | Full lifecycle (BIRTH, DATA, DEATH)            |
| **Message loss detection** | Not supported                             | Sequence numbers included                      |
| **Timestamps**             | Optional, application-defined             | Mandatory per metric                           |
| **Data quality flags**     | Custom implementation                     | Built-in (historical, transient, null)         |
| **Bandwidth efficiency**   | Lower (JSON overhead)                     | Higher (protobuf + metric aliasing)            |
| **Metric aliasing**        | Not available                             | Supported                                      |
| **Command & control**      | Custom topics and logic                   | Standardized NCMD / DCMD                       |
| **Interoperability**       | Low (vendor-specific)                     | High (vendor-neutral)                          |
| **Human readability**      | High                                      | Low (binary encoded)                           |
| **Debugging effort**       | Easy with basic tools                     | Requires Sparkplug-aware tools                 |
| **Scalability**            | Depends on custom design                  | Designed for large-scale IIoT                  |
| **Security**               | MQTT-level (TLS, ACLs)                    | MQTT-level (same as plain MQTT)                |
| **Learning curve**         | Low                                       | Medium to high                                 |
| **Best fit use cases**     | Small systems, prototypes, simple sensors | SCADA, HMI, multi-vendor industrial systems    |

## Using MQTT Sparkplug B with Node-RED

Now that we understand what Sparkplug B is and how it structures industrial data, let’s see how to use it in practice with Node-RED.

[Node-RED](https://flowfuse.com/node-red/) is a popular low-code tool for building IoT and industrial data flows. It’s widely used at the edge to connect devices, process data, and integrate with MQTT brokers. With dedicated Sparkplug nodes, Node-RED makes it easy to publish and consume Sparkplug B messages without manually handling topics, protobufs, or state management.

To run Node-RED reliably in production, especially for industrial and edge deployments, [FlowFuse](https://flowfuse.com) provides a managed platform for deploying, scaling, and managing Node-RED instances. FlowFuse also includes a built-in MQTT broker, making it simple to get started with Sparkplug B without additional infrastructure.

[Create a free FlowFuse account](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} to deploy Node-RED, connect devices, and start working with MQTT Sparkplug B in minutes.

In the following example, we’ll configure a Node-RED flow where a factory machine publishes temperature and humidity data using Sparkplug B, and then consumes that data downstream.

### Prerequisite

Before you begin, ensure you have the following:

- node-red-contrib-mqtt-sparkplug-plus: Install this [Node-RED package for Sparkplug B](https://flows.nodered.org/node/node-red-contrib-mqtt-sparkplug-plus){rel="&#x22;nofollow&#x22;"} support via palette manager.
- MQTT Broker: An MQTT broker is required to send and receive data between clients. If you do not already have one, FlowFuse offers a built-in MQTT broker service that simplifies the process of using MQTT with Node-RED, no external setup required. To learn how to use the FlowFuse MQTT Broker and create and manage clients, refer to the [FlowFuse MQTT documentation](https://flowfuse.com/docs/user/teambroker/).

### Configuring Node-RED for MQTT Sparkplug B

1. Drag any mqtt sparkplug node onto the canvas.
2. Double-click the mqtt sparkplug node to open the configuration panel.
3. Click the "+" icon next to the "Broker" field. Enter your MQTT broker's host address (e.g., `broker.flowfuse.cloud`), specify the port number (e.g., `1883` for unencrypted or `8883` for TLS), and configure the TLS settings if required. Enter the username and password, enter a Client ID, Set the "Keep Alive" interval (default is 60 seconds).
4. Switch to the Sparkplug tab by clicking the Sparkplug option in the top-right corner.
5. Enter a name in the "Name" field (this will be the Edge Node ID). Enter the group name in the "Group" field. Select "No" for the compression setting. Enable the "Use Alias for Metrics" option if you prefer not to send the full metric names every time and use aliases instead.
6. Click "Add" to save the configuration.

![Screenshot showing the configuration of Sparkplug broker config node](https://flowfuse.com/blog/2024/08/images/mqtt-broker-config.png "Screenshot showing the configuration of Sparkplug broker config node"):br*Screenshot showing the configuration of Sparkplug broker config node*

### Sending Data to MQTT with Sparkplug B

1. Drag the inject node onto the canvas. Set the `msg.payload` to the metrics you want to send and set the repeat interval according to your preference. This inject node could be any node that triggers the data sending. For testing purpose, you can use the following JSONata expression to simulate temperature and humidly metrics:
   ```json
   {
       "metrics": [
           {
               "name": "sensor/temperature",
               "value": $random() * 100
           },
           {
               "name": "sensor/humidity",
               "value": $random() * 100
           }
       ]
   }
   ```
2. Drag the mqtt sparkplug device node onto the canvas.
3. Double-click the mqtt sparkplug device node to open the configuration panel. Add the metric names that you will be sending by clicking the bottom-left "Add" button. Ensure that the names match the metric names in the payload you are sending and specify the data types for each metric.

![Screenshot showing the Sparkplug Device node configuration and the "Add" button for defining metrics](https://flowfuse.com/blog/2024/08/images/mqtt-sparkplug-device-node.png "Screenshot showing the Sparkplug Device node configuration and the 'Add' button for defining metrics"):br*Screenshot showing the Sparkplug Device node configuration and the "Add" button for defining metrics*

4. Switch to the Advanced tab by clicking the "Advanced" option at the top-right.
5. Enable the "Send Birth Immediately" option. This ensures that a Birth message (DBIRTH) is sent immediately upon deployment and connection to the MQTT broker. Note that enabling this option will send the `DBIRTH` message when the device node connects, but an `NBIRTH` message will be sent successful connection of mqtt sparkplug out node if you are using.

![Screenshot showing the Sparkplug Device node configuration and the "Add" button for defining metrics](https://flowfuse.com/blog/2024/08/images/mqtt-spark-device-advance.png "Screenshot showing the Sparkplug Device node configuration and the 'Add' button for defining metrics"):br*Screenshot showing the Sparkplug Device node configuration and the "Add" button for defining metrics*

6. Optionally, enable Store and Forward when not connected to ensure that messages are stored and sent once the connection is re-established. To use this option, make sure you have enabled it in the mqtt sparkplug broker config node and specified the destination.
7. Connect the inject node's output to the mqtt sparkplug device node's input.
8. Deploy the flow by clicking the top-right "Deploy" button.

Once you deploy the flow and all devices connect to the MQTT broker, the system automatically send a `DBIRTH` message as soon as each device within the node connects, signalling that the device is ready for data transmission.

::render-flow
```json
[{"id":"f2864f2b830e3590","type":"mqtt sparkplug device","z":"239c9025714089d3","name":"Machine1","metrics":{"sensor/temperature":{"dataType":"Float","name":"sensor/temperature"},"sensor/humidity":{"dataType":"Float","name":"sensor/humidity"}},"broker":"0d831bd9ba588536","birthImmediately":true,"bufferDevice":false,"x":380,"y":320,"wires":[["3dfc9b74f5e36bec"]]},{"id":"90cc413f58871fc1","type":"inject","z":"239c9025714089d3","name":"Send Metrics","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{    \"metrics\": [        {            \"name\": \"sensor/temperature\",            \"value\": $random()*100        },        {            \"name\": \"sensor/humidity\",            \"value\": $random()*100        }    ]}","payloadType":"jsonata","x":130,"y":320,"wires":[["f2864f2b830e3590"]]},{"id":"3dfc9b74f5e36bec","type":"debug","z":"239c9025714089d3","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":650,"y":320,"wires":[]},{"id":"0d831bd9ba588536","type":"mqtt-sparkplug-broker","name":"Local Host","deviceGroup":"My Devices","eonName":"Node-Red","broker":"localhost","port":"1883","tls":"","clientid":"","usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"enableStoreForward":false,"compressAlgorithm":"","aliasMetrics":true,"manualEoNBirth":false,"primaryScada":""}]
```
::

### Receiving Data from MQTT with Sparkplug B

1. Drag the mqtt sparkplug in node onto the canvas.
2. Double-click the node and configure the broker settings.
3. Enter the topic in the "Topic" field in the format `namespace/group_id/message_type/edge_node_id/[device_id]`. Use `DDATA` for receiving metrics you are sending using device node or a wildcard like `spBv1.0/group_id/+/+/[device_id]` to listen to all message types from a specific device.
4. Select the desired "QoS" level.
5. Drag a debug node onto the canvas.
6. Connect the mqtt sparkplug in node’s output to the debug node’s input.
7. Click "Deploy" to save and run the flow.

Now you will be able to see the `DBIRTH`, and `DDATA` messages printed on the debug panel.

::render-flow
```json
[{"id":"a98c49d80bb5c4ee","type":"mqtt sparkplug in","z":"239c9025714089d3","name":"","topic":"spBv1.0/My Devices/DDATA/Node-RED/Machine1","qos":"2","broker":"0d831bd9ba588536","x":330,"y":120,"wires":[["655761fb21409216"]]},{"id":"655761fb21409216","type":"debug","z":"239c9025714089d3","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":800,"y":120,"wires":[]},{"id":"0d831bd9ba588536","type":"mqtt-sparkplug-broker","name":"Local Host","deviceGroup":"My Devices","eonName":"Node-Red","broker":"localhost","port":"1883","tls":"","clientid":"","usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"enableStoreForward":false,"compressAlgorithm":"","aliasMetrics":true,"manualEoNBirth":false,"primaryScada":""}]
```
::

### Sending Commands for devices and EoN nodes

Beyond data exchange, MQTT Sparkplug B allows you to send commands for managing devices and Edge of Network (EoN) nodes, such as initiating a device's rebirth or signalling its death.

1. Drag inject node onto the canvas.
2. Set the `msg.command` in the inject node to the desired command. For instance, you can use the following JSON object to send a command that triggers a device's death:

```json
    {
        "device" : {
            "death" : true
        }
    }   
```

Alternatively, to send a command that triggers a device's rebirth, use:

```json
    {
        "device" : {
            "rebirth" : true
        }
    }   
```

3. Connect the output of the inject node to the input of the relevant mqtt sparkplug device node.
4. Deploy the flow by clicking the Deploy button at the top-right of the Node-RED interface.
5. Click the inject node’s button to send the command.

In this example, we've used an inject node to manually send commands, but you can also trigger these commands based on other inputs or conditions within your flow, such as device status or sensor data. For more information on available commands and advanced configurations, refer to the [MQTT Sparkplug nodes documentation](https://flows.nodered.org/node/node-red-contrib-mqtt-sparkplug-plus){rel="&#x22;nofollow&#x22;"}.

::render-flow
```json
[{"id":"f2864f2b830e3590","type":"mqtt sparkplug device","z":"239c9025714089d3","name":"Machine1","metrics":{"sensor/temperature":{"dataType":"Float"},"sensor/humidity":{"dataType":"Float"}},"broker":"0d831bd9ba588536","birthImmediately":true,"bufferDevice":false,"x":440,"y":320,"wires":[["3dfc9b74f5e36bec"]]},{"id":"90cc413f58871fc1","type":"inject","z":"239c9025714089d3","name":"Send connect command","props":[{"p":"command","v":"{\"node\":{\"connect\":true}}","vt":"jsonata"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":170,"y":260,"wires":[["f2864f2b830e3590"]]},{"id":"3dfc9b74f5e36bec","type":"debug","z":"239c9025714089d3","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":650,"y":320,"wires":[]},{"id":"915ca0772eebee04","type":"inject","z":"239c9025714089d3","name":"Send rebirth command","props":[{"p":"command","v":"{\"device\":{\"rebirth\":true}}","vt":"json"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":160,"y":320,"wires":[["f2864f2b830e3590"]]},{"id":"696db58cc9eb029d","type":"inject","z":"239c9025714089d3","name":"Send death command","props":[{"p":"command","v":"{\"device\":{\"death\":true}}","vt":"json"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":160,"y":380,"wires":[["f2864f2b830e3590"]]},{"id":"0d831bd9ba588536","type":"mqtt-sparkplug-broker","name":"Local Host","deviceGroup":"My Devices","eonName":"Node-Red","broker":"localhost","port":"1883","tls":"","clientid":"","usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"enableStoreForward":false,"compressAlgorithm":"","aliasMetrics":true,"manualEoNBirth":true,"primaryScada":""}]
```
::

If you need more flexibility in defining topic names when sending data, you can use the mqtt sparkplug out node. It’s quite similar to the standard mqtt out node but is designed to handle Sparkplug-encoded messages. Below is an example showing how to use the mqtt sparkplug out node with in nodes.

::render-flow
```json
[{"id":"bbe3765e67eed956","type":"mqtt sparkplug in","z":"f098830cc10afc2f","name":"","topic":"spBv1.0/+/+/#","qos":"2","broker":"0d831bd9ba588536","x":150,"y":100,"wires":[["d45ff4446380beaa"]]},{"id":"3b2b9788c51d5c3b","type":"mqtt sparkplug out","z":"f098830cc10afc2f","name":"","topic":"spBv1.0/My Devices/NDATA/Node-Red","qos":"","retain":"","broker":"0d831bd9ba588536","x":510,"y":200,"wires":[]},{"id":"d45ff4446380beaa","type":"debug","z":"f098830cc10afc2f","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":410,"y":100,"wires":[]},{"id":"dc73048fd385783a","type":"inject","z":"f098830cc10afc2f","name":"Send Metrics","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{    \"metrics\": [        {            \"name\": \"sensor/temperature\",            \"value\": $random(),            \"type\": \"Float\"        },        {            \"name\": \"sensor/humidity\",            \"value\": $random(),            \"type\": \"Float\"        }    ]}","payloadType":"jsonata","x":170,"y":220,"wires":[["3b2b9788c51d5c3b"]]},{"id":"0d831bd9ba588536","type":"mqtt-sparkplug-broker","name":"Local Host","deviceGroup":"My Devices","eonName":"Node-Red","broker":"localhost","port":"1883","tls":"","clientid":"","usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"enableStoreForward":false,"compressAlgorithm":"","aliasMetrics":true,"manualEoNBirth":false,"primaryScada":""}]
```
::

!["Images of some Sparkplug messages printed on debug panel"](https://flowfuse.com/blog/2024/08/images/sparkplug-messages.png "Images of some Sparkplug messages printed on debug panel")*Images of some Sparkplug messages printed on debug panel*

## Best Practices for Production Deployments

Getting Sparkplug B working is only the first step. Running it reliably in production means thinking about naming, state, performance, and failure handling from day one. The best practices below focus on the things that matter most once your system is live, keeping data trustworthy, networks efficient, and recovery predictable.

- **Name things like you mean it**
  Use clear group, edge, and device names that match your factory or system layout. Future you will thank you.
- **Birth messages are non-negotiable**
  Always send `NBIRTH` and `DBIRTH` on start and reconnect. If apps don’t see a birth, they don’t trust the data.
- **Alias your metrics**
  Turn on metric aliasing to cut payload size and keep networks fast and efficient.
- **Listen for Death messages**`NDEATH` and `DDEATH` are early warning signals. Use them to detect failures instantly.
- **Buffer with intent**
  Store-and-forward is great for flaky networks, just don’t let backlogs pile up unchecked.
- **Lock down MQTT early**
  Use TLS, authentication, and topic permissions from day one. Security is easier before go-live.
- **Break it on purpose**
  Restart brokers and edge nodes during testing. A system that recovers cleanly is production-ready.

## Conclusion

MQTT Sparkplug B transforms MQTT from a simple messaging protocol into a robust, standardized framework for industrial IoT. By enforcing structured topics, typed metrics, state awareness, and efficient payloads, it makes integrating heterogeneous devices predictable, scalable, and reliable.

Following best practices (clear naming, birth/death messages, metric aliasing, buffering, security, and deliberate testing) ensures your system runs smoothly in production and avoids costly downtime.

For teams looking to get Sparkplug B up and running quickly, [FlowFuse](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} provides a production-ready, easy-to-use platform. With minimal setup and no advanced skills required, you can deploy, scale, and monitor industrial flows in minutes. Start building your reliable, standardized IIoT solution today.


# FlowFuse 2.9: Software Bill of Materials & Public Static Assets

FlowFuse 2.9 bring improvements in application maintenance with the new "Software Bill of Materials" and in building full stack applications, with an iteration on the "Static Asset Service", by providing the option to "share" your assets assets publicly, making them consumable by external services and your Dashboards.

## Software Bill of Materials

This release sees the introduction of a new feature for our Enterprise customers, the Software Bill of Materials (SBOM).

![Screenshot showing the new Software Bill of Materials view in FlowFuse](https://flowfuse.com/blog/2024/09/images/screenshot-sbom.png){dataZoomable=""}

This view is available for all of your Applications in FlowFuse, and provides a detailed breakdown of all packages running in your Node-RED instances within your applications, making it easier to trace down out of date packages and keep on top of the security and integrity of your applications.

In the above screenshot, we get a clear picture of the different versions of Node-RED that I'm running, as well as the different packages that are installed in each of my instances. Highlighting in particular that I have some out-of-date versions of `@flowfuse/node-red-dashboard`.

It's possible to expand the detail for each entry to see which instances are running the respective package, and consequently jump in to update them if appropriate.

## Static Assets Service

[Last release](https://flowfuse.com/blog/2024/08/flowfuse-2-8-release) we published the new "Static Assets Service". This new feature provided an easy way to upload files alongside your Node-RED instances, and make them easily accessible in your Node-RED Editor.

In this new release we've expanded on that feature, now allowing you to make those files publicly accessible via a URL, making them available for consumption in your Dashboards, or wherever else you may want to consume that content.

:video[
Your browser does not support the video tag.
]{controls="true"}

This unlocks a new set of possibilities for building full stack applications in FlowFuse, for examples, making it easy to customize branding in your Dashboard to match your company's branding, or to serve up images and other assets to your users.

## And Much More...

For a full list of everything that went into our 2.9 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.9.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Coming Soon: MQTT Broker

FlowFuse already makes extensive use of MQTT under the covers. It provides the connection for our [Project Nodes](https://flowfuse.com/docs/user/projectnodes/) that make it very simple to move data between your Node-RED instances.

We're now working on opening up the broker to allow teams to connect their MQTT devices to the platform without having to manage their own broker infrastructure.

This feature will allow you to run and manage your own MQTT Clients alongside your Node-RED instances, making it easier to build full-stack IoT applications with FlowFuse.

We do not have a precise release date for this just yet, but we're hoping to having this in for 2.10 or 2.11. Keep an eye out for more information on this in the coming weeks. If this feature is of interest to you, please do [reach out](https://flowfuse.com/contact-us) and help us shape it to make sure it meets your needs.

## Try FlowFuse

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.

## Upgrading FlowFuse

If you're using \[FlowFuse Cloud]\({{ site.appURL }}), then there is nothing you need to do - it's already running 2.9, and you may have already been playing with the new features.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

If you have an Enterprise license please make sure to review this [changelog entry](https://flowfuse.com/changelog/2024/08/enterprise-license-update)

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go to the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# How to Scrape Data from Websites Using Node-RED

Web scraping has become an indispensable tool for monitoring news, tracking competitors, and gathering insights. In this guide, you'll learn how to harness the power of Node-RED for efficient web scraping, allowing you to extract and manage data from various websites with ease that are not exposed through an API.

## What is Web Scraping?

Web scraping is a technique for automatically extracting data from websites. Instead of manually copying information from web pages, web scraping uses tools or scripts to access and retrieve data from the Internet efficiently. This process allows you to quickly gather large volumes of information, which is helpful for tasks such as tracking market trends, aggregating news, or collecting product details. By automating data collection, web scraping helps save time and reduce human error. It enables users to extract and analyze structured data from various sources, making it easier to compile and utilize information for research, business intelligence, or other purposes.

Web scraping can be helpful when APIs are unavailable or do not meet your requirements. It allows you to collect data directly from web pages, which can be beneficial for tasks like competitive analysis, market research, or tracking specific online content.

## How Does Web Scraping Works?

Web scraping involves systematically extracting data from websites using automated tools or scripts. The process begins with requesting a specific webpage. The response from the server is the HTML content of the page. This HTML code contains the structured information displayed on the webpage, organized in a format that describes the layout and content.

Once the HTML is received, the next step is parsing it. Parsing involves analyzing the HTML structure to identify and extract the data of interest. This may include navigating through nested elements, locating specific tags, and using selectors to target precise content such as text blocks, images, or links. The extracted data is then processed and stored in a format that suits the user's needs, whether a database, a CSV file, or another format suitable for analysis.

## Web scrapping with Node-RED

In this section, we will guide you through the process of scraping data from publicly available websites using Node-RED and demonstrate how to extract data from a website specifically designed for scraping practice. For this example, we will scrape country data from the page at `https://www.scrapethissite.com/pages/simple/.`

### Sending Requests to a Webpage

To start scraping data, follow these steps to send an HTTP GET request to the webpage:

1. Drag the **inject** node onto the canvas. This node allows you to manually trigger the HTTP request or set it to fire at specific intervals.
2. Drag the **http request** node onto the canvas. Double-click it to configure and set the **Method** to `GET.` Enter the webpage URL you want to scrape (e.g., `https://www.scrapethissite.com/pages/simple/`).
3. Drag the **debug** node onto the canvas.
4. Connect the **inject** node's output to the input of the **http request** node and the **http request** node's output to the input of the **debug** node.
5. Click **Deploy** to save and deploy your flow.

Once deployed, click the **inject** button. You will see the raw HTML printed in the debug panel.

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

### Parsing and Extracting Data from HTML

Next, we need to process the raw HTML to extract meaningful data. This involves parsing the HTML content and identifying the specific information you want. To do this, first analyze the HTML structure of the webpage by opening the browser’s developer tools (press Ctrl + I or F12) and inspecting the elements to locate where the data is and in which HTML elements it resides.

#### Analyzing HTML Structure

Begin by analyzing the HTML structure of the webpage. Open your browser’s developer tools (press Ctrl + Shift + c ) and examine the elements to locate where the data resides and which HTML elements contain it. For example, on a page with a list of countries, each with its capital, population, and area, click on one of those countires elements to navigate to its HTML in the developer tools. Identify the selector that can be used to select those elements. On this webpage, the information about countries is contained within an element with the .countries class. You can use this class to extract all the data for the countries.

![Image showing the structure of the page and the data which we needed to extract](https://flowfuse.com/blog/2024/09/images/html-structer-of-target-website.png){dataZoomable=""}*Image showing the structure of the page and the data which we needed to extract*

#### Using Node-RED to extract data

1. Drag the **html** node onto the canvas.
2. Double-click the **html** node and enter the selector `.countries` into the "Selector" field.
3. Set the output to "only the text of element" and keep other settings default.
4. Drag the **debug** node onto the canvas.
5. Connect the output of the **http request** node to the input of the **html** node and the output of the **html** node to the input of the **debug** node.
6. Click **Deploy** to save and deploy your flow.

When you click the **inject** button, you will see the array containing the text content from each `.countries` div. While this data is a good starting point, it has yet to be in a format that is directly useful for analysis. To make the data more helpful, you'll need to transform it into objects with meaningful properties.

### Transforming Data into Structured Objects

You can use JavaScript in a Node-RED function node to transform data into structured objects. If you are familiar with JavaScript, this process will be straightforward. However, if you are not, you can use FlowFuse Expert to generate the necessary function. For more details, refer to our [LinkedIn Post](https://www.linkedin.com/posts/flowfuse_flowfuse-nodered-automation-activity-7226171132796637184-vKKt/?utm_source=share&utm_medium=member_desktop){rel="&#x22;nofollow&#x22;"} for a quick guide. However, in this section, we will use a low-code approach to transform the data.

1. Drag a **Split** node onto the canvas and connect it to the **HTML** node. This **Split** node will split the input array into individual string messages.
2. Drag a **Change** node onto the canvas and connect it to the **Split** node. Set `msg.name` to the following JSONata expression to extract the country name:
   ```json
   $trim($split(payload, "Capital: ")[0])
   ```
3. Set `msg.payload` to the following Jsonata expression that will extract the capital and population from the string:
   ```json
   $split($split(payload, "Capital: ")[1], "Population: ")
   ```
4. Drag another **Change** node onto the canvas and connect it to the previous **Change** node. Set `msg.capital` to the following Jsonata expression to trim and extract the value of the capital from the previously split data array:
   ```json
   $trim(payload[0])
   ```
5. Set `msg.payload` to the following Jsonata expression to split the remaining string for area extraction:
   ```json
   $split(payload[1], "Area (km2): ")
   ```
6. Drag another **Change** node onto the canvas and connect it to the **Change** node from the previous step. Set `msg.population` to the following Jsonata expression to trim and convert the population value to a number:
   ```json
   $number($trim(payload[0]))
   ```
7. Set `msg.area` to the following Jsonata expression to trim and convert the area value to a number:
   ```json
   $number($trim(payload[1]))
   ```
8. Drag another **Change** node onto the canvas and connect it to the last **Change** node. Set `msg.payload` to the following JSON object:
   ```json
   {
     "name": name,
     "capital": capital,
     "population": population,
     "area": area
   }
   ```
9. Finally, drag a **Join** node onto the canvas and connect it to the previous **Change** node. This Join node will create an array of the objects we have created.

When you click the inject button again, you will see that the data is now structured and formatted. The output will contain objects with properties such as name, capital, population, and area. This data can now be displayed on the FlowFuse dashboard table. For more details, refer to the [FlowFuse table widget](https://dashboard.flowfuse.com/nodes/widgets/ui-table.html){rel="&#x22;nofollow&#x22;"}.

::render-flow
```json
[{"id":"cc3c919ad9f93cc6","type":"inject","z":"380e37fed72e6885","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":280,"y":200,"wires":[["43ba04d623a8aa57"]]},{"id":"2d66b9fa2858cf5f","type":"html","z":"380e37fed72e6885","name":"","property":"payload","outproperty":"payload","tag":".country","ret":"text","as":"single","x":620,"y":200,"wires":[["c4e9a4c8.487e68"]]},{"id":"43ba04d623a8aa57","type":"http request","z":"380e37fed72e6885","name":"","method":"GET","ret":"txt","paytoqs":"ignore","url":"https://www.scrapethissite.com/pages/simple/","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":450,"y":200,"wires":[["2d66b9fa2858cf5f"]]},{"id":"8e7b462a5b5a064e","type":"ui-table","z":"380e37fed72e6885","group":"0c48f8d560157d3c","name":"","label":"text","order":1,"width":0,"height":0,"maxrows":0,"passthru":false,"autocols":true,"showSearch":true,"selectionType":"none","columns":[],"mobileBreakpoint":"sm","mobileBreakpointType":"defaults","x":1870,"y":200,"wires":[[]]},{"id":"c4e9a4c8.487e68","type":"split","z":"380e37fed72e6885","name":"Split Array","splt":"\\n","spltType":"str","arraySplt":"1","arraySpltType":"len","stream":false,"addname":"","x":810,"y":200,"wires":[["1a1e8a0a.8e7b06"]]},{"id":"1a1e8a0a.8e7b06","type":"change","z":"380e37fed72e6885","name":"Extract Name","rules":[{"t":"set","p":"name","pt":"msg","to":"$trim($split(payload, \"Capital: \")[0])","tot":"jsonata"},{"t":"set","p":"payload","pt":"msg","to":"$split($split(payload, \"Capital: \")[1], \"Population: \")","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":1000,"y":200,"wires":[["cfdb7c1f.9234b"]]},{"id":"cfdb7c1f.9234b","type":"change","z":"380e37fed72e6885","name":"Extract Capital & Population","rules":[{"t":"set","p":"capital","pt":"msg","to":"$trim(payload[0])","tot":"jsonata"},{"t":"set","p":"payload","pt":"msg","to":"$split(payload[1], \"Area (km2): \")","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":1240,"y":200,"wires":[["fb93f89b.b96138"]]},{"id":"fb93f89b.b96138","type":"change","z":"380e37fed72e6885","name":"Extract Population & Area","rules":[{"t":"set","p":"population","pt":"msg","to":"$number($trim(payload[0]))","tot":"jsonata"},{"t":"set","p":"area","pt":"msg","to":"$number($trim(payload[1]))","tot":"jsonata"},{"t":"set","p":"payload","pt":"msg","to":"{   \"name\": name,   \"capital\": capital,   \"population\": population,   \"area\": area}","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":1510,"y":200,"wires":[["342166ac8729e9d7"]]},{"id":"342166ac8729e9d7","type":"join","z":"380e37fed72e6885","name":"","mode":"auto","build":"object","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":true,"timeout":"","count":"","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":1710,"y":200,"wires":[["8e7b462a5b5a064e"]]},{"id":"0c48f8d560157d3c","type":"ui-group","name":"My Group","page":"d0def7a91d3b7aa1","width":"12","height":"1","order":1,"showTitle":false,"className":"","visible":"true","disabled":"false"},{"id":"d0def7a91d3b7aa1","type":"ui-page","name":"Page 1","ui":"c385dfc590b1308d","path":"/1","icon":"home","layout":"grid","theme":"6be033291dd76b17","order":1,"className":"","visible":false,"disabled":false},{"id":"c385dfc590b1308d","type":"ui-base","name":"Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control","ui-button"],"showPathInSidebar":false,"showPageTitle":false,"navigationStyle":"temporary","titleBarStyle":"default"},{"id":"6be033291dd76b17","type":"ui-theme","name":"Default Theme","colors":{"surface":"#202c34","primary":"#202c34","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#ffffff"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px","density":"default"}}]
```
::

![Left side: Image showing the countries table we created on the FlowFuse dashboard. Right side: The original webpage with countries.](https://flowfuse.com/blog/2024/09/images/webscrapping-result.png){dataZoomable=""}&#x2A;Left side: Image showing the table we created on the FlowFuse dashboard. Right side: The original webpage with countries.*

## Legal and Ethical Considerations

Web scraping can be a valuable tool for gathering data, but it's crucial to navigate the legal and ethical landscape responsibly. Adhere to websites' terms of service, respect intellectual property and data privacy laws, and avoid actions that could disrupt a site's operation or misuse the scraped data. By staying informed and adhering to best practices, you can harness the power of web scraping tools like Node-RED while remaining ethically and legally compliant.

## Conclusion

You’ve now learned to use Node-RED for web scraping, from sending requests and parsing HTML to transforming data into practical formats. This approach streamlines data collection from websites, making it easier to manage and analyze information efficiently.


# How to create and use Subflow in Node-RED (2026)

In traditional programming, managing complex and repetitive tasks can quickly lead to a tangled mess of code that’s hard to maintain and update. To tackle this issue, developers use libraries or modules, reusable chunks of code that help organize functionality, minimize duplication, and keep codebases clean and manageable.

Node-RED brings a similar solution to its visual programming environment with Subflows. Imagine Subflows as the visual counterpart to libraries. In this guide, we will explore what Subflows are, how to create them, and how to use them effectively to enhance your Node-RED experience.

## What Exactly Are Subflows?

![Image showing a Node-RED flow at the top selected for creating a Subflow, and the resulting Subflow at the bottom.](https://flowfuse.com/blog/2024/09/images/subflow.png){dataZoomable=""}&#x2A;Image showing a Node-RED flow at the top selected for creating a Subflow, and the resulting Subflow at the bottom.*

Subflows in Node-RED are a way to group together a set of nodes and reusable flows into a single, reusable node. This helps you manage and organize complex workflows by encapsulating repetitive or complex logic into a modular unit. You can think of Subflows as custom nodes that you create and use within your flows to simplify your design and reduce redundancy.

## Creating a Subflow in Node-RED

In this section, we will create a Subflow for a flow that sends requests to an API and returns results. If the request faces an issue, it retries until it reaches the maximum retry limit. Let's assume we need to use this flow in multiple places, for different APIs, each with different retry timeouts. To avoid duplicating the flow logic, we can create a Subflow.

To follow along, import the following flow into your Node-RED instance.

::render-flow
```json
[{"id":"132f4fdc40d55e89","type":"debug","z":"380e37fed72e6885","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":2840,"y":280,"wires":[]},{"id":"612819f76617e5a8","type":"debug","z":"380e37fed72e6885","name":"debug 3","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":2840,"y":220,"wires":[]},{"id":"7e9e8e1af751bb92","type":"inject","z":"380e37fed72e6885","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":1460,"y":240,"wires":[["8899fea497064b8c"]]},{"id":"b4eca1de14599dd1","type":"delay","z":"380e37fed72e6885","name":"","pauseType":"delayv","timeout":"5","timeoutUnits":"milliseconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":1900,"y":240,"wires":[["96ca1ed69e7fa7ac"]]},{"id":"96ca1ed69e7fa7ac","type":"http request","z":"380e37fed72e6885","name":"","method":"GET","ret":"txt","paytoqs":"ignore","url":"https://jsonplaceholder.typicode.com/todos","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":2050,"y":240,"wires":[["f523bb034db360a4"]]},{"id":"3eb4ec6b71fc383b","type":"switch","z":"380e37fed72e6885","name":"if success","property":"statusCode","propertyType":"msg","rules":[{"t":"btwn","v":"200","vt":"num","v2":"299","v2t":"num"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":2420,"y":240,"wires":[["612819f76617e5a8"],["bad4bdb7e00b7a80"]]},{"id":"bad4bdb7e00b7a80","type":"switch","z":"380e37fed72e6885","name":"if max retries","property":"retry_counter","propertyType":"msg","rules":[{"t":"gte","v":"10000","vt":"num"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":2590,"y":280,"wires":[["132f4fdc40d55e89"],["b4eca1de14599dd1"]]},{"id":"8899fea497064b8c","type":"change","z":"380e37fed72e6885","name":"","rules":[{"t":"set","p":"delay","pt":"msg","to":"retry_interval","tot":"msg"},{"t":"set","p":"retry_counter","pt":"msg","to":"0","tot":"num"}],"action":"","property":"","from":"","to":"","reg":false,"x":1720,"y":240,"wires":[["b4eca1de14599dd1"]]},{"id":"f523bb034db360a4","type":"change","z":"380e37fed72e6885","name":"retry_counter++","rules":[{"t":"set","p":"payload","pt":"msg","to":"retry_counter+1","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":2240,"y":240,"wires":[["3eb4ec6b71fc383b"]]}]
```
::

### Creating subflow of selection

:video{ariaLabel="Video showing process of creating subflow from the selection" autoPlay="true" height="354" loop="true" muted="true" playsInline="true" preload="none" width="800"}*Video showing process of creating subflow from the selection*

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

1. Select the flow you want to convert into a Subflow.
2. Open the main menu by clicking the top-right menu icon, and select "Selection to Subflow" under the Subflows option.

![Image showing subflow node added in the node palette](https://flowfuse.com/blog/2024/09/images/subflow-showing-in-pallete.png){dataZoomable=""}*Image showing subflow node added in the node palette*

Once selected, the Subflow will be added to the node palette like other nodes. The selected flow will also be converted into a single node representing the Subflow.

### Adding Properties to the Subflow

1. Double-click on the Subflow, then click on &#x2A;*"Edit Subflow template"**.

![Editing the Subflow template by clicking on the 'Edit Subflow Template' option.](https://flowfuse.com/blog/2024/09/images/edit-template-option.png){dataZoomable=""}&#x2A;Editing the Subflow template by clicking on the 'Edit Subflow Template' option.*

2. A new flow tab for the Subflow will open. Click on &#x2A;*"Edit Properties"** in the top-left corner.

![The edit properties button for a Subflow](https://flowfuse.com/blog/2024/09/images/edit-properties.png){dataZoomable=""}*The edit properties button for a Subflow*

3. To add environment properties, click on the &#x2A;*"+ add"** button located at the bottom-left.

![The 'Add' button for adding environment properties for subflow](https://flowfuse.com/blog/2024/09/images/add-env.png){dataZoomable=""}*The 'Add' button for adding environment properties for subflow*

4. In the field that opens, give the property a name and set its default value.
5. Once you have added all your properties, you can view a preview by switching to the &#x2A;*"UI PREVIEW"** tab.

![A preview of the Subflow environment properties](https://flowfuse.com/blog/2024/09/images/ui-preivew-env.png){dataZoomable=""}*A preview of the Subflow environment properties*

6. Click "Done" to save.

### Setting Added Environment Variables in the Nodes

Now that we have added properties for the Subflow (which are environment variables), we need to use them in the relevant nodes, such as the HTTP request node, which will require an API and the max-retry setting.

1. Double-click on the **HTTP request** node, set the environment variable as `${your_env_name}` into the URL feild, and click **Done** to save.

![The URL field of an HTTP request node in Node-RED with an environment variable added.](https://flowfuse.com/blog/2024/09/images/http-request-url-env-adding.png){dataZoomable=""}&#x2A;The URL field of an HTTP request node in Node-RED with an environment variable added.*

2. Next, double-click on the **switch** node named "if max retries," update the hardcoded max retry condition value to the environment variable you set for it, and click **Done** to save.

![The switch node in Node-RED with a max retry condition set using an environment variable.](https://flowfuse.com/blog/2024/09/images/max-retry-setting.png){dataZoomable=""}&#x2A;The switch node in Node-RED with a max retry condition set using an environment variable.*

### Managing Subflow Input and Output Ports

As we know, any node in Node-RED requires input and output ports to manage its data flow. Similarly, a Subflow node requires these ports to function correctly. In our Subflow example, it needs to be triggered and therefore requires at least one input port and one or more output ports. Specifically, our Subflow has two outputs: one for successfully fetched data and another to indicate when the maximum retry limit has been exceeded.

1. In the **Subflow** tab, at the top, you will see an option for **inputs** with values 0 and 1. Click on **1** to add an input port (as a any Node-RED node can have only one input port). Once set to 1, you will see an input port added in the Subflow tab. Connect it to the appropriate node; in our example, it should be connected to the first **change** node.

![Option to add input port for subflow](https://flowfuse.com/blog/2024/09/images/input-adding-subflow.png){dataZoomable=""}*Option to add input port for subflow*

2. Next, right after the **inputs** option, you will see an option for **outputs**. Unlike inputs, you can add as many outputs as you need. Once you've added the outputs, connect them to the appropriate nodes. In our example, the first output should be connected to the first input of both **switch** nodes.

![Option to add output ports for subflow](https://flowfuse.com/blog/2024/09/images/output-adding-subflow.png){dataZoomable=""}*Option to add output ports for subflow*

### Adding Status for Subflow Nodes

To effectively manage and monitor the execution of Subflows, you can add status indicators to your Subflow nodes. This allows you to see if the Subflow is functioning correctly and helps in debugging if something goes wrong. To add a status indicator:

1. In the Subflow flow tab at the top, click on the **Status** node option to add a status node. This status node can be connected to the Node-RED status node to capture and display all statuses, or you can configure it to use `msg.payload`.

![Option to add status for subflow](https://flowfuse.com/blog/2024/09/images/status-adding-subflow.png){dataZoomable=""}*Option to add status for subflow*

In our example, we need two indicators: one to display when the flow is retrying to request and another to indicate that the fetch operation has successfully completed.

2. Drag two **Change** nodes onto the Canvas. Connect one Change node to the **if success** switch node's first output and set the `msg.payload` to `"completed"`. Connect the other Change node to the **if max retries** switch node's first output and set its `msg.payload` to `"retrying"`. Then, connect both Change nodes to the input of the Subflow status node.

### Customizing the Appearance of a Subflow Node

Node-RED allows you to customize the appearance of Subflow nodes, including setting the color, icon, port labels, and selecting the category in which it will be visible in the node palette.

1. In the Subflow flow tab, click on the &#x2A;*"Edit Properties"*&#x2A; option in the top-left corner and switch to the &#x2A;*"Appearance"** tab.

![Image showing the apperance tab of subflow](https://flowfuse.com/blog/2024/09/images/customizing-apperance.png){dataZoomable=""}*Image showing the apperance tab of subflow*

2. Select a category from the available categories or add a new one by clicking on &#x2A;*"Add new"**.
3. Choose a color for the Subflow node and select an icon.
4. Provide labels for the ports so that when someone hovers over the Subflow input or output ports, they can quickly understand their purpose.

### Adding Documentation for a Subflow Node

Node-RED allows you to add documentation for Subflow nodes, providing guidance on how to use them. This documentation will be rendered in the help sidebar, similar to other nodes.

1. In the Subflow flow tab, click on the &#x2A;*"Edit Properties"*&#x2A; option in the top-left corner and switch to the &#x2A;*"Description"** tab.

![Image showing the description tab of subflow](https://flowfuse.com/blog/2024/09/images/documentation-tab.png){dataZoomable=""}*Image showing the apperance tab of subflow*

2. Enter the documentation content in markdown format that provides guidance on how to use the Subflow node effectively.
3. Click **Done** to save.

Once saved, the documentation will be displayed in the help sidebar when users click on the Subflow node in the Node-RED palette or hover over and select the help option for that node.

::render-flow
```json
[{"id":"ea5436b592a86b90","type":"subflow","name":"API Retry ","info":"## hee","category":"function","in":[{"x":50,"y":30,"wires":[{"id":"8899fea497064b8c"}]}],"out":[{"x":1140,"y":60,"wires":[{"id":"3eb4ec6b71fc383b","port":0}]},{"x":1610,"y":120,"wires":[{"id":"092547737a0cbee2","port":0}]}],"env":[{"name":"URL","type":"str","value":""},{"name":"MAX_RETRY","type":"str","value":""}],"meta":{},"color":"#D7D7A0","inputLabels":["Trigger"],"outputLabels":["API Response","Max Retry Exeeded"],"icon":"node-red/white-globe.svg"},{"id":"b4eca1de14599dd1","type":"delay","z":"ea5436b592a86b90","name":"","pauseType":"delayv","timeout":"5","timeoutUnits":"milliseconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":400,"y":80,"wires":[["96ca1ed69e7fa7ac"]]},{"id":"96ca1ed69e7fa7ac","type":"http request","z":"ea5436b592a86b90","name":"","method":"GET","ret":"txt","paytoqs":"ignore","url":"${URL}","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":550,"y":80,"wires":[["f523bb034db360a4"]]},{"id":"3eb4ec6b71fc383b","type":"switch","z":"ea5436b592a86b90","name":"if success","property":"statusCode","propertyType":"msg","rules":[{"t":"btwn","v":"200","vt":"num","v2":"299","v2t":"num"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":920,"y":80,"wires":[[],["bad4bdb7e00b7a80"]]},{"id":"bad4bdb7e00b7a80","type":"switch","z":"ea5436b592a86b90","name":"if max retries","property":"retry_counter","propertyType":"msg","rules":[{"t":"gte","v":"MAX_RETRY","vt":"env"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":1090,"y":120,"wires":[["092547737a0cbee2"],["b4eca1de14599dd1"]]},{"id":"8899fea497064b8c","type":"change","z":"ea5436b592a86b90","name":"","rules":[{"t":"set","p":"delay","pt":"msg","to":"retry_interval","tot":"msg"},{"t":"set","p":"retry_counter","pt":"msg","to":"0","tot":"num"}],"action":"","property":"","from":"","to":"","reg":false,"x":220,"y":80,"wires":[["b4eca1de14599dd1"]]},{"id":"f523bb034db360a4","type":"change","z":"ea5436b592a86b90","name":"retry_counter++","rules":[{"t":"set","p":"retry_counter","pt":"msg","to":"retry_counter+1","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":740,"y":80,"wires":[["3eb4ec6b71fc383b"]]},{"id":"092547737a0cbee2","type":"change","z":"ea5436b592a86b90","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"Max retry exeeded","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":1360,"y":120,"wires":[[]]},{"id":"132f4fdc40d55e89","type":"debug","z":"380e37fed72e6885","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":2420,"y":320,"wires":[]},{"id":"612819f76617e5a8","type":"debug","z":"380e37fed72e6885","name":"debug 3","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":2420,"y":200,"wires":[]},{"id":"7e9e8e1af751bb92","type":"inject","z":"380e37fed72e6885","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":1840,"y":260,"wires":[["ccadc2ba40bb8606"]]},{"id":"ccadc2ba40bb8606","type":"subflow:ea5436b592a86b90","z":"380e37fed72e6885","name":"","env":[{"name":"URL","value":"https://jsonplaceholder.typicode.com/photosS","type":"str"},{"name":"MAX_RETRY","value":"10000","type":"str"}],"x":2160,"y":260,"wires":[["612819f76617e5a8"],["132f4fdc40d55e89"]]}]
```
::

Now, just like regular Node-RED nodes, you can effectively use this Subflow node in your projects. With its added documentation, customized appearance, and status indicators, it integrates seamlessly into your Node-RED environment, enhancing both usability and functionality.

### Benefits of using subflows.

- **Modularity**: Subflows allow you to group related nodes into a single, reusable unit, making complex flows easier to manage.
- **Code Reuse**: They help avoid duplicating similar logic across different parts of your flow, saving time and effort.
- **Simplified Design**: Subflows can simplify your main flow by hiding complexity within a single node.
- **Easier Maintenance**: Updating a Subflow automatically updates all instances where it is used, making maintenance quicker.

## Conclusion

In this guide, we explored the concept of subflows in Node-RED, including their definition and purpose. We walked through the steps to create and configure subflows, demonstrating how to integrate them into your main flow. Additionally, we discussed how to edit and update existing subflows, and provided best practices for managing and organizing them effectively.


# Using Snapshots for Version Control in Node-RED with FlowFuse

Version control is essential, especially when multiple people are working on the same Node-RED project. Without it, changes can easily overlap, or worse, accidental updates could break critical flows. FlowFuse solves this challenge with snapshots, allowing you to create backups of your flows, restore previous versions, and safeguard your project from unexpected issues.

Let's look at how to use snapshots in FlowFuse to manage your Node-RED projects with confidence and prevent costly mistakes.

## What is Version Control and Snapshots

Using **version control** for Node-RED flows can introduce complexity and effort, as it often requires frequent pushes of changes to keep everything in sync. This is especially challenging in environments where modifications occur rapidly and continuously.

**Snapshots** simplify this process by providing point-in-time backups of your flows. In the context of Node-RED, snapshots automatically capture the state of your work, ensuring that you can quickly restore them if needed. It captures the following:

- **Flows**: The flow, including all nodes and config nodes of your Node-RED flows.
- **Credentials**: Any sensitive information used within flows using config nodes.
- **Environment Variables**: Environment variables you have used or defined within that Node-RED instance.
- **Packages**: The packages you have installed, including 3rd party contribution nodes and Node.js packages.
- **Runtime Settings**: The configurations that govern the behavior of your Node-RED runtime.

With snapshots in [FlowFuse](https://flowfuse.com), you can focus on developing your projects while having the confidence that your work is protected.

## Managing Snapshots in FlowFuse

Creating snapshots in FlowFuse is straightforward and can be done in just a few steps.

### Creating Snapshots for Cloud and Device Instances

Before we begin, it’s essential to understand the differences between a cloud instance and a device instance. For more information, refer to the [Documentation](https://flowfuse.com/docs/user/concepts/#instance).

Additionally, let’s discuss the two types of device assignments available in FlowFuse:

- Application Device
  - When a device is assigned to an instance, it can be considered as a mirror of the instance. In Fleet mode, it downloads and runs the target snapshot.
- Instance Device
  - When a device is assigned to an application, it can be considered as a standalone entity.

With that in mind, taking snapshots for an Application Device is a bit different from taking a snapshot for an Instance Device. For example, taking snapshots of an Application Device will have the same user experience as taking a snapshot of a cloud instance. However, since an Instance Device is typically closely coupled with the owner instance, there is a slightly different procedure. We will cover both below.

#### Creating Snapshots for Cloud Instance and Application Device

![Image showing the "Instances" option in the sidebar](https://flowfuse.com/blog/2024/09/images/instances-option-in-sidebar.png){dataZoomable=""}*Image showing the "Instances" option in the sidebar*

![Image showing the "Devices" option in the sidebar](https://flowfuse.com/blog/2024/09/images/devices-option-in-the-sidebar.png){dataZoomable=""}*Image showing the "Devices" option in the sidebar*

1. Log in to your FlowFuse account and navigate to the instances by clicking on &#x2A;*"Instances"*&#x2A; in the sidebar, or if you want to create a snapshot for an Application Device, click on &#x2A;*"Devices."**
2. Click on the instance or device you want to create a snapshot for. This will take you to the management interface, which includes different tabs for various settings.

![Image showing the option to switch to the Snapshots tab in FlowFuse Cloud Instance.](https://flowfuse.com/blog/2024/09/images/option-to-switch-to-snapshots-tab.png){dataZoomable=""}&#x2A;Image showing the option to switch to the Snapshots tab in FlowFuse Cloud Instance.*

![Image showing the option to switch to the Snapshots tab in FlowFuse Application Device.](https://flowfuse.com/blog/2024/09/images/application-device-snapshot-tab.png){dataZoomable=""}&#x2A;Image showing the option to switch to the Snapshots tab in FlowFuse Application Device.*

3. Switch to the &#x2A;*“Snapshots”*&#x2A; tab by selecting it from the instance management options. Here, you will find options to create a new snapshot called &#x2A;*"Create Snapshot"**.

![Image showing the button to create a snapshot in FlowFuse.](https://flowfuse.com/blog/2024/09/images/button-to-create-snapshot.png){dataZoomable=""}&#x2A;Image showing the button to create a snapshot in FlowFuse.*

4. Click on the button to **create snapshot**. You will be prompted to enter a **name and description** for the snapshot, helping you identify it later. There’s also an option to set this snapshot as Device Target Snapshot, enable this checkbox if needed.

![Image showing the form to provide a name and description for the snapshot.](https://flowfuse.com/blog/2024/09/images/form-to-give-snapshot-name-desc.png){dataZoomable=""}&#x2A;Image showing the form to provide a name and description for the snapshot.*

5. After creating the snapshot, you will receive a confirmation message indicating that the snapshot has been successfully created.

![Image showing a list of created snapshots with details in FlowFuse.](https://flowfuse.com/blog/2024/09/images/snapshot-in-the-list.png){dataZoomable=""}&#x2A;Image showing a list of created snapshots with details in FlowFuse.*

Once a snapshot is created, it will be visible in a list format. Each snapshot will display details such as the name, description, creator, and creation date, along with a three-dot icon.

![Image showing available options for managing snapshots in FlowFuse.](https://flowfuse.com/blog/2024/09/images/options-available-for-instance.png){dataZoomable=""}&#x2A;Image showing available options for managing snapshots in FlowFuse.*

Clicking on the icon will open different options to manage and operate the snapshot.

### Creating Snapshot for Device Instances when assigned to Cloud Instance

If the device is in fleet mode, it will be running the flows specified by the target snapshot, and there is typically no need to create a snapshot directly from the device. However, if the device is in developer mode, it may have been modified and may have different flows than those in the instances. In this case, you can take a snapshot directly from the device using the Developer Mode tab. Here’s how to do it:

1. Go to **Devices** by clicking on the **Devices** option in the sidebar, and then click on the specific device.
2. Once clicked, a similar interface will open as with instances, allowing you to manage and monitor its settings and configuration. Ensure that the device has developer mode enabled.

![Image showing the 'Create Snapshot' option in the Developer mode tab](https://flowfuse.com/blog/2024/09/images/option-to-create-device-snapshot.png){dataZoomable=""}*Image showing the 'Create Snapshot' option in the Developer mode tab*

3. Switch to the **Developer Mode** tab by clicking on the **Developer Mode** option at the top. In the Developer Mode section, you will see the **Create Snapshot** button. Click on it to create a snapshot, then enter the details such as the name and description. If needed, set it as the device target snapshot, and then click **Create**.

### Viewing and Comparing Snapshots

In the **Snapshots** tab, you can view all snapshots associated with your instance. FlowFuse also allows you to compare two snapshots, enabling you to track changes between different versions of your flows. This is especially useful for identifying specific changes that may have caused issues or to review the progress over time.

#### Viewing a Snapshot:

![Image showing the 'View Snapshot' option in the menu](https://flowfuse.com/blog/2024/09/images/view-snapshot-option.png){dataZoomable=""}*Image showing the 'View Snapshot' option in the menu*

1. Click on the three-dot icon next to the corresponding snapshot you want to view, then select **View Snapshot** from the menu.

![Image showing the snapshot view window in FlowFuse.](https://flowfuse.com/blog/2024/09/images/view-snapshot-window.png){dataZoomable=""}&#x2A;Image showing the snapshot view window in FlowFuse.*

2. After clicking, a new window will open displaying the entire flow for that snapshot. At the bottom right of this window, you'll find options to **copy** or **download** the flow.

#### Comparing Snapshots:

If you have multiple snapshots and want to compare them, follow these steps:

![Image showing the 'Compare Snapshot' option in the menu](https://flowfuse.com/blog/2024/09/images/compare-snapshot-option.png){dataZoomable=""}*Image showing the 'Compare Snapshot' option in the menu*

1. Click on the three-dot icon next to the snapshot you want to compare, then choose **Compare Snapshot**.

![Image showing the comparison window in FlowFuse, featuring a dropdown to select the instance to compare and a compare button.](https://flowfuse.com/blog/2024/09/images/window-comparing-snapshots.png){dataZoomable=""}*Image showing the comparison window in FlowFuse, featuring a dropdown to select the instance to compare and a compare button*

2. In the newly opened window, select another snapshot from the dropdown to compare it with the one you chose.

![Image showing the comparison window for snapshots in FlowFuse, with differences highlighted in light purple color.](https://flowfuse.com/blog/2024/09/images/window-comparing-snapshots-2.png){dataZoomable=""}&#x2A;Image showing the comparison window for snapshots in FlowFuse.*

3. The flows of both snapshots will be displayed side by side. At the top-right corner of the window, you will see two buttons, Use according to your preference:
   - **Prev**: Navigate to the previous difference between the two snapshots.
   - **Next**: Navigate to the next difference.

This comparison feature helps you easily identify changes, making it simple to spot issues or track flow modifications between versions.

### Downloading, Uploading, and Deploying Snapshots

Created snapshots can be downloaded locally, providing you with a backup of your Node-RED flows. This backup can be uploaded to another instance or restored in case of emergencies.

#### Downloading Snapshot:

![Image showing the 'Download Snapshot' option in the menu](https://flowfuse.com/blog/2024/09/images/download-snapshot.png){dataZoomable=""}*Image showing the 'Download Snapshot' option in the menu*

1. Click on the **three-dot** icon next to the corresponding snapshot, then select **Download Snapshot** from the menu.

![Image showing the prompt to download a snapshot in FlowFuse, featuring a highlighted key and the download button.](https://flowfuse.com/blog/2024/09/images/download-snapshot-prompt.png){dataZoomable=""}*Image showing the prompt to download a snapshot in FlowFuse, featuring a highlighted key and the download button*

2. A **Download Snapshot** dialog will open. Note: If the flows contain sensitive values, an additional field for **secret key** will be displayed. This is used to encrypt the sensitive values in the snapshot. As a convenience, a random secret is auto generated however you should change this to something memorable as it will be needed when you later upload the snapshot.
3. Next, click the **Download** button located at the bottom right of the prompt to download the snapshot.

#### Uploading Snapshots:

![Image showing the button to upload a snapshot in FlowFuse.](https://flowfuse.com/blog/2024/09/images/button-upload-snapshot.png){dataZoomable=""}&#x2A;Image showing the button to upload a snapshot in FlowFuse.*

1. In the **Snapshots** tab, click the **Upload Snapshot** button at the top-right corner.

![Image showing the prompt to upload a snapshot in FlowFuse.](https://flowfuse.com/blog/2024/09/images/upload-prompt.png){dataZoomable=""}&#x2A;Image showing the prompt to upload a snapshot in FlowFuse.*

2. Select the snapshot file from your local system. If a secret key was provided during the snapshot download, enter it. Otherwise, you will not be prompted for a key.
3. Click **Upload** to restore the snapshot to the desired instance.

With this process, you can easily manage your snapshots across different environments, ensuring the safety and portability of your Node-RED flows.

#### Deploying Snapshots

Once you have learned how to download and upload snapshots, deploying them is quite straightforward.

To deploy a snapshot:

![Image showing the 'Deploy Snapshot' option in the menu](https://flowfuse.com/blog/2024/09/images/deploy-snapshot.png){dataZoomable=""}*Image showing the 'Deploy Snapshot' option in the menu*

1. Click on the three-dot icon next to the corresponding snapshot and select **Deploy Snapshot** from the menu.
2. Next, you will be prompted to confirm the deployment. Review the details to ensure you are deploying the correct snapshot.
3. Click **Confirm** to proceed with the deployment.

Upon successful deployment, the instance will restart with the state captured in the snapshot. This includes all flows, credentials, environment variables, NPM packages, and runtime settings as they were at the time of the snapshot. This process allows you to quickly recover from issues or revert to a previously stable state in your Node-RED instance.

## Introducing Auto Snapshot

Creating snapshots is crucial for documenting changes, and manually creating them gives users full control over when snapshots are taken. However, manually doing this can be time-consuming, and there is always the risk of forgetting to create one before making changes. To simplify this process, FlowFuse introduces the **Auto Snapshot** feature.

Auto Snapshots automatically create backups whenever you deploy changes, ensuring that your work is continuously backed up without requiring manual intervention. These snapshots are labeled as &#x2A;*"Auto snapshot - yyyy-mm-dd hh\:mm\:ss"** for easy identification.

This feature allows you to focus on developing your Node-RED flows with the assurance that your changes are securely saved. If necessary, you can disable Auto Snapshots for devices only from the **Developer Mode** tab. This can be helpful to avoid excessive data usage when a device is in the field or on a cellular connection, or to prevent reaching the limit of auto snapshots with unnecessary snapshots.

### Disabling Auto Snapshots

1. Switch to the **Developer Mode** tab by clicking on the "Developer Mode" option at the top.

![Image showing option to enable/disable auto-snapshots for devices](https://flowfuse.com/blog/2024/09/images/enable-disable-auto-snapshot.png){dataZoomable=""}*Image showing option to enable/disable auto-snapshots for devices*

2. Once inside the Developer Mode tab, you will find the option to enable or disable the Auto Snapshot feature.

**Note:** A limit of 10 auto snapshots is maintained, with the oldest one being deleted when a new one is created. Also this feature is only available to **Team** and **Enterprise** users.

## Setting a Device Target Snapshot

When you set a device target snapshot, all devices associated with the instance will be restarted and updated to run that specified snapshot. This gives you full control over when devices receive the latest changes from your development instance.

With this feature, you can continue developing and testing your flows in FlowFuse without immediately impacting your devices. Once you're confident the flow is ready, you can push the changes to the devices by setting the target snapshot.

Device target snapshots can be assigned either during the creation of a snapshot or at a later time.

### To set the already creted Snapshot as a Device Target Snapshot:

1. Go to the **Snapshots** tab and click on the three-dot icon next to the desired snapshot.

![Image showing the 'Set as Device Target' option in the menu](https://flowfuse.com/blog/2024/09/images/set-targe-snapshot-option.png){dataZoomable=""}*Image showing the 'Set as Device Target' option in the menu*

2. Select **Set as Device Target** from the menu, prompt will open to conform then click on to the "Set Target".

![Image showing the green status indicating how many devices have deployed this snapshot option in the menu.](https://flowfuse.com/blog/2024/09/images/status-showing-the-target-snapshot.png){dataZoomable=""}&#x2A;Image showing the green status indicating how many devices have deployed this snapshot option in the menu.*

Once done you will be able to see the green mark in that snapshot showing on how much devices it is deployed on.

## Common Mistakes to Avoid

1. **Neglecting Regular Backups**: Don’t skip those snapshots! Regularly create backups, especially before making significant changes, moving devices through instances or applications, or disabling developer mode. Think of it as your safety net, ensuring you can always bounce back to a stable state if unexpected issues pop up.
2. **Overlooking Auto-Snapshot Limits**: Did you know that your **auto snapshots** have limits? Be mindful of how many you can retain, as older **auto snapshots** will be automatically deleted. If you have important **auto snapshots**, either rename them to avoid automatic deletion or download and save them locally to keep them safe. Remember, manually created snapshots have no limits, so take advantage of that!
3. **Secret Key**: The secret key used to encrypt your snapshot is crucial for when you later need to upload that snapshot. When downloading snapshots locally, securely store that key. Losing it could mean losing access to your snapshot and your ability to recover your work. Treat it like a password, keep it safe!
4. **Taking a Snapshots of the wrong thing**: When a device is owned by an instance it typically runs the same flows however, if a device flows may have been modified directly in **developer mode** it will have different flows to the instance that owns it. In this case, before you move the device or switch it out of developer mode, it is recommended that you take a snapshot directly from the device itself. Direct device snapshots are performed on the **Developer Mode** tab of the device.
5. **Deploying Unverified Snapshots**: A little caution goes a long way! Always review and verify the details of a snapshot before deploying it. Jumping into deployment without checking can lead to unexpected behavior or the loss of critical configurations. Take the time to ensure everything is in order.

### Conclusion

Using snapshots in FlowFuse is an effective way to manage your Node-RED projects with confidence. By regularly creating snapshots, you can ensure that you always have a backup of your work, allowing you to quickly recover from mistakes or accidental changes.


# MQTT Service Now Available on FlowFuse

In our [recent product update](https://flowfuse.com/blog/2024/10/flowfuse-release-2-10) we have added our very own MQTT service, built-in and ready to use alongside your Node-RED applications. We are always engaging with users and prospective customers and this has been a highly requested feature, and so we are delighted to announce that this is now live on FlowFuse Cloud for our Pro and Enterprise teams.

:product-update-note

The MQTT Service is available now on [FlowFuse Cloud](https://app.flowfuse.com/account/create/){rel="&#x22;nofollow&#x22;"}. FlowFuse permits you to setup your own secure clients to begin publishing and subscribing to your own topics.

You can now use FlowFuse to manage your own MQTT Clients alongside your Node-RED instances, making it easier to build full-stack, event-driven applications within FlowFuse.

## Use Cases

FlowFuse MQTT Service simplifies access to real-time data, an important element in optimizing industrial processes. With the power of FlowFuse, Node-RED and the MQTT service, your integrations are now even easier. Here are some typical uses cases:

- Connect your MQTT enabled PLCs (like Omron N Series, Siemens S7, etc) to your Node-RED instance to open up such possibilities like:
  - Data collection and analysis, Predictive Maintenance, OEE, Condition Based Monitoring.
  - Triggering actions like sending Emails or alerting your engineers about an event.
  - Realtime production monitoring of your facility.
- Make use of modern IIoT devices on legacy systems by bridging the gap with MQTT.
- Connect disparate systems together where Node-RED and FlowFuse act as the central hub for data processing and routing. This gives you the advantage of transforming data on the fly, applying extra contextual data from other systems, apply routing rules, and much more.

## Pricing

If you're on the Pro or Enterprise tiers of FlowFuse Cloud, then you don't have to pay any extra to get started with the MQTT Service.

- **Pro Tier:** Includes **5 clients for free** as part of your existing plan
- **Enterprise Tier:** Includes **20 clients for free** as part of your existing plan

In the near future we'll be publishing extra packages of clients that you can add to your team, beyond the amounts included with the base tiers.

## Getting Started

To get started with your own MQTT Clients, navigate to [FlowFuse Cloud](https://app.flowfuse.com){rel="&#x22;nofollow&#x22;"}, and Sign In.

1. Click the new "Broker" option in the left navigation menu
2. Click "Create Client"

![Screenshot of FlowFuse's "Create Client" interface](https://flowfuse.com/blog/2024/10/images/mqtt-broker-add-client.png){dataZoomable=""}*Screenshot of FlowFuse's "Create Client" interface*

3. Fill out the client's credentials (Username + Password)
4. Define the "Access Control Rules" (see more below)
5. Click "Confirm"

With your client created, you can then, in Node-RED, use the MQTT nodes to connect to your new client.

Setting up a new broker in Node-RED, you can use your credentials accordingly:

![Screenshot of the MQTT Config, "Connection" tab in the Node-RED Editor](https://flowfuse.com/blog/2024/10/images/mqtt-broker-config.png){dataZoomable=""}{width=400}
*Screenshot of the MQTT Config, "Connection" tab in the Node-RED Editor*

And the respective "Security" tab:

![Screenshot of the MQTT Config, "Security" tab in the Node-RED Editor](https://flowfuse.com/blog/2024/10/images/mqtt-broker-security.png){dataZoomable=""}{width=440}
*Screenshot of the MQTT Config, "Security" tab in the Node-RED Editor*

### Access Control Rules

In MQTT, you can publish and subscribe to *topics*.

These topics are strings that you can use to organise your data. In the Access Control Rules, you can define which topics your client can publish and subscribe to.

For example, in a flow deployed to many PLCs on your factory floor, you might be publishing to the topics `factory/body-shop/plc/1`, `factory/body-shop/plc/2`, etc.

![Simplified example of MQTT data flow for a Factory Floor](https://flowfuse.com/blog/2024/10/images/mqtt-factory-architecture.jpg){dataZoomable=""}*Simplified example of MQTT data flow for a Factory Floor*

Then, in a Cloud-Hosted flow, you can subscribe to `factory/body-shop/plc/#` to receive all messages from all PLCs in the body shop, and display relevant data into a Dashboard.

Each client that you create can be constrained in two ways:

- **Action**: You can limit clients to whether than can *only* subscribe, *only* publish, or conduct both actions.
- **Topic**: You can control which topics a given client can interact with.

These constraints are particularly useful to ensure security throughout your MQTT network, and to ensure that data is only being sent and received by the correct components.


# Dialogs, Customizable Icons and Histograms Now Available in FlowFuse Dashboard

This update introduces new ways to enhance data visualization and customization in your dashboards. With key improvements, including a new chart type, customizable app icon support and a dialog feature for groups, this release helps tailor dashboards for better user interaction and flexibility.

## New Chart Type: Histogram

Histograms are an essential tool for data analysis, offering a clear way to visualize distributions. The latest Dashboard update introduces a fully customizable histogram chart type, allowing you to present frequency distributions for your data.

Whether analyzing performance metrics or user activity, histograms can give you a clear view of how data points are distributed across predefined ranges. You can now easily group data and control the range, providing deeper insights at a glance.

![Screenshot showing the new Histogram chart type](https://flowfuse.com/blog/2024/10/images/chart-histogram.png){dataZoomable=""}*Screenshot showing the new Histogram chart type*

The real advantage of this new Histogram chart type is that it simplifies the process for you. Just pass in the raw data, and the histogram will automatically organize it into meaningful ranges, then display how often each range occurs. This makes it incredibly easy to extract valuable insights without the need for manual data processing.

You can see an example flow for the Histogram chart type [here](https://dashboard.flowfuse.com/nodes/widgets/ui-chart.html#histograms){rel="&#x22;nofollow&#x22;"} in our documentation.

## Customizable App Icon

Branding is an essential part of any user experience and with this new feature, you can customize your dashboard's app icon. The Node-RED Dashboard 2.0 now allows users to provide their own application icon, which appears in the browser tab and when the dashboard is installed as a Progressive Web App (PWA). This customization helps reinforce your brand, whether you’re developing IoT solutions, monitoring systems or creating dashboards for end-users.

![Screenshot showing the customizable app icon in browser and as a PWA](https://flowfuse.com/blog/2024/10/images/app-icon-installation.png){dataZoomable="" style="max-width: 400px; margin: auto;"}*Screenshot showing the customizable app icon in browser and as a PWA*

You can configure the icon by navigating to the base UI settings (ui-base) and providing an icon URL.

You can read more about how to use this feature in the [App Icon Documentation](https://dashboard.flowfuse.com/nodes/config/ui-base.html#application-icon){rel="&#x22;nofollow&#x22;"}

## Building Dialogs

Organizing data on dashboards has become more efficient with the new "Dialog/Modal" feature. Groups in Dashboard now have a new ["Type"](https://dashboard.flowfuse.com/nodes/config/ui-group.html#type){rel="&#x22;nofollow&#x22;"} property, so they can be rendered inline as before, or instead rendered as a Dialog. The display of the dialog groups can be controlled (opened/closed) via the [Control](https://dashboard.flowfuse.com/nodes/widgets/ui-control.html#show-hide){rel="&#x22;nofollow&#x22;"} node.

This removes the need for building custom modals and dialogs in a Template node, and makes the entire experience of building your dialogs low-code.

![Screenshot showing groups rendered as dialogs in the dashboard](https://flowfuse.com/blog/2024/10/images/ui-group-type-dialog.png){dataZoomable=""}*Screenshot showing groups rendered as dialogs in the dashboard*

By utilizing groups as dialogs, users can maintain a clean dashboard while still having quick access to detailed data when required.

You can read more about the new property, and see an example flow in the [UI Group Documentation](https://dashboard.flowfuse.com/nodes/config/ui-group.html#type){rel="&#x22;nofollow&#x22;"}

## What else is new?

You can find the full 1.18.0 Release Notes [here](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v1.18.0){rel="&#x22;nofollow&#x22;"}.

Just to highlight a few, particularly valuable, updates and fixes:

- UI Chart - Group tooltips for line chart.
- UI Button Group
  - Show node status
  - Add pointerdown/pointerup event handling and fix button theming bug
- UI Table - Support key type option for entering fixed strings as item labels
- UI Switch - Layout Switching with Dynamic Configuration Support

## What's Next?

Work has already begun on the next release, `1.19.0`, you can see what items we have queued up [here](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}, if you've got any feedback or suggestions, please do let us know, and feel free to open new issues on our [GitHub](https://github.com/FlowFuse/node-red-dashboard/issues){rel="&#x22;nofollow&#x22;"}


# Using FlowFuse Project Nodes for Faster and More Efficient Communication

Node-RED is a powerful tool for IoT application development, connecting various services and devices. However, establishing communication between different Node-RED instances, whether for monitoring or control, can be complex. This often requires detailed configurations and protocols like MQTT, HTTP, or CoAP, despite its seamless integration with many protocols.

FlowFuse addresses this challenge with project nodes designed for easy and efficient communication between Node-RED instances. This guide will show you how to use FlowFuse project nodes to enhance communication and integration, complete with practical demonstrations.

## What Are FlowFuse Project Nodes?

[FlowFuse](https://flowfuse.com) is a platform that helps manage multiple Node-RED instances in one place. This centralized management makes it easier for teams to collaborate and share resources while simplifying scaling and enhancing project security.

To facilitate communication between these centrally organized instances, FlowFuse introduces specific project nodes that enable easy and secure message exchange without complex setup. Behind the scenes, these project nodes utilize MQTT, ensuring that communication is lightweight and fast.

These project nodes include three main types:

![Image: Project nodes.](https://flowfuse.com/blog/2024/10/images/project-nodes.png){dataZoomable=""}*Left :project-in node, Middle: Project-out node, Right: Project-call node*

- **Project In**: Listens for messages being broadcast by other Node-RED instances or for messages sent directly to this instance.
- **Project Out**: Sends messages to other Node-RED instances.
- **Project Call**:sends messages to other Node-RED instances to trigger specific flows and waits for a response that can be sent using the project out node.

## Using FlowFuse Project nodes

In this section, we will explore how to use the FlowFuse project nodes. We’ll begin by explaining the Project In and Project Out nodes, followed by a detailed look at the Project Call node.

### Using Project in and out nodes

To demostrate this nodes, we will use an example where a central instance monitors the CPU performance of multiple Node-RED instances every 10 seconds.

Before we start, let’s understand their configurations:

#### Project In Node

- **Name**: A descriptive label for the node.
- **Source**:
  - **Receive**: Select this option to receive messages sent specifically to this instance.
  - **Receive Broadcast From**: Choose this option to listen for messages broadcast from other instances. A dropdown will include the names of all instances within your team.
- **Topic**: This field allows you to specify a topic, similar to MQTT, to categorize the messages.

#### Project Out Node

- **Name**: A descriptive label for the node.
- **Mode**:
  - **Send Specified Project Node**: This option allows you to send a specific message or payload to the selected instance. Use this for one-way communication.
  - **Return Project Link Call**: This option sends used to sent response back using a Project Out node project call node.
- **Target**:
  - **Send Message To Instance**: A dropdown to select the instance.
  - **Broadcast Messages**: Option to send messages to all instances.
- **Topic**: This field allows you to specify a topic, similar to MQTT, to categorize the messages.

## Example: Monitoring CPU Performance Of Node-RED Instances

## Prerequisites

Before we begin, ensure you have installed the following nodes via the Palette Manager:

- **node-red-contrib-cpu**: This node is essential for monitoring CPU performance. Install it on the instances that you want to monitor.
- **@flowfuse/node-red-dashboard**: This node is used for creating a dashboard interface. Install it on the central instance, as we will be visualizing the CPU performance data collected from the monitored instances.

### Creating the Flow on the Instances to Monitor

In this section, we will learn how to create a flow that monitors CPU performance and sends data using **Project out**. We will also discuss how to make this flow reusable, allowing you to apply the same setup across multiple instances without editing the flow each time.

1. Drag the **Inject** node onto the canvas and set the repeat interval to "2 seconds". This will trigger the flow after every 2 seconds.
2. Drag the **CPU** node onto the canvas. Double-click it to configure, enable the option "Send message for overall usage," and click "Done".
3. Drag the **Change** node onto the canvas. Configure it to add metadata, including the instance name, instance ID, using default environment variablesand and the CPU data received from the CPU node.
4. Drag the **Project Out** node onto the canvas. Double-click it to set the Mode to "Send to specified project node." For the Target, select "Send message to instance" and choose the name of your centralized instance.
5. Next, Enter the topic as "cpu-performance".
6. Connect the output of the **Inject** node to the input of the **CPU** node, the output of the **CPU** node to the input of the **Change** node, and finally, connect the **Change** node to the **Project Out** node.

::render-flow
```json
[{"id":"dd182fedce6c532a","type":"inject","z":"fe61f54c8563279d","name":"","props":[{"p":"payload"}],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":190,"y":200,"wires":[["c47bc42f8a6f6884"]]},{"id":"e0dd915a7b37af2b","type":"project link out","z":"fe61f54c8563279d","name":"project out 1","mode":"link","broadcast":false,"project":"054bb5cf-20df-431f-a00b-29b28e160b27","topic":"cpu-performance","x":770,"y":200,"wires":[]},{"id":"05a9ec7b2ae57cc0","type":"change","z":"fe61f54c8563279d","name":"","rules":[{"t":"set","p":"data.name","pt":"msg","to":"FF_INSTANCE_NAME","tot":"env"},{"t":"set","p":"data.cpu","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":560,"y":200,"wires":[["e0dd915a7b37af2b"]]},{"id":"c47bc42f8a6f6884","type":"cpu","z":"fe61f54c8563279d","name":"","msgCore":false,"msgOverall":true,"msgArray":false,"msgTemp":false,"x":370,"y":200,"wires":[["05a9ec7b2ae57cc0"]]}]
```
::

By utilizing environment variables, this flow becomes reusable, allowing you to copy and paste flow to monitor multple instances.

### Receiving Data to Monitor and Visualize

:video{ariaLabel="Video: Line chart visualizing CPU performance of all instances." autoPlay="true" height="263" loop="true" muted="true" playsInline="true" preload="none" width="800"}&#x2A;Video: Line chart visualizing CPU performance of all instances.*

To receive the CPU data from monitored instances, follow these steps in your centralized Node-RED instance:

1. Open the editor for your central instance.
2. Drag the **Project In** node onto the canvas.
3. Double-click the **Project In** node and set the **Source** to "Listen for broadcast messages from." Select the name of the instances you want to monitor from the dropdown. If you want data from all instances, select "All instances and devices."
4. Enter the **Topic** as "cpu-performance" (or the topic you configured in the Project Out nodes).
5. Drag a **ui-chart** widget onto the canvas. Set the chart type to "line" and configure the series to `msg.payload`.
6. Connect the output of the **Project In** node to the input of the **ui-chart** node.
7. Click the "deploy" button.

::render-flow
```json
[{"id":"2d681b19eb5799b7","type":"change","z":"d382bd2b5733a3a9","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"data.cpu","tot":"msg"},{"t":"set","p":"topic","pt":"msg","to":"data.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":400,"y":220,"wires":[["307d9c5913509557"]]},{"id":"307d9c5913509557","type":"ui-chart","z":"d382bd2b5733a3a9","group":"d0dbd4016c7aac21","name":"","label":"chart","order":1,"chartType":"line","category":"topic","categoryType":"msg","xAxisLabel":"","xAxisProperty":"","xAxisPropertyType":"property","xAxisType":"time","xAxisFormat":"","xAxisFormatType":"auto","yAxisLabel":"","yAxisProperty":"","ymin":"","ymax":"","action":"append","stackSeries":false,"pointShape":"cross","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"3600","removeOlderPoints":"","colors":["#0095ff","#ff0000","#ff7f0e","#2ca02c","#a347e1","#d62728","#ff9896","#9467bd","#c5b0d5"],"textColor":["#666666"],"textColorDefault":true,"gridColor":["#e5e5e5"],"gridColorDefault":true,"width":"12","height":8,"className":"","x":630,"y":220,"wires":[[]]},{"id":"465ee550bf9d101d","type":"project link in","z":"d382bd2b5733a3a9","name":"project in 1","project":"all","broadcast":false,"topic":"cpu-performance","x":180,"y":220,"wires":[["2d681b19eb5799b7"]]},{"id":"d0dbd4016c7aac21","type":"ui-group","name":"Device Monitoring Chart","page":"39fae809f6f7fc7b","width":"12","height":"1","order":1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"39fae809f6f7fc7b","type":"ui-page","name":"Device Monitoring","ui":"ded86f3820342985","path":"/charts-example","icon":"chart-box-outline","layout":"grid","theme":"5075a7d8e4947586","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"ded86f3820342985","type":"ui-base","name":"My Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"showPageTitle":true,"navigationStyle":"default","titleBarStyle":"default"},{"id":"5075a7d8e4947586","type":"ui-theme","name":"Default Theme","colors":{"surface":"#ffffff","primary":"#0094CE","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
```
::

Once deployed, open the dashboard to view an interactive live line chart displaying the CPU performance of all monitored devices.

#### Visualizing Data for Specific Devices

:video{ariaLabel="Video: Gauges visualizing the CPU performance of different devices." autoPlay="true" height="136" loop="true" muted="true" playsInline="true" preload="none" width="800"}&#x2A;Video: Gauges visualizing the CPU performance of different devices.*

To visualize CPU data for specific devices separately, configure the **Project In** node to "Listen for broadcast messages from" and select the desired instance name that you want to monitor.

In the instance sending the CPU data for monitoring, set the **Project Out** node to "Broadcast messages." This will send CPU data to all instances within your team, allowing the centralized instance to capture and display the information.

If you prefer not to use broadcasting, configure the **Project Out** node with specific topics. This will ensure that receiving nodes capture only specific instance data based on the topic. You can then connect these nodes to gauge nodes to distinctly display the CPU performance for each instance.

::render-flow
```json
[{"id":"c0021ca894dd3e17","type":"change","z":"d382bd2b5733a3a9","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"data.cpu","tot":"msg"},{"t":"set","p":"ui_update.label","pt":"msg","to":"data.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":360,"y":140,"wires":[["932a6733d53ab87d"]]},{"id":"426925e74d8e30f5","type":"project link in","z":"d382bd2b5733a3a9","name":"project in 1","project":"04175120-ebeb-4813-8910-03f92f8ed429","broadcast":true,"topic":"cpu-performance","x":140,"y":140,"wires":[["c0021ca894dd3e17"]]},{"id":"932a6733d53ab87d","type":"ui-gauge","z":"d382bd2b5733a3a9","name":"","group":"087559f9b99f047a","order":1,"width":"4","height":"4","gtype":"gauge-half","gstyle":"needle","title":"gauge","units":"units","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#5cd65c"},{"from":"4","color":"#ffc800"},{"from":"7","color":"#ea5353"}],"min":0,"max":10,"sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":590,"y":140,"wires":[]},{"id":"38539dc4bfdbf6be","type":"change","z":"d382bd2b5733a3a9","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"data.cpu","tot":"msg"},{"t":"set","p":"ui_update.label","pt":"msg","to":"data.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":360,"y":240,"wires":[["bdbcd5f9f8ac610c"]]},{"id":"e36b12aa51d365fe","type":"project link in","z":"d382bd2b5733a3a9","name":"project in 2","project":"04175120-ebeb-4813-8910-03f92f8ed429","broadcast":true,"topic":"cpu-performance","x":140,"y":240,"wires":[["38539dc4bfdbf6be"]]},{"id":"bdbcd5f9f8ac610c","type":"ui-gauge","z":"d382bd2b5733a3a9","name":"","group":"6cf5326fe928c9cf","order":1,"width":"4","height":"4","gtype":"gauge-half","gstyle":"needle","title":"gauge","units":"units","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#5cd65c"},{"from":"4","color":"#ffc800"},{"from":"7","color":"#ea5353"}],"min":0,"max":10,"sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":590,"y":240,"wires":[]},{"id":"a2e1fba0e9cd985a","type":"change","z":"d382bd2b5733a3a9","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"data.cpu","tot":"msg"},{"t":"set","p":"ui_update.label","pt":"msg","to":"data.name","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":360,"y":340,"wires":[["c298b64b260df708"]]},{"id":"dcfe73c16e17648a","type":"project link in","z":"d382bd2b5733a3a9","name":"project in 3","project":"8a611136-6e3f-447e-9436-34b2d00eac8e","broadcast":true,"topic":"cpu-performance","x":140,"y":340,"wires":[["a2e1fba0e9cd985a"]]},{"id":"c298b64b260df708","type":"ui-gauge","z":"d382bd2b5733a3a9","name":"","group":"ee5fc3eb29a7ee4b","order":1,"width":"4","height":"4","gtype":"gauge-half","gstyle":"needle","title":"gauge","units":"units","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#5cd65c"},{"from":"4","color":"#ffc800"},{"from":"7","color":"#ea5353"}],"min":0,"max":10,"sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":590,"y":340,"wires":[]},{"id":"087559f9b99f047a","type":"ui-group","name":"Device Group 1","page":"39fae809f6f7fc7b","width":"4","height":"2","order":3,"showTitle":false,"className":"","visible":"true","disabled":"false"},{"id":"6cf5326fe928c9cf","type":"ui-group","name":"Device Group 2","page":"39fae809f6f7fc7b","width":"4","height":"2","order":2,"showTitle":false,"className":"","visible":"true","disabled":"false"},{"id":"ee5fc3eb29a7ee4b","type":"ui-group","name":"Device Group 3","page":"39fae809f6f7fc7b","width":"4","height":"2","order":1,"showTitle":false,"className":"","visible":"true","disabled":"false"},{"id":"39fae809f6f7fc7b","type":"ui-page","name":"Device Monitoring","ui":"ded86f3820342985","path":"/charts-example","icon":"chart-box-outline","layout":"grid","theme":"5075a7d8e4947586","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"ded86f3820342985","type":"ui-base","name":"My Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"showPageTitle":true,"navigationStyle":"default","titleBarStyle":"default"},{"id":"5075a7d8e4947586","type":"ui-theme","name":"Default Theme","colors":{"surface":"#ffffff","primary":"#0094CE","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
```
::

This example showcases one of many powerful use cases for FlowFuse project nodes. By utilizing these capabilities, you can transform how your Node-RED instances communicate, enabling efficient workflows and innovative solutions.

## Using Project Call Nodes

**Project Call** nodes are ideal for triggering flows deployed on another Node-RED instance and retrieving the final result as a response. While they function similarly to [webhooks](https://flowfuse.com/node-red/integration-technologies/webhook/), they utilize [MQTT](https://flowfuse.com/node-red/protocol/mqtt/) as their underlying mechanism instead of HTTP. In this section, we will demonstrate the use of a **Project Call** node through an example of making an on-demand temperature request.

### How Project Call Nodes Work

The **Project Call** node does not operate in isolation; it requires both **Project In** and **Project Out** nodes to function properly. The **Project Call** node triggers the **Project In** node deployed on the specified target instance, while the **Project Out** node handles the response. This means the flow that needs to be triggered should start with a **Project In** node and end with a **Project Out** node.

### Example: On-Demand Temperature Request

In this example, we will trigger a flow on a Raspberry Pi instance that reads the temperature using a DHT11 sensor and sends the response back to the instance where we use the **Project Call** node.

Before we start, let’s review the configuration options for the **Project Call** node:

#### Project Call Node Configuration

- **Name**: A descriptive label for the node.
- **Timeout**: Set the duration to wait for a response before timing out.
- **Target**: Specify the target instance where the flow is deployed.
- **Topic**: This field allows you to specify a topic, similar to MQTT, to categorize the messages.

#### Prerequisites

Before we begin, ensure you have the following prepared:

- **node-red-contrib-dht-sensor**: Install this node via the palette manager. This node is used to manage the connection to a DHT11 or DHT22 sensor on a Raspberry Pi.
- **FlowFuse Device Agent Setup**: Ensure you have set up and are running the FlowFuse device agent on your Raspberry Pi, and it is connected to the platform.

#### Developing a Flow to Handle On-Demand Data Requests

Throughout this section, we will explore how to utilize the **Project Call** node along with **Project In** and **Project Out** nodes to trigger a flow that retrieves temperature readings from a Raspberry Pi on demand.

***Note**: Before proceeding, make sure your device is assigned to an instance. If the device is assigned to an application, you cannot use Project nodes, as they are designed to work with instances.*

::render-flow
```json
[{"id":"bdb27b9ab0d94897","type":"inject","z":"b152a914653d9fce","name":"Trigger","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"5","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":260,"y":380,"wires":[["8a4fe9cf342b6156"]]},{"id":"4ece54ca3c91f7ff","type":"debug","z":"b152a914653d9fce","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":680,"y":380,"wires":[]},{"id":"8a4fe9cf342b6156","type":"rpi-dht22","z":"b152a914653d9fce","name":"","topic":"rpi-dht22","dht":"11","pintype":"0","pin":4,"x":460,"y":380,"wires":[["4ece54ca3c91f7ff"]]}]
```
::

1. Copy/download the flow above and import/upload it into your Raspberry Pi Node-RED instance. Ensure you have correctly interfaced the DHT11 sensor with your Raspberry Pi. For more information, refer to our guide on [Setting Up Node-RED on Raspberry Pi 4](https://flowfuse.com/node-red/hardware/raspberry-pi-4/), which explains how to install the device agent on the Raspberry Pi and read temperature data from the DHT11 sensor.
2. Deploy the flow.

Once you deploy the flow, you will see the temperature data displayed on the Debug panel if everything was done correctly. Now, let’s add the project nodes to trigger the temperature reading flow on demand and retrieve the data accordingly.

3. Drag the **Project In** node onto the canvas, double-click on it, and set the source to "Receive messages sent to this instance." Next, enter the topic.
4. Replace the **Inject** node with the **Project In** node.
5. Next, you can add a **Change** node to format the data received by the **DHT** node.
6. Drag the **Project Out** node onto the canvas, double-click on it, and set the mode to "Return to project link call."

Once the flow is ready, deploy it. The final flow should look like the one below:

::render-flow
```json
[{"id":"020ede0bf68cf063","type":"change","z":"fe61f54c8563279d","name":"","rules":[{"t":"set","p":"data.temperature","pt":"msg","to":"payload","tot":"msg"},{"t":"set","p":"data.humidity","pt":"msg","to":"humidity","tot":"msg"},{"t":"delete","p":"payload","pt":"msg"},{"t":"delete","p":"humidity","pt":"msg"},{"t":"set","p":"topic","pt":"msg","to":"rpi-dht11","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":560,"y":220,"wires":[["1a592414ab69f1d8"]]},{"id":"a39fcfcd133ecaae","type":"project link in","z":"fe61f54c8563279d","name":"project in 1","project":"all","broadcast":false,"topic":"temperature","x":160,"y":220,"wires":[["16e8a24545d3258f"]]},{"id":"1a592414ab69f1d8","type":"project link out","z":"fe61f54c8563279d","name":"project out 1","mode":"return","broadcast":false,"project":"b1dd1d7d-556e-4dd4-9b8f-d78ffe3f510d","topic":"","x":790,"y":220,"wires":[]},{"id":"16e8a24545d3258f","type":"rpi-dht22","z":"fe61f54c8563279d","name":"","topic":"rpi-dht11","dht":"11","pintype":"0","pin":4,"x":340,"y":220,"wires":[["020ede0bf68cf063"]]}]
```
::

Now that we have added the **Project In** and **Project Out** nodes, the flow can be triggered to read the temperature from any Node-RED instance within your team using the **Project Call** node and receive the response.

#### Triggering the Flow and Receiving Temperature Data

In this section, we will explore how to trigger the flow we created in the previous step and receive the on-demand temperature data.

1. Navigate to the instance within your team where you want to receive the data.
2. Drag the **Project Call** node onto the canvas. Double-click it to set the timeout according to your preference, then set the target to the instance where your flow needs to be triggered. Next, enter the topic you configured in the **Project In** node previously.
3. Drag an **Inject** node onto the canvas and connect it to the input of the **Project Call** node. This will allow you to trigger the **Project Call** node manually.
4. Finally, drag a **Debug** node onto the canvas and connect it to the output of the **Project Call** node. This will help you view the response received from the triggered flow in the Debug panel.
5. Deploy the flow.

::render-flow
```json
[{"id":"8276fba516f3697b","type":"project link call","z":"d382bd2b5733a3a9","name":"","project":"d1b6cf3a-70fc-4ec4-b30c-e207338b2cc4","topic":"temperature","timeout":"30","x":530,"y":200,"wires":[["9ef6638382d7e9d5"]]},{"id":"0abdbf43350eb362","type":"inject","z":"d382bd2b5733a3a9","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":320,"y":200,"wires":[["8276fba516f3697b"]]},{"id":"9ef6638382d7e9d5","type":"debug","z":"d382bd2b5733a3a9","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":740,"y":200,"wires":[]}]
```
::

Now, once you click the **Inject** button, you will see the response that includes the temperature in the debug panel, which is read by the flow deployed on the Raspberry Pi.

:video{ariaLabel="Video showing the project call node triggering the flow to read the temperature data" autoPlay="true" height="832" loop="true" muted="true" playsInline="true" preload="none" width="1908"}&#x2A;Video showing the project call node triggering the flow deployed on the device to read the temperature data.*

Now that you understand how to use FlowFuse project nodes, you can significantly improve the way your Node-RED instances communicate with one another.

## Conclusion

FlowFuse project nodes streamline communication between Node-RED instances. By using these nodes, you can easily monitor performance, request data, and more. This makes your workflows smoother and more efficient.


# FlowFuse's Software bills of material helps enhance Application Security and Management

FlowFuse recently launched Software Bill of Materials (SBoM) for enterprise customers. This powerful tool enhances security and management within projects, particularly in the Node-RED ecosystem. As open-source libraries and software continue to play a pivotal role in the industry, monitoring third-party components used in projects becomes essential. The SBoM enables organizations to track dependencies and identify vulnerabilities, ensuring compliance and mitigating risks.

## What is an SBoM, and How Does It Enhance Security?

A Software Bill of Materials (SBoM) is a detailed list of all the components that make up a software application. Just as a bill of materials for a physical product lists every part used in its construction, an SBoM provides a breakdown of all the software libraries, packages, and dependencies in a project.

This transparency is crucial for security, allowing developers and organizations to track what’s inside their software. By knowing precisely what components are in use, you can quickly identify outdated or vulnerable dependencies that may pose security risks. An SBoM helps you monitor third-party nodes, ensuring that any related security issues can be addressed promptly and reducing the chance of vulnerabilities being exploited.

## How You Can Use SBoM to Enhance Security in Your Node-RED Applications

Here are some effective strategies for leveraging SBoM in your Node-RED applications:

1. **Regular Monitoring**: Frequently review your SBoM to identify outdated or vulnerable packages. Proactive monitoring helps catch potential security threats early.
2. **Timely Upgrades**: When you spot vulnerabilities in your packages, prioritize upgrading them. Keeping dependencies up to date is crucial for maintaining security and performance.
3. **Evaluate Third-Party Nodes**: Assess the third-party nodes in your application. If any appear unmaintained or outdated, consider alternatives to ensure ongoing security.

By integrating these practices into your workflow, you can effectively manage dependencies and strengthen the security of your Node-RED solutions.

## Exploring the FlowFuse SBoM Feature

To support the effective monitoring and assessment of your dependencies, FlowFuse provides a dedicated Software Bill of Materials (SBoM) interface in the platform. For those who may not be familiar, &#x2A;*[FlowFuse](https://flowfuse.com)** offers a comprehensive platform that enables engineers to effectively build, manage, and secure their applications. By integrating IT and operational technology (OT) environments, FlowFuse streamlines the process of connecting, collecting, transforming, and visualizing industrial data.

### Accessing FlowFuse SBoM Interface

The Software Bill of Materials (SBoM) interface is available at the application level. For more information on the application, refer to the [Documentation](https://flowfuse.com/docs/user/concepts/#application). To access it:

1. Navigate to your Node-RED application within the FlowFuse platform.

![Image showing the 'Applications' option in the FlowFuse platform](https://flowfuse.com/blog/2024/10/images/applications-options-in-the-ff.png){dataZoomable=""}&#x2A;Image showing the 'Applications' option in the FlowFuse platform.*

2. Click the **Dependencies** option at the top to switch to the SBoM interface.

![Image showing the 'Dependencies' option in the FlowFuse platform for the SBoM interface.](https://flowfuse.com/blog/2024/10/images/dependencies-tab-option.png){dataZoomable=""}&#x2A;Image showing the 'Dependencies' option in the FlowFuse platform for the SBoM interface.*

*Note: This feature is only available for FlowFuse Enterprise customers.*

### Understanding What the SBoM Interface Shows

Once you navigate the tab, you will see a list of all the packages installed within your Node-RED Cloud instances and devices associated with that application. This includes the package names and versions, the number of devices and instances using each version, and additional details such as the latest available version of each package and the time since its release.

![Image showing the Dependencies tab along with the detailed notes of each item displayed.](https://flowfuse.com/blog/2024/10/images/the-dependency-tab-info.png){dataZoomable=""}&#x2A;Image showing the Dependencies tab along with the detailed notes of each item displayed.*

Incorporating a Software Bill of Materials into your development process not only enhances security but also fosters a culture of accountability and transparency within your team. By understanding your dependencies, you can make informed decisions that protect your applications and ensure compliance with industry standards.


# FlowFuse Security Features You Didn’t Know You Needed

When it comes to securing Node-RED applications and its editor, ensuring that your flows and data are protected from unauthorized access can feel like a daunting task. Even after investing considerable time, achieving the right level of security often remains a complex challenge. For enterprises, this goes far beyond access control, security is a cornerstone of protecting sensitive data, maintaining operational continuity, and meeting strict regulatory requirements. A robust security framework not only prevents breaches but also safeguards intellectual property, preserves trust, and shields the organization from costly cyber threats.

Here are 9 ways FlowFuse simplifies and strengthens your Node-RED deployments, ensuring you’re fully protected without the hassle.

## Default Security Measures to Keep Your Environment Safe

Securing your Node-RED applications is essential to protect sensitive data, proprietary business logic, and critical systems from unauthorized access or cyberattacks. Without proper safeguards, the risks of data loss, operational disruptions, and reputational damage are significant. FlowFuse implements robust security measures right from the start, ensuring your deployments remain safe. Data is encrypted during transmission, and rate limiting prevents traffic overloads, ensuring smooth operations. Additionally, secure tunnelling facilitates safe communication between your edge devices and the FlowFuse platform. To ensure that only authorized personnel have access to your FlowFuse team, we’ve implemented strong login authentication measures, which can be further enhanced with multi-factor authentication as needed.

Here’s the best part- we don’t just offer default protections; we empower you to fine-tune your security defences. FlowFuse features a user-friendly interface that allows you to customize your security settings and design a strategy tailored to your needs. Rest easy knowing that we've laid a solid security foundation while giving you the flexibility to enhance your defences.

If you're interested in learning more about how we safeguard your data privacy and security, we invite you to read our detailed [security statement](https://flowfuse.com/platform/security/). Additionally, we are proud to announce that [FlowFuse has achieved SOC 2 Type 1 compliance](https://flowfuse.com/blog/2024/01/soc2/), demonstrating our commitment to maintaining the highest standards in security and data protection.

### Single Sign-On (SSO) Integration

Every organization relies on various tools and platforms to enhance productivity and efficiency. Providing seamless access to these resources is vital for optimizing workflows. That’s where Single Sign-On (SSO) comes in, it simplifies the onboarding and offboarding processes.

With SSO, team members can log in using their existing credentials, eliminating the hassle of remembering multiple passwords. This streamlines their login experience and enables them to be productive from day one.

To implement SSO for your self-hosted FlowFuse, refer to the following resources:

- [How to Set Up SSO SAML for Node-RED](https://flowfuse.com/blog/2024/07/how-to-setup-sso-saml-for-the-node-red/)
- [How to Set Up SSO LDAP for Node-RED](https://flowfuse.com/blog/2024/07/how-to-setup-sso-ldap-for-the-node-red/)

If you are using FlowFuse Cloud, please get in touch with us for configuration assistance.

### Two-Factor Authentication (2FA)

We've all been there, managing countless passwords, hoping they're strong enough to protect against security threats. But in today’s digital world, passwords alone aren’t sufficient. That’s why Two-Factor Authentication (2FA) has become essential.

FlowFuse understands this need. By enabling 2FA, even if someone gets hold of your password, they'll still require a second form of verification, like a code sent to your phone, to access your account. This simple yet powerful layer of security ensures your data is much safer from unauthorized access. However, when Single Sign-On (SSO) is enabled, 2FA will be replaced by SSO's authentication process.

To set up 2FA in FlowFuse, you’ll need to head over to **User Settings > Security > Two-Factor Authentication**. It’s as simple as clicking the "Enable Two-Factor Authentication" button, scanning the QR code displayed on the platform with your authenticator app, and then entering the code from your app back into FlowFuse. Once you've done that, 2FA will be up and running, adding that extra layer of security to your account!

![Two-Factor Authentication](https://flowfuse.com/blog/2024/10/images/2f-auth.png){dataZoomable=""}*Flowfuse: Two Factor Authentication*

## Granular Role-Based Access Management

With collaboration at its core, FlowFuse allows you to create teams and invite members to collaborate on projects. However, not all team members require access to every feature. Effective management is essential, as some members might feel overwhelmed by unnecessary options, and there's a risk of accidental changes being made by those who are unfamiliar with the configurations and settings.

To address this, FlowFuse offers [Role-Based Access Control (RBAC)](https://flowfuse.com/blog/2024/04/role-based-access-control-rbac-for-node-red-with-flowfuse/). When inviting team members, you can assign specific roles that provide the appropriate level of access for their work:

- **Owner**: Has full control over the team settings, applications, instances, and flows. Can invite users and change their roles.
- **Member**: Can access applications and instances and modify flows, but with limited permissions compared to the Owner. Cannot manage team, application, or instance settings or invite users.
- **Viewer**: Can view instances and flows but cannot make any changes. Ideal for users who need to monitor without editing capabilities.
- **Dashboard Only**: Restricted to accessing the dashboard or HTTP endpoint. This role is for users who only need to monitor status without making any changes.

![Role Base Accesss control](https://flowfuse.com/blog/2024/10/images/rbac.png){dataZoomable=""}*Flowfuse: Role Base Accesss control*

Additionally, you can later change the roles of team members in the "members" page. This helps prevent unauthorized changes and ensures a more secure and efficient workflow.

### Comprehensive Activity Audit Logs

Today, many organizations prioritize a culture of openness and transparency, but security remains a top concern. Our **Audit Logs** feature supports this dual focus by maintaining a comprehensive record of all actions in the platform. These logs detail who made changes, what was changed, and when it occurred, ensuring accountability and enabling teams to quickly identify any unauthorized access or mistakes that could jeopardize security.

We provide audit logs at three different levels: **instance level**, where all action logs related to a specific instance are recorded; **application level**, which groups logs from instances created within a particular application; and **team level**, where all platform activities are documented but visible only to admins. This layered approach helps organizations maintain secure workflows and demonstrates their commitment to transparency, ensuring that security concerns are effectively addressed without sacrificing openness.

To access the audit logs:  

- For **instance-level logs**, choose the specific instance you want to see and go to **Audit Logs**.  

![Instance-level Audit Logs](https://flowfuse.com/blog/2024/10/images/instance-audit-logs.png){dataZoomable=""}*FlowFuse: Instance-level Audit Logs*

- For **application-level logs**, select the application you want to view and navigate to **Audit Logs**.

![Application-level Audit Logs](https://flowfuse.com/blog/2024/10/images/application-audit-logs.png){dataZoomable=""}*Flowfuse: Application-level Audit Logs*

- For **team-level logs*&#x2A;, there will be an option labeled &#x2A;*"Audit Logs"** in the left sidebar, accessible only to admins.

![Team-level Audit Logs](https://flowfuse.com/blog/2024/10/images/team-audit-logs.png){dataZoomable=""}*Flowfuse: Team-level Audit Logs*

For more information refer to the [Documentation](https://flowfuse.com/docs/user/logs/#audit-log)

### Instance Protection Mode

Imagine your Node-RED application running smoothly on the production line, seamlessly handling critical tasks and data flows. Now, picture the chaos that could ensue if someone from your team accidentally modified a flow. While we offer the [snapshot](https://flowfuse.com/blog/2024/09/node-red-version-control-with-snapshots/) feature to recover previous changes, accidental modifications may not be identified quickly. Even when they are discovered, and the snapshot is used to restore the previous state, it can still take seconds or even minutes to recover, resulting in costly downtime.

To prevent such scenarios, we provide a feature called **Instance Protection Mode**. This mode allows you to set flows within your Node-RED instances to read-only, ensuring that modifications can only occur through a [DevOps pipeline](https://flowfuse.com/blog/2024/10/how-to-build-automate-devops-pipelines-node-red-deployments/). This process guarantees that even the most critical flows can only be altered with thorough testing and approval.

![Option to Enable the Instance Protection Mode](https://flowfuse.com/blog/2024/10/images/instance-protection.png){dataZoomable=""}*Flowfuse: Option to Enable the Instance Protection Mode*

With Instance Protection Mode activated, team members can still view flows, but any attempts to modify them are blocked, providing an additional layer of security. This approach protects the integrity of your applications and fosters a controlled environment for making changes safely.

### Secure HTTP Nodes Endpoints

HTTP is one of the most widely used protocols for enabling communication between different applications and services. In Node-RED, you can quickly create these APIs using HTTP-In nodes, which allow for communication. However, while this convenience is excellent, ensuring that only authorized users can access your APIs is essential.

FlowFuse provides robust options for securing all HTTP endpoints served by Flow and the Node-RED Dashboard. To manage this, each instance has a dedicated interface that you can access by navigating to **your instance -> Settings -> Security**. Here, you’ll find several options for securing your APIs:

![Options to enable authentication for the HTTP endpoints created in the Node-RED instance](https://flowfuse.com/blog/2024/10/images/http-api-auth.png){dataZoomable=""}&#x2A;Flowfuse: Options to enable authentication for the HTTP endpoints created in the Node-RED instance.*

1. **None (Default)**: No authentication is enabled by default, which means anyone can access your endpoints.
2. **Basic Authentication**: By selecting this option, two input fields will appear where you can enter a username and password. This ensures that only users with the correct credentials can access your APIs.
3. **FlowFuse User Authentication**: This option allows all team members to use their unique usernames and passwords when requesting API.
4. **Bearer Tokens**: For more advanced users, there’s an option to generate bearer tokens for secure API access without needing to send usernames and passwords. With this feature, you can also set expiration times for these tokens, ensuring that access is time-limited and reducing the risk of unauthorized use. To use bearer tokens, you must first enable **FlowFuse User Authentication**.

For more information, refer to [HTTP Authentication in Node-RED with FlowFuse](https://flowfuse.com/blog/2024/03/http-authentication-node-red-with-flowfuse/).

With these features, FlowFuse gives you complete control over who can access your APIs created in the Node-RED instance.

### API Token Management for Secure Platform Interactions

We understand that organizations need to create integrations for automation, monitoring, and efficient workflows. FlowFuse provides REST APIs that allow easy interaction with various platform parts, including users, instances, teams, devices, and more. However, security settings are protected to ensure they can only be updated by admins or authorized team members directly on the platform, not via APIs.

![Options to generate bearer tokens for secure API access](https://flowfuse.com/blog/2024/10/images/genrate-token-for-platform-api.png){dataZoomable=""}&#x2A;FlowFuse: Interface for generating bearer tokens to ensure secure interactions with the platform APIs.*

Protecting against unauthorized access is crucial, especially since you control and monitor your entire factory and production lines through this platform. To safeguard this, we offer an interface similar to the one used for bearer tokens. You can access this by navigating to **User Settings > Security > Tokens**.

For more information, refer to the [FlowFuse Platform API docs](https://flowfuse.com/docs/api/).

## Software Bills of Materials

Node-RED is an open-source platform maintained by dedicated community members who ensure it operates smoothly and remains free of security vulnerabilities. Similarly, there exists a vast ecosystem of open-source packages, nodes, and libraries that we frequently use in our projects. While these packages are often excellent and enhance our capabilities, some may need a regular team or individual to update and monitor them. This can lead to potential risks, as outdated or unmaintained packages can introduce vulnerabilities into our applications.

To address these concerns, we recently introduced the Software Bill of Materials (SBOM) feature, which adds an extra layer of security and compliance. An SBOM is a detailed list of all an application's components. It provides a comprehensive view of all third-party libraries used in each application instance and their latest versions. This allows teams to monitor dependencies and make informed decisions about upgrades, ensuring effective dependency management and enhanced resilience against security threats.

![Software Bills of Materials](https://flowfuse.com/blog/2024/10/images/sbom.png){dataZoomable=""}*FlowFuse: Software Bills of Materials Inteface*

For more information, refer to the [Article on FlowFuse Software Bills of Materials](https://flowfuse.com/blog/2024/10/exploring-flowfuse-sbom-feature/).

In conclusion, FlowFuse offers a comprehensive suite of security features designed to empower you with the tools to protect your Node-RED applications effectively. Understanding and utilizing these security features will help you maintain a secure and efficient environment for your Node-RED applications. With FlowFuse, you can confidently safeguard your deployments, ensuring robust protection against unauthorized access while enhancing collaboration within your team.


# FlowFuse 2.10: MQTT Broker, Improved Version Control & More!

With FlowFuse 2.10 we've added some new major features, as well as improvements across the board for FlowFuse users.

Most notably, FlowFuse now offers it's own MQTT service, with the option to create MQTT client credentials for your teams, making it even easier and quicker to build your full-stack Node-RED applications.

## MQTT Broker

This is a significant milestone for FlowFuse, as we're now offering our own MQTT service. We have listened to a lot of feedback from users and prospective customers, and this has consistently been a regularly requested offering, and so we are delighted to announce that this is now live on FlowFuse Cloud for our Enterprise teams.

![Screenshot of the UI to manage your MQTT clients](https://flowfuse.com/blog/2024/10/images/screenshot-mqtt-client-config.png){dataZoomable=""}

This feature allows you to run and manage your own MQTT Clients alongside your Node-RED instances, making it easier to build full-stack applications within FlowFuse.

### Pricing

From today, Enterprise teams on FlowFuse Cloud will be able to create up to 20 clients on their accounts at **no extra cost**.

In the near future, users will then be able to purchase additional packs of clients to add to their team.

Self-hosted Enterprise customers will be able to make use of this feature in our next release.

## Version History - Visual Timeline

Since early iterations of FlowFuse, Snapshots have played a key role in Version Control for your Node-RED flows, environment variables and settings. Whilst we still offer the same "Snapshots" view in the application, we've also added a new view to give a clearer picture of what flows are running on your Node-RED instances and *when*.

![Screenshot showing an Instance's visual timeline](https://flowfuse.com/blog/2024/10/images/screenshot-visual-timeline.png){dataZoomable=""}

In this view, you can see every time a new set of flows were deployed to your Node-RED instance, no matter the source, whether that's from the Editor itself, via our [DevOps Pipelines](https://flowfuse.com/docs/user/devops-pipelines/), or restoring a Snapshot.

## Device Group Environment Variables

We've also added in the ability to define common environment variables in your Device Groups.

![Screenshot showing the new Device Group Environment Variables](https://flowfuse.com/changelog/2024/10/images/device-group--with-env-vars.png){dataZoomable=""}

These will now be deployed to any devices contained within a given group, and can still be overridden by environment variables defined in the Device's settings directly.

See the [Device Group documentation](https://flowfuse.com/docs/user/device-groups/) for more information on how to set environment variables for your device groups.

## And Much More...

For a full list of everything that went into our 2.10 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.10.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try FlowFuse

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.

## Upgrading FlowFuse

If you're using \[FlowFuse Cloud]\({{ site.appURL }}), then there is nothing you need to do - it's already running 2.10, and you may have already been playing with the new features.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

If you have an Enterprise license please make sure to review this [changelog entry](https://flowfuse.com/changelog/2024/08/enterprise-license-update)

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go to the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# Creating and Automating DevOps Pipelines for Node-RED in Industrial Environments

When deploying any update in your manufacturing or automotive process, it is important to perform testing and validation. The smallest errors can lead to a production outage. In such cases, having a quick and reliable deployment process is essential for maximising uptime and minimising downtime.

For developers using Node-RED, setting up a comprehensive DevOps pipeline can make all the difference. In this blog, we’ll explore how to build and automate DevOps pipelines specifically for Node-RED deployments. You’ll discover practical tips and tools to streamline your process, ensuring your applications are always ready to support your operations.

## What Exactly is a DevOps Pipeline?

![Image showing the DevOps Lifecycle](https://flowfuse.com/blog/2024/10/images/What-is-DevOps.png){dataZoomable=""}*The DevOps Lifecycle illustrating the stages of development through to production*

A DevOps pipeline is an process that helps developers move their code from development to production smoothly. In a pipeline, each step depends on the one before it, ensuring every update is properly tested and ready for use. The most common stages of a pipeline are:

1. **Development:** This is where the application flows are created. A level of testing and checking is carried out as a natural step of the development.
2. **Staging/Testing:** In this stage, the code is deployed to a staging environment that closely mimics the live system. Here, the application goes through a level of QA and is tested in scenarios as close to real-world conditions as possible. This is stage designed to catch any issues that slipped through in the development stage.
3. **Production:** When the flows are tested and confirmed in staging and are ready to be deployed, this stage can be operated to promote the flows to production.

## How to Create DevOps Pipelines for Node-RED Deployments

Creating DevOps pipelines manually for your Node-RED deployments can be time-consuming, expensive, and require considerable technical expertise. **FlowFuse** simplifies the creation of DevOps pipelines for Node-RED deployments.

[FlowFuse](https://flowfuse.com) enhances collaboration, security, and scalability for your Node-RED applications, making the deployment and management of edge devices seamless. With a centralized platform and an intuitive visual interface, FlowFuse allows you to connect, collect, transform, and visualize data effortlessly.

### Steps to Create a DevOps Pipeline:

1. Go to the **FlowFuse platform** and navigate to the application where your Node-RED instances are located. Ensure you have instances set up for all stages, including production devices or instances.
2. Switch to the **DevOps Pipelines** option from the top menu.

![Image showing option to switch to DevOps pipelines tab from top menu](https://flowfuse.com/blog/2024/10/images/devops-pipeline-option-in-apps.png){dataZoomable=""}*Image showing option to switch to DevOps pipelines tab from top menu*

3. Click the **Add Pipeline** button in the top right corner to create the pipeline.

![Screenshot of the FlowFuse dashboard with the 'Add Pipeline' button highlighted at the top-right corner](https://flowfuse.com/blog/2024/10/images/add-pipeline-button.png){dataZoomable=""}*Click the 'Add Pipeline' button to start creating your DevOps pipeline in FlowFuse*

4. Enter the name for your pipeline and click **Create Pipeline**.

![Screenshot of the pipeline creation form in FlowFuse, showing fields to enter the pipeline's name](https://flowfuse.com/blog/2024/10/images/form-to-create-pipeline.png){dataZoomable=""}*Fill out the form to give your pipeline a name*

5. Next, you'll see an option to create stages by clicking **Add Stage**.

![Screenshot highlighting the button to add stages within a DevOps pipeline in FlowFuse.](https://flowfuse.com/blog/2024/10/images/button-to-add-stages.png){dataZoomable=""}*Add stages to your pipeline for different deployment environments, such as development, testing, and production*

6. In the window that opens, select the **stage type** based on whether it's an instance, device, or device group.
7. Enter the name for the stage in the **Stage Name** field.
8. Choose an instance, device, or device group for the stage.
9. Next, configure which action should be performed when this stage is pushed to the next:
   - **Create New Snapshot:** Generates a new [Snapshot](https://flowfuse.com/docs/user/high-availability/) using the current flows and settings.
   - **Use Latest Instance Snapshot:** Uses the most recent existing snapshot of the instance. The deployment will fail if no snapshot exists.
   - **Prompt to Select Snapshot:** Prompts at deploy time to select which snapshot from the source stage should be copied to the next stage.
10. Check the option **Deploy to Devices** if you want changes to be deployed to all devices connected to this stage’s instance when the stage is deployed.

![Screenshot showing the stage configuration form with options to select instance types and configure actions.](https://flowfuse.com/blog/2024/10/images/form-to-create-configure-stages.png){dataZoomable=""}*Configure each stage by selecting an instance, device, or device group, and define the deployment actions*

Once you’ve created your initial stage, you can add more stages by following the same process. This flexibility allows you to tailor your DevOps pipeline to meet the specific needs of your Node-RED deployment.

For example, in development, you might have a Node-RED instance in the cloud to build your application. During staging, you could test the setup with a single device. Finally, in production, you can deploy the tested application to thousands of devices in a device group, saving time and ensuring smooth deployment at scale.

:video{ariaLabel="DevOps pipelines animation" autoPlay="true" height="449" loop="true" muted="true" playsInline="true" preload="none" width="800"}&#x2A;Video: DevOps animation demonstrating pipeline deployments.*

## Running a Pipeline Stage

Once your pipeline is set up, you can run it to deploy your changes across each stage. Here's how:

![Screenshot of the 'Run Pipeline' button in FlowFuse, allowing users to trigger the deployment process.](https://flowfuse.com/blog/2024/10/images/button-to-run-pipeline.png){dataZoomable=""}&#x2A;Click the 'Run Pipeline' button to initiate a pipeline deployment.*

1. Click the "Run Pipeline" button for the current stage to start the deployment. This button is available for all stages except the last one.
2. After clicking, the deployment automatically progresses to the next stage on the right. Since each pair of stages operates independently, you need to click the "Run" button for each stage to continue the deployment.

Pressing the "Run Pipeline" button for the current stage creates a new snapshot that includes all settings, environment variables, and flows for that stage. This snapshot is then copied and deployed to the next stage, but any existing environment variable keys in the target stage will remain unchanged.

When creating a pipeline, you can include only one Device Group, and it must be in the final stage. This ensures all changes are fully tested and verified before reaching production, guaranteeing a safe and reliable deployment.

## Conclusion

DevOps pipelines formalize deployment patterns, standardize testing, and streamline updates, minimizing errors and downtime. This clear process improves reliability and helps organizations adapt more easily thus ensuring smooth operation of critical applications in manufacturing and automotive environments.


# Transform Chaos into Control: Centralize Node-RED Management with FlowFuse

Managing a single Node-RED instance involves setting up and configuring a server, securely tunneling for remote access to edge devices, and ensuring proper networking and firewall configurations, all of which can be complex. The complexity increases when overseeing multiple Node-RED instances spread across various projects, edge devices, or environments.

This situation brings additional challenges that can make management a really difficult task, often leading to confusion and frustration as teams try to keep everything running smoothly, troubleshoot issues, and ensure clear communication between instances. Consolidating control into a single platform simplifies deployment, configuration, collaboration, and oversight, making it easier to manage multiple Node-RED instances. Let’s explore how FlowFuse can centralize this management.

## What is a Node-RED Instance?

A [Node-RED](https://flowfuse.com/node-red/) instance refers to a single, operational setup of the Node-RED application. Whether you start Node-RED on your computer, a cloud server, or an edge device, you create an instance. Each instance operates independently, allowing you to build and run automation flows or applications.

## What are the Challenges of Managing Multiple Node-RED Instances?

Managing multiple Node-RED instances can quickly become complicated as operations grow. Each new instance adds complexity, from configuration issues to security concerns. These challenges highlight the need for a centralized solution to simplify management and improve efficiency.

1. **Deployment and Configuration Management:** Setting up Node-RED instances on a server requires technical knowledge and ongoing maintenance. As the number of instances grows, maintaining them can become time-consuming and resource-intensive.
2. **Egde Node-RED Management:** Managing Node-RED instances on edge devices introduces additional challenges, such as the need for on-site troubleshooting when issues arise.
3. **Monitoring and Troubleshooting:** Keeping track of the health and performance of multiple instances requires constant attention. Checking logs across different instances can become overwhelming.
4. **Security Management:** Each instance requires its own security settings. Ensuring that all instances are secure and up to date can be a difficult task, especially as the number of instances increases.
5. **Backup and Recovery:** Having a solid backup and recovery plan is critical. If a system crashes, you need a way to quickly restore it without losing important data.
6. **Scaling:** As applications grow in complexity, scaling Node-RED instances becomes necessary. This requires expertise in server management and the ability to handle multiple instances efficiently.
7. **Ensuring High Availability:** In production environments, keeping all Node-RED instances running smoothly and avoiding downtime is essential which also requires high technical exepertise

A centralized platform is essential to handle deployment, configuration, and management efficiently, providing a visual interface to maintain and update instances.

> "As organizations navigate the complexities of the digital age, adopting a holistic approach that integrates technology, processes, and people is essential for reaping the full benefits of IoT."

## FlowFuse: Centralize Your Node-RED and IoT Device Management

FlowFuse is a powerful platform designed to simplify the management of multiple Node-RED instances. By providing a centralized interface, FlowFuse enables users to manage, scale, secure, and collaborate on Node-RED solutions.

![Centralized Node-RED Management](https://flowfuse.com/blog/2024/10/images/instances.png):br&#x2A;Image showing how multiple Node-RED instances are organized and managed under one roof.*

With FlowFuse, you can organize your Node-RED instances into teams for improved collaboration, allowing seamless teamwork on projects without the need to navigate between different instance locations physically. You can create as many teams as needed, ensuring that instances are organized based on the team members assigned to them. Additionally, you can ensure that each member has the correct permissions they require through role-based access control (RBAC), providing precise management of access and responsibilities.

![Immersive Editor](https://flowfuse.com/blog/2024/10/images/imersive-editor.png):br&#x2A;Image showing how FlowFuse's immersive editor simplifies managing settings and configuration within the Node-RED editor.*

FlowFuse also simplifies the [monitoring and controlling of edge devices](https://flowfuse.com/use-cases/edge-connectivity/) through the [FlowFuse Device Agent](https://flowfuse.com/platform/device-agent/), which quickly connects your devices to the cloud platform and allows you to build and monitor applications remotely.

![Device Management](https://flowfuse.com/blog/2024/10/images/devices.png):br&#x2A;Image showing remote edge devices connected through the FlowFuse platform for remote monitoring and control.*

Additionally, FlowFuse enables the creation of [DevOps pipelines](https://flowfuse.com/blog/2024/10/how-to-build-automate-devops-pipelines-node-red-deployments/) that ensure your application is well-tested and evaluated before deployment to production. Deploying the same flow to hundreds or thousands of devices becomes effortless with these pipelines.

![Devops Pipeline](https://flowfuse.com/blog/2024/10/images/devops.png):br*Image showing feature to create the devops pipeline for Node-RED instances*

You can efficiently [monitor logs](https://flowfuse.com/docs/user/logs/#logs) for each instance and receive instant email alerts if any crashes occur, facilitating quick troubleshooting.

![Logs](https://flowfuse.com/blog/2024/10/images/log.png):br&#x2A;Image showing the Node-RED instance logs.*

FlowFuse also allows you to quickly add [high availability](https://flowfuse.com/docs/user/high-availability/) features to your instances, ensuring smooth and efficient operation of your production applications. The platform includes an auto-snapshot feature that lets you recover from accidental changes to flows, ensuring you always have a backup of your application.

![High availability](https://flowfuse.com/blog/2024/10/images/high-availablity.png):br*Image showing the feature that allows to enable high availability for instances*

![Snapshots](https://flowfuse.com/blog/2024/10/images/snapshots.png):br*Image showing snapshots feature*

We have highlighted just a few features of FlowFuse; there are many more, potentially three to four times what has been presented, and the team is continuously working to develop and introduce new functionalities to improve collaboration, scalability, security, and overall performance.

### How FlowFuse Transforms Production Operations

In manufacturing, downtime is costly, and managing machines, sensors, and systems across multiple sites can be complex. FlowFuse simplifies this by centralizing management, giving you a single platform to oversee all your Node-RED instances efficiently.

With its intuitive interface, FlowFuse handles deployments, updates, and real-time monitoring, ensuring smooth production. It collects data from hardware, APIs, and services using a drag-and-drop interface, enabling teams to easily connect, transform, and analyze data. The high-availability feature ensures critical operations continue even during failures, minimizing downtime.

FlowFuse also enhances security with advanced settings, keeping your systems safe while boosting collaboration. As operations grow, FlowFuse scales seamlessly, integrating new devices and systems without added complexity.

By simplifying system management, FlowFuse cuts costs, keeps production running smoothly, and lets your team focus on growth and innovation.

## Conclusion

FlowFuse transforms how you manage Node-RED instances, turning chaos into clarity. With centralized control, teams can collaborate and reduce operational costs while ensuring critical applications remain available and secure. Automated backups and high availability translate to less downtime and more focus on innovation.


# Exploring Quick Ways to Write Complex Logic in Function Nodes in Node-RED

Node-RED is a powerful tool for building automation flows through its visual interface and low-code nodes. However, there are times when this low-code approach falls short, particularly when you need to implement complex JavaScript logic. That’s where the Function Node comes into play. Many Node-RED developers excel in their domains, such as IoT integration and PLCs, but may lack a strong foundation in JavaScript.

In this guide, I will share strategies for making writing in Function Nodes straightforward and efficient. You’ll learn how to leverage JavaScript's capabilities without needing extensive knowledge, empowering you to handle more complex logic with confidence and ease.

## What are function nodes and the challenges related to them?

![Image showing the function node](https://flowfuse.com/blog/2024/10/images/node_function.png){dataZoomable=""}*Image showing the function node*

## What Are Function Nodes and Common Challenges?

[Function Nodes](https://flowfuse.com/node-red/core-nodes/function/) in Node-RED allow you to write custom JavaScript for processing messages. While they provide flexibility, many users find it challenging to turn complex business rules into code and manage variables. For more details on the benefits and drawbacks of using Function Nodes, refer to this [Article](https://flowfuse.com/blog/2023/03/why-should-you-use-node-red-function-nodes/).

Before using Function Nodes, consider if existing low-code nodes can fulfill your needs. Using standard low-code nodes can simplify your approach and enhance collaboration and clarity. If you still feel the need to use Function Nodes, don’t worry, In the following section, we’ll explore straightforward strategies to make working with Function Nodes easier.

## Quick Ways to Simplify Writing in Function Nodes

### Using Blockly-Based Function Nodes

For users seeking to simplify the process of writing complex logic, Blockly-based Function Nodes serve as a valuable tool within Node-RED. Designed to facilitate JavaScript code generation, Blockly allows you to construct logic visually using a drag-and-drop interface with pre-defined blocks. This makes it easier to translate intricate business rules into functional code. As you build your logic, Blockly automatically generates the corresponding JavaScript.

Before proceeding, make sure you have installed the following Node-RED package via the palette manager:

- **node-red-contrib-blockly**: This package adds the Blockly custom node in your Node-RED sidebar to use.

For the demonstration, let's consider we have an array of temperatures, and we wanted to calculate the Upper Control Limit (UCL) and Lower Control Limit (LCL) to send to different outputs.

1. Drag the Blockly node onto the canvas and double-click it to open the editor.
2. Once open, you will see the block categories on the left side, a plain canvas on the right side, and an option to set output and timeout at the bottom. Set the output to 2.
3. In the left sidebar, you’ll find different categories starting with Node-RED, each containing related operation blocks. For example, in Node-RED, you’ll find blocks to get the value of `msg.payload`, set `msg.payload`, and more. In the Math category, there are various blocks for different mathematical operations.
4. We must first calculate the mean to calculate UCL and LCL. Switch to the Math category and drag the block labeled "`sum` of the list." Click on the sum in the block to see other options; select "average" from it. Then, in the Node-RED category, find the block labeled "get the `msg` property from `payload`" and connect it to the end of the "`sum` of the list" block. Now, to create a variable to store the mean, switch to the Variables category, click "create variable," and name it `mean`. Once you make the variable, you’ll get different blocks related to its perform operations on that var, such as setting and changing its value. Drag the block labeled "set to mean" and place it at the start of the "`average` of list" block.
5. Next, we know the formulas to calculate UCL and LCL (where we pick z = 3):

- UCL = mean + (stdDev \* z)
- LCL = mean - (stdDev \* z)
     

7. To calculate the standard deviation, switch to the Math category and drag the "`sum` of the list" block again. Click on the sum and select the "standard deviation" option. Again, drag the block "get the `msg` property from `payload`" and connect it to the end of the standard deviation block. Create a variable called `stdDev,` drag the "set stdDev to" block, and place it at the start of the "`standard deviation` of the list" block.
8. Now, it’s time to calculate UCL and LCL. First, create a variable for UCL and then Drag the "set UCL to" block, then switch to the Math category and drag the "1 + 1" block. Place the `mean` variable in one of the positions for "1." Drag the same block again and place it in the second position of 1, then switch to Variables again and drag the `stdDev` variable to replace one of the "1s" in the second 1+1 block, and set the second "1" to 3.
9. Next, switch to Node-RED and drag the "set `msg` property `payload` to" block. Then, drag the UCL from the variable and place it in place of "to." s value, Drag the "send "`msg` block to output 1". Repeat the same steps for LCL, but make sure that you subtract from the mean (`stdDev * z`) and set LCL to the payload, returning it to output 2.
10. Finally, click Done to save it.
11. Drag the inject node, having set the payload to an array of simulated temperature data, and connect its output to the input of the blockly node,
12. Then, drag the two debug nodes onto the canvas. Connect one debug node to output 1 of the Blockly node (this will display the UCL) and the other debug node to output 2 (this will display the LCL).
13. Deploy the flow and click the inject button. You will see both UCL and LCL printed on the debug panel

The final blockly canvas should look like the below image:

![Image showing collection of blockly blocks that are calculating UCL and LCL](https://flowfuse.com/blog/2024/10/images/blockly.png){dataZoomable=""}*Image showing collection of blockly blocks that are calculating UCL and LCL*

Using Blockly-based Function Nodes simplifies the creation of complex logic in Node-RED. However, a basic understanding of JavaScript is still beneficial, especially as your logic becomes more complicated. While beginners may appreciate the visual interface initially, it can become confusing when trying to implement more advanced features. Additionally, the Blockly Function Node is a modified version of the original Function Node, which may lead to differences in behavior and functionality. Nevertheless, it remains a valuable node for users looking to simplify writing function logics in Node-RED.

### Using FlowFuse Expert

:video{ariaLabel="Video showing the quick function node generation with FlowFuse Expert" autoPlay="true" height="1574" loop="true" muted="true" playsInline="true" preload="none" width="2992"}*Video showing the quick function node generation with FlowFuse Expert*

The FlowFuse Expert is an AI-based plugin integrated into the FlowFuse platform within the Node-RED editor, making it incredibly easy to generate complex functions using prompts.

For this example, let’s use the same logic we demonstrated with Blockly:

Before proceeding, ensure you have updated Node-RED to the latest version on the FlowFuse platform.

1. Open the Node-RED instance editor on the platform.
2. Click the magic button in the top right corner.
3. A popup prompt will appear, asking for your input to generate the function node.
4. Enter the prompt for your logic. For this example, you can use:
   > "Generate JavaScript code that takes an array of numbers, calculates the Upper Control Limit (UCL) and Lower Control Limit (LCL), then sends UCL to the first output of the function node and LCL to the second output."
5. Click "Generate." After 2-3 seconds, the Function Node with the requested JavaScript code will appear directly on your canvas.
6. To test it, connect an inject node containing an array of simulated temperature data, then drag two debug nodes onto the canvas. Connect one debug node to output 1 of the function node (this will display the UCL) and the other debug node to output 2 (this will display the LCL).
7. Deploy the flow and click the inject button; both UCL and LCL will be displayed on the debug panel.

Using the FlowFuse Expert is significantly easier than Blockly, as it streamlines the process and saves you valuable time. You can articulate your goals in plain English or other languages, such as Spanish or Dutch, and the assistant generates your Function Node seamlessly. This allows you to focus more on your project objectives rather than getting bogged down in coding or block arrangements. Additionally, it provides you with the original Function Node, maintaining standard functionality.

## Conclusion

In summary, both Blockly and FlowFuse Expert simplify writing complex logic in Node-RED, but FlowFuse is easier to use. Blockly’s visual approach can be confusing, while FlowFuse allows you to generate code by stating your goals in plain English or other languages. Although Blockly can be helpful, it often requires JavaScript knowledge. FlowFuse Expert simplifies the process, allowing you to focus on your project.


# Building a Unified Namespace (UNS) with FlowFuse

As systems and devices become more connected, managing data from different sources can be tricky. A [Unified Namespace (UNS)](https://flowfuse.com/use-cases/uns/) solves this by centralizing all your data in one place, making it easy to access and use.

[FlowFuse](https://flowfuse.com) makes building a UNS simple. It connects old and new systems, collects data from devices and applications, and streamlines workflows. With tools like Node-RED for data flow, MQTT for real-time updates, and a central management layer, FlowFuse helps you improve efficiency and make better decisions.

This article will show you how to build your UNS using FlowFuse, step by step.

## Building a UNS with Real-Time Sensor Data

This section explains how to set up a Unified Namespace (UNS) using FlowFuse, a Raspberry Pi, and an ADXL345 sensor. The Raspberry Pi collects data from the sensor, which we collect and process in Node-RED, calculate vibration magnitude, format it, and send it to the UNS using standardized topic names.

### Step 1: Collect Metrics from Devices

The first step in building your UNS is collecting data from your devices. The method you choose will depend on the type of device and the communication protocol it supports. For example, many devices use traditional communication standards like Modbus, while others, such as industrial controllers, might rely on OPC-UA.

Fortunately, Node-RED provides support for a wide range of industrial protocols, from legacy to modern ones. While older protocols like Modbus and OPC-UA were originally designed for machine-to-machine (M2M) communication and are not directly compatible with cloud systems, Node-RED acts as a bridge to overcome this limitation.

By leveraging Node-RED, you can collect data from these legacy systems, process and transform the data using low-code workflows, and then seamlessly send it to the cloud via modern protocols such as MQTT, Kafka, AMQP, and more.

In our example, Node-RED can directly collect metrics from sensor using [I2C](https://flows.nodered.org/node/node-red-contrib-i2c){rel="&#x22;nofollow&#x22;"} on the Raspberry Pi. This approach simplifies the process by eliminating the need for additional communication layers. To run Node-RED on the Raspberry Pi, we use [FlowFuse Device Agent](https://flowfuse.com/platform/device-agent/), This agent enables you to remotely monitor, manage, and build Node-RED flows securely through the FlowFuse platform remotely. [See here](https://flowfuse.com/node-red/hardware/) for more details on how to set up and run FlowFuse Device Agent on different devices.

### Step 2: Transform and Process the Collected metrics

Once you've collected data from your devices, the next step is to transform it using Node-RED. Industrial systems often use different protocols such as Modbus and OPC UA, and each might have its own data structure, which can create challenges for integration. For example, the ADXL345 sensor which we are uisng in our practile example outputs raw data as electrical signals (buffer data). We first need to format it into a human-readable format and then calculate the Magnitude, a standard vibration monitoring unit.

**Why Data Transformation Matters:**

- **Consistency**: Ensures data from different sources follows the same structure.
- **Integration**: It makes integrating data from various systems easier.
- **Speed**: Simplifies data access for faster insights and decision-making.

#### Example: Transforming Data from ADXL345 Sensor (Raspberry Pi)

Raw data from the ADXL345 sensor might look like this:

```json
[26,0,244,255,37,255]  
```

Using a [Function node](https://flowfuse.com/node-red/core-nodes/function/) in Node-RED, we can convert this into a human-readable format.

![Function node: Transforming Raw Data into Readable Format](https://flowfuse.com/blog/2024/11/images/function-node.png){dataZoomable=""}*Function node: Transforming Raw Data into Readable Format*

After transformation, the data will look as shown below.

```json
{
    "x":0.09765625,
    "y":-0.046875,
    "z":-0.8828125
}  
```

While this is more readable, it can still be challenging to monitor changes in vibration quickly or detect anomalies. To simplify monitoring, we can calculate the Magnitude, a single metric commonly used in vibration monitoring.

![Change node: Calculating Magnitude](https://flowfuse.com/blog/2024/11/images/change-node-calculating-magnitude.png){dataZoomable=""}*Change node: Calculating Magnitude*

After calculating the Magnitude using a [Change node](https://flowfuse.com/node-red/core-nodes/change/), the data might look like this:

```json
{
    "x":0.00390625,
    "y":-0.07421875,
    "z":-0.8515625,
    "magnitude":0.8547996098775871
}  
```

Now, the data is easier to monitor with a single metric (Magnitude), but this structure is still not optimal for a UNS. We need to transform it further to provide more context.

**Enhanced Data Structure for UNS:**

To make the data more useful for integration and interpretation in a UNS, we can transform it to include additional context, such as units and timestamps, while removing unnecessary metrics like the three-axis components (`x`, `y`, `z`). The easiest and most low-code approach for achieving this in Node-RED is to use the Change node, which is specifically designed for formatting and structuring payloads.

![Change Node: Formatting and structuring payload for UNS](https://flowfuse.com/blog/2024/11/images/change-node-structering-data.png){dataZoomable=""}*Change Node: Formatting and structuring payload for UNS*

After formatting, the data will look as shown below:

```json
{
  "name": "vibration",
  "timestamp": "2024-11-13T10:00:00Z",
  "unit": "m/s²",
  "value": 0.8547996098775871
}
```

This format is more structured and consistent, with important labels like `value`, `unit`, and `timestamp` that provide meaningful context. It clarifies that the value represents the Magnitude of vibration in **m/s²** and provides the precise time when the data was collected.

### Step 3: Setting Up Your UNS Broker

Now, it's time to configure your UNS broker. As mentioned, we’ll use the [FlowFuse MQTT Broker](https://flowfuse.com/blog/2024/10/announcement-mqtt-broker/). This broker is integrated within the FlowFuse platform to simplify your workflow by eliminating the need for multiple separate services. With FlowFuse, you can monitor and configure everything from a single, centralized platform. This ensures you can efficiently monitor, manage, and configure your UNS without juggling multiple tools or services.

**Steps to Set Up the FlowFuse MQTT Broker:**

1. Log in to the FlowFuse platform and navigate to &#x2A;*"Broker"** in the left sidebar.
2. Click the &#x2A;*"Create Client"** button at the top-right corner to add a new MQTT client.
3. **Configure the client**:
   - Provide a **Username** and **Password** for secure access.
   - Define an **Access Pattern** to manage client permissions.
4. Click &#x2A;*"Create"** to generate the client.

*Note: Enterprise-level teams can register up to 20 clients, and teams-level teams can register up to 5 clients as part of their plan. The ability to purchase additional packs of clients will come in a near future release.*

5. Copy the client ID you generated from the list and save it somewhere for later use.

![FlowFuse Interface for creating MQTT Client](https://flowfuse.com/blog/2024/11/images/creating-client-interface.png){dataZoomable=""}*FlowFuse Interface for creating MQTT Client*

### Step 4: Choosing Your Topic Naming Convention

The key to building a successful UNS is organizing your data with a clear and consistent naming convention. A well-designed convention ensures data is accessible and understandable across systems and users, simplifying communication and integration.

**ISA-95** is a standard for industrial systems encompassing various manufacturing and communication aspects. However, when it comes to communication, ISA-95 often relies on point-to-point (P2P) connections between systems and devices. These connections can introduce complexity, delays, and other challenges.

While we are building a UNS to address the problems and limitations we observed with point-to-point communication, we can still leverage key elements of ISA-95 that remain valuable for improving production efficiency. One of the central aspects of ISA-95 is its equipment hierarchical model, which links various layers of a factory, from physical devices to enterprise systems. By adapting this model to your data architecture, you can simplify data access and management across the entire system.

![ISA-95 : Equipment Hierarchical Model](https://flowfuse.com/blog/2024/11/images/isa-95-equipement-model.png){dataZoomable=""}*ISA-95 : Equipment Hierarchical Model*

For example, following an ISA-95-based equipment hierarchy to define your topic naming convention allows you to access data from devices, sensors, or any other source without knowing their specific addresses or tags, such as for a PLC. With clarity and ease, this logical structure enables you to retrieve relevant information from different system layers (e.g., from control systems to MES or ERP).

Example topic structure based on ISA-95 equipment model hierarchy:

`Plant1/Area3/Line4/Cell2/DeviceA`

`Plant1/Area4/Line5/Cell6/DeviceB`

You can also use the [**Sparkplug B**](https://flowfuse.com/blog/2024/08/using-mqtt-sparkplugb-with-node-red/) naming convention for MQTT topics, which offers a structured hierarchy and standard. However, the Sparkplug B convention has some limitations in terms of flexibility. A typical **Sparkplug B topic** follows this structure:

`spBv1.0/{groupID}/{edgeNodeID}/{deviceID}/{messageType}`

While Sparkplug B provides a standardized topic model, its hierarchy may not always suit the specific needs of your architecture. Alternative methods, such as the Paris and Schultz models, help address these limitations with Sparkplug B topics. However, to keep things simple and avoid unnecessary complexity, we will use plain MQTT with the ISA-95 hierarchy.

### Step 5: Sending Collected metrics to UNS

With your topic naming convention chosen, it’s time to send the data to the UNS. In Node-RED, we will use the [MQTT Out](https://flowfuse.com/node-red/core-nodes/mqtt-in/) node to send the transformed data to the broker.

1. Drag an MQTT out node into your flow.
2. Configure the node to connect to the FlowFuse MQTT Broker using the client credentials generated earlier.

**Note**: Use environment variables to secure configuration and prevent exposing credentials when sharing flows. This ensures that sensitive data remains secure and allows easy sharing without compromising security. For more details, refer to the [Article: Using Environment Variables in Node-RED](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/).

![Configuring mqtt-broker-config node](https://flowfuse.com/blog/2024/11/images/mqtt-broker-node-config.png){dataZoomable=""}*Configuring mqtt-broker-config node*

!\[Configuring mqtt-broker-config node]\(./images/mqtt-broker-config-security
.png){data-zoomable}
*Configuring mqtt-broker-config node*

3. Set the **topic** using your predefined naming convention (e.g., `Plant1/Area3/Line4/Cell2/RPI1`).

![Configuring mqtt-out node](https://flowfuse.com/blog/2024/11/images/mqtt-out-node-config.png){dataZoomable=""}*Configuring mqtt-out node*

4. Connect the input of the mqtt out node to your data transformation flow and deploy the flow.

For information on how to use MQTT with Node-RED, refer to [Using MQTT with Node-RED](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/)

After deploying, you can monitor the topic hierarchy on the FlowFuse platform by switching to the "Hierarchy" tab in the Broker interface.

![Monitoring your mqtt topic hierarchy within FlowFuse](https://flowfuse.com/blog/2024/11/images/topic-hierarchy.png){dataZoomable=""}*Monitoring your mqtt topic hierarchy within FlowFuse*

Once your data is in the UNS, you have a centralized, real-time view of your operations. This unified structure enables easier access, sharing, and analysis of data across systems, helping you drive better decisions, improve efficiency, and gain valuable insights to optimize your processes.

With real-time data access, you can create monitoring dashboards using the [FlowFuse Dashboard](https://flowfuse.com/platform/dashboard/) with a low-code approach, integrate with other cloud solutions, or leverage it further for enhanced analytics or automation.

![FlowFuse Dashboard Monitoring Vibrations](https://flowfuse.com/blog/2024/11/images/flowfuse-dashboard.png){dataZoomable=""}*FlowFuse Dashboard Monitoring Vibrations*

## Conclusion

FlowFuse makes building a Unified Namespace (UNS) easy by centralizing data from systems, devices, and sensors. With seamless integration of Node-RED, MQTT, and its enterprise layer, FlowFuse ensures smooth data flow, real-time insights, and efficient management. It simplifies operations, enhances productivity, and improves system interoperability, making it easy to adapt your UNS to specific needs and support real-time analytics and automation.


# Visual Layout Editor - Now Available in Dashboard

It has been one of the most requested features for FlowFuse Dashboard, and is now available in its first iteration. It is now possible to resize and move groups in the Dashboard itself using the new "Edit Layout" feature. That's not all though, we've added a new "Spacer" widget to assist with layouts, added improvements to the rendering of charts and plenty more.

## Layout Editor - Quick Guide

For those transitioning over from the original Node-RED Dashboard 1.0, you'll notice some difference in how you can now edit the layout of your dashboard. Now, the editing is done directly in the Dashboard itself, rather than in the Node-RED editor.

To open the Dashboard in "Edit Mode", click the "Edit Layout" button for the relevant page in the Dashboard sidebar:

![Screenshot showing the Edit Layout button in the Dashboard sidebar](https://flowfuse.com/blog/2024/11/images/edit-layout-button.png){dataZoomable=""}{width="500px"}
*Screenshot to show the buttons available to "Edit Layout" for a given page*

This will open the relevant page in "Edit Mode":

:video{ariaLabel="Short recording to show resizing and reordering in the visual layout editor" autoPlay="true" height="459" loop="true" muted="true" playsInline="true" preload="none" width="800"}*Short recording to show resizing and reordering in the visual layout editor*

The three controls at the top of the page are:

- **Save Changes:** Deploy any changes to the underlying Node-RED flow.
- **Discard Changes:** Clear any in-browser changes that have not yet been saved.
- **Exit Edit Mode:** Stop "Edit Mode" and interact with teh Dashboard as a standard end-user.

You can then use the handles on each group to resize them, or click and drag to re-position the groups on the page. How this re-positioning is done is controlled by the "Layout" property of the page. The Visual Editor is currently available for "Grid" and "Fixed" layouts only.

Once you're happy with your changes clicked the "Save Changes" button to deploy them to the underlying Node-RED flow. Note, you will then be made aware that &#x2A;"your flows have been updated"* by Dashboard when you return to your Node-RED Editor.

Note that you can only enter "Edit Mode" via the Node-RED Editor, this is to ensure security and stability of your Dashboard, in cases where you may have users for your Dashboard that should not have access to modify your Dashboard's layout.

## Layout Editor - Next Steps

We are very aware that is this is just the first iteration of the Layout Editor, and we have plenty of plans to improve it further. Here are some of the features we are considering for future releases:

- Include widget resizing and ordering in the Layout Editor
- Overhauling sizing options for groups and widgets [#835](https://github.com/FlowFuse/node-red-dashboard/issues/835){rel="&#x22;nofollow&#x22;"}

If there are any other key editor features you'd like to see, then please do reach out to us, open GitHub issues and help us shape the future of FlowFuse Dashboard.

## New Widget: UI Spacer

In the Dashboard sidebar, you now have the option to add a "Spacer", this is just an empty widget that can be used to shift the position of other widgets. This can be useful for creating more complex layouts, or for adding space between widgets. For example, if you wanted to have some directional controls with up/down/left/right buttons, you could use a spacer to separate and align them:

![(left) A d-pad controller layout using spacers, (right) the spacer's highlighted to demonstrate their positioning](https://flowfuse.com/blog/2024/11/images/spacer-example.png){dataZoomable=""}*(left) A d-pad controller layout using spacers, (right) the spacer's highlighted to demonstrate their positioning*

Spacers can be any width and height, and will always render empty-space. To add a new spacer, you can click the "+" button in the Dashboard sidebar next to any Groups. You can then re-order the widgets there too (re-ordering of widgets in the visual layout editor will be coming soon).

## What else is new?

You can find the full 1.19.0 Release Notes [here](https://github.com/FlowFuse/node-red-dashboard/releases/tag/v1.19.0){rel="&#x22;nofollow&#x22;"}.

Work has already begun on the next release, `1.20.0`, you can see what items we have queued up [here](https://github.com/orgs/FlowFuse/projects/15/views/1){rel="&#x22;nofollow&#x22;"}, if you've got any feedback or suggestions, please do let us know, and feel free to open new issues on our [GitHub](https://github.com/FlowFuse/node-red-dashboard/issues){rel="&#x22;nofollow&#x22;"}

## We are Hiring!

You may have seen already that we are hiring for a full-time Front-End Engineer to join our team, and work on Dashboard, full-time. If you are interested in working with us, please do check out the job listing [here](https://job-boards.greenhouse.io/flowfuse/jobs/5185319004){rel="&#x22;nofollow&#x22;"}.


# Run FlowFuse Device Agent as a service on MacOS using Docker

The FlowFuse Device Agent is a tool that enables you to run Node-RED on various hardware devices, such as Raspberry Pi, Windows, MacOS, and PLCs. Running Node-RED directly on the device helps when your application flow needs direct access to sensors and actuators connected to the hardware, facilitating seamless integration with the FlowFuse platform. This integration enables secure management, monitoring, and remote editing of flows from a centralized platform, even at the edge.

In this article, we will explore how to run the FlowFuse Device Agent as a service on MacOS using Docker. This setup ensures that the Device Agent runs in the background, automatically starts on boot, and maintains a continuous connection the FlowFuse platform for remotely managing your Node-RED flows, even after a device restart. This eliminates the need to manually start the agent after each reboot, saving you time and effort.

### Prerequisites

Before starting, ensure that you have the following set up:

- **FlowFuse Account**: You need an active FlowFuse account to register your device and manage your flows remotely. If you don't have an account, you can [sign up](https://app.flowfuse.com/account/create?utm_campaign=60718323-BCTA&utm_source=blog&utm_medium=cta&utm_term=high_intent&utm_content=Run%20FlowFuse%20Device%20Agent%20as%20a%20service%20on%20MacOS%20using%20Docker){rel="&#x22;nofollow&#x22;"} at FlowFuse.

*NOTE: The instructions in this guide were tested on MacBook M1 & M4 MacBook Pro*

### Step 1: Install Homebrew

Homebrew is the MacOS package manager for installing packages and libraries. You can install it using the following command:

```bash
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
```

This script will install the Homebrew package manager on your Mac. Once installed, you can easily install other packages like Docker and Colima.

### Step 2: Install Docker

With Homebrew installed, you can now install Docker by running:

```bash
brew install docker-credential-helper docker
```

This will install Docker and its credential helper, which is useful for managing authentication with Docker registries.

### Step 3: Install Colima

Colima is a free alternative to Docker Desktop, particularly useful for MacOS, and offers better compatibility with Apple Silicon hardware. We’ll need it to run the Flowfuse Device Agent container that we will create later. To install Colima, run:

```bash
brew install colima
```

### Step 4: Start Colima

Once Colima is installed, start it with:

```bash
colima start
```

This command starts the Colima virtual machine, which Docker will then use to run containers. If Colima is not running, Docker won't have the necessary environment to create and run containers.

```bash
colima status
```

![CLI: Showing the result of colima status](https://flowfuse.com/blog/2024/11/images/colima-status.png){dataZoomable=""}&#x2A;CLI: Showing the result of `colima status`*

### Step 5: Set Colima to Run as a Service

To ensure Colima starts automatically in the background, run the following:

```bash
brew services start colima
```

This will set Colima to run as a service, so it will start automatically every time your Mac boots up.

### Step 6: Adding the Device to the FlowFuse Platform

Now, you'll need to add a new device to the FlowFuse platform and download the device configuration file. This configuration will allow to connect your MacOS device to your FlowFuse team. For more information on how to add a device and generate the configuration, refer to [Generating "Device Configuration"](https://flowfuse.com/docs/device-agent/register/).

### Step 7: Run the FlowFuse Device Agent Container

You can now run the FlowFuse Device Agent container using Docker. Replace `/path/to/device.yml` with the actual path to the device configuration file you have downloaded. The following command will launch the container:

```bash
docker run -d --restart unless-stopped \
 --mount type=bind,src=/path/to/device.yml,target=/opt/flowfuse-device/device.yml \
  -p 1880:1880 flowfuse/device-agent:latest
```

Explanation of the command:

- `-d`: Run the container in detached mode (in the background).
- `--restart` unless-stopped: Ensure the container restarts automatically unless explicitly stopped.
- `--mount type=bind,src=/path/to/device.yml,target=/opt/flowfuse-device/device.yml`: Mounts your local device.yml file into the container so it can be accessed by the agent.
- `-p 1880:1880`: Exposes port 1880 on your host machine, which is typically used for the Node-RED web interface.
- `flowfuse/device-agent:latest`: The Docker image for the FlowFuse Device Agent.

### Step 8: Verify the Device Agent is Running

To verify that the Device Agent is running correctly, you can use the following command:

```bash
docker ps
```

![CLI: Showing the result of docker ps indicating device agent is running correctly](https://flowfuse.com/blog/2024/11/images/docker-ps-result.png){dataZoomable=""}*CLI: Showing the result of `docker ps` indicating the device agent is running correctly*

This will list all running containers, and you should see the FlowFuse Device Agent listed there. If it's not running, you can check the logs to troubleshoot:

```bash
docker logs <container_id>
```

Additionally, you can confirm that the Device Agent is running and successfully connected to the FlowFuse platform by following these steps:

1. Navigate to the FlowFuse platform.
2. In the left sidebar, click on "Edge Devices".
3. Then, select the device you added for MacOS.

![FlowFuse Platform: showing the status of your edge device](https://flowfuse.com/blog/2024/11/images/device-status-on-ff.png){dataZoomable=""}*FlowFuse Platform: showing the status of your edge device*

Now, you can start developing applications on the device remotely from any location and manage it efficiently.

### Step 9: Ensure the Device Agent Restarts Automatically After a Reboot

The `--restart unless-stopped` flag in the Docker command ensures that your FlowFuse Device Agent container will automatically restart if your Mac reboots. However, it's always good to verify this by restarting your system:

1. Restart your Mac.
2. After rebooting, check the status of the FlowFuse Device Agent:

```bash
   docker ps
```

### Conclusion

By following these steps, you've successfully set up the FlowFuse Device Agent on your macOS system using Docker and Colima. Now, the agent will run seamlessly in the background and restart automatically after a system reboot.


# Interacting with ESP32 Using Node-RED and MQTT (2026)

The ESP32 is an affordable and powerful microchip that combines Wi-Fi and Bluetooth in one small package. It's commonly used in smart devices like home automation systems, wearables, and other IoT projects. Despite its low cost (around $6), it offers strong performance, and low power consumption, and is compatible with popular platforms like Arduino. Whether you're a hobbyist or a business, the ESP32 provides great value, making it easy to create wireless devices without a big investment. This tutorial demonstrates how to set up communication between the ESP32 and Node-RED using MQTT, along with an interactive dashboard via FlowFuse for a user-friendly interface.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: ecfJ-9MxyVE
---
::

## Prerequisites

To follow this tutorial, you'll need the following:

- **ESP32 microcontroller**: The hardware you'll be using for this project.
- **USB cable**: To connect the ESP32 to your computer.
- **Arduino IDE**: Installed and set up to program your ESP32. [Download](https://support.arduino.cc/hc/en-us/articles/360019833020-Download-and-install-Arduino-IDE){rel="&#x22;nofollow&#x22;"}the Arduino IDE if you haven't already done so.
  - Additionally, if you haven't set up the Arduino IDE for the ESP32 board, please follow this tutorial: [How to Set Up ESP32 with Arduino IDE](https://www.youtube.com/watch?v=CD8VJl27n94){rel="&#x22;nofollow&#x22;"}
- **FlowFuse account**: This will allow you to create and deploy Node-RED instances securely on the cloud with a single click, collaborate on your Node-RED projects with your team, manage and program your edge devices remotely, and provide an MQTT broker with an interface for securely managing clients.

If you haven’t signed up for a FlowFuse account yet, [sign up](https://app.flowfuse.com/account/create?utm_campaign=60718323-BCTA&utm_source=blog&utm_medium=cta&utm_term=high_intent&utm_content=Interacting%20with%20ESP32%20Using%20Node-RED%20and%20MQTT){rel="&#x22;nofollow&#x22;"} now.

## Getting Started with ESP32 and Node-RED

In this section, we’ll set up Node-RED on FlowFuse, create an MQTT connection, and configure everything to interact with your ESP32. This will lay the foundation for building your IoT flows and controlling devices.

### Step 1: Creating Node-RED instance on FlowFuse Cloud

Start by logging into your [FlowFuse](https://flowfuse.com) account and creating a new Node-RED instance. For more information on creating a Node-RED instance, refer to the [FlowFuse documentation](https://flowfuse.com/docs/user/introduction/#creating-a-node-red-instance).

Once the instance is created, open the Node-RED editor.

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

### Step 2: Creating and Configuring MQTT Clients in FlowFuse

In this step, we’ll set up MQTT to enable communication between Node-RED and the ESP32. MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for reliable, low-bandwidth communication between devices in IoT applications.

We use MQTT because it allows devices to communicate over a network (like Wi-Fi) without the need for a direct physical connection. This makes it perfect for long-distance communication, where devices need to send and receive data efficiently, even when they are not physically connected or close to each other.

![Diagram showing the flow of data and how commands are sent to the ESP32 using MQTT using Node-RED.](https://flowfuse.com/blog/2024/11/images/esp32-mqtt-node-red.png){dataZoomable=""}*Diagram showing the flow of data and how commands are sent to the ESP32 using MQTT using Node-RED*

In our setup, Node-RED will publish commands to the MQTT broker, and the ESP32 will subscribe to topics to receive responses. The ESP32 will then perform actions, such as controlling an LED. To facilitate this, we’ll create two MQTT clients in FlowFuse (since the MQTT broker is already set up and managed by FlowFuse, you don’t need to worry about its configuration or maintenance). One client will be for Node-RED, and the other will be for the ESP32. These clients will handle the secure and reliable exchange of messages, ensuring smooth communication between the two devices.

**To Create MQTT Clients in FlowFuse:**

1. Navigate to your FlowFuse platform and log in to your account.
2. In the left sidebar, click on "Broker".
3. In the newly opened interface, click the “Create Client” button.
4. Enter a username and password for your MQTT client. Confirm the password.
   - You can leave the default pattern as `#` for access control, or set a custom pattern if needed.

![Interface for setting MQTT client details and credentials](https://flowfuse.com/blog/2024/11/images/mqtt-client-create.png){dataZoomable=""}*Interface for setting MQTT client details and credentials*

5. Click "Create" to generate the client.
6. Copy the client ID and save it somewhere secure for later use.
7. Repeat the same steps to create the second MQTT client for the ESP32.

### Step 3: Building a Node-RED Dashboard to Send Commands Over MQTT

Now that we’ve created the MQTT clients, it’s time to build a Node-RED dashboard and create a flow that will publish commands to the FlowFuse MQTT broker. This will later allow you to interact with your ESP32 using a user-friendly interface.

**Let's first create a flow to connect to the MQTT broker with the client config we have created:**

1. Drag the **mqtt out** node onto the canvas in Node-RED.
2. Double-click the **mqtt out** node to open the settings.
3. Click the pencil icon next to the Server field to open the MQTT broker configuration.
4. In the configuration, enter the following details:
   - Server: `broker.flowfuse.cloud`
   - Client ID: The Client ID you created earlier.
   - Username: The MQTT username (Client ID).
   - Password: The MQTT password.
5. Click "Add" to save the configuration, then select the newly added configuration.
6. In the Topic field, enter a topic name, such as `/LEDControl`.
7. Click "Done" to close the settings.
8. Click "Deploy" in the top-right corner to deploy the flow.
9. Once deployed, check the MQTT out node for a Connected status, confirming the connection to the MQTT broker.

For this example, we will create a very simple dashboard. If you're not familiar with FlowFuse Dashboard, you can refer to the following blog to get started: [FlowFuse Dashboard: Getting Started](https://flowfuse.com/blog/2024/03/dashboard-getting-started/)

1. Install the `@flowfuse/node-red-dashboard` from the Node-RED Palette Manager.
2. Drag two **ui-button** widgets onto the canvas.
3. Double-click on the first button and set the Label to "ON", the Background Color to Green, and the Payload to `1`. Adjust the Width and Height as needed.
4. Double-click on the second button and set the Label to "OFF", the Background Color to Red, and the Payload to `2`.
5. Connect the output of both buttons to the input of the **mqtt out** node.
6. Click "Deploy" to save the flow.

::render-flow
```json
[{"id":"59887a8115c95eae","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"02c25e8a30f9379d","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"showPageTitle":true,"navigationStyle":"default","titleBarStyle":"default"},{"id":"cfb2ab9ff30660fc","type":"ui-theme","name":"Default Theme","colors":{"surface":"#ffffff","primary":"#0094CE","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"d263574af6876c7a","type":"ui-page","name":"ESP32","ui":"02c25e8a30f9379d","path":"/page1","icon":"home","layout":"grid","theme":"cfb2ab9ff30660fc","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"3ae115ea7ede6827","type":"ui-group","name":"Group 1","page":"d263574af6876c7a","width":"6","height":"1","order":1,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"def97b29f5f7baab","type":"mqtt-broker","name":"","broker":"broker.flowfuse.cloud","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closeRetain":"false","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willRetain":"false","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":""},{"id":"5a9162986a34a4d6","type":"ui-button","z":"59887a8115c95eae","group":"3ae115ea7ede6827","name":"","label":"ON","order":1,"width":"3","height":"2","emulateClick":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","iconPosition":"left","payload":"1","payloadType":"num","topic":"topic","topicType":"msg","buttonColor":"green","textColor":"","iconColor":"","enableClick":true,"enablePointerdown":false,"pointerdownPayload":"","pointerdownPayloadType":"str","enablePointerup":false,"pointerupPayload":"","pointerupPayloadType":"str","x":190,"y":120,"wires":[["9239f8a7cca5c858"]]},{"id":"f9c194994d9491a8","type":"ui-button","z":"59887a8115c95eae","group":"3ae115ea7ede6827","name":"","label":"OFF","order":2,"width":"3","height":"2","emulateClick":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","iconPosition":"left","payload":"2","payloadType":"num","topic":"topic","topicType":"msg","buttonColor":"red","textColor":"","iconColor":"","enableClick":true,"enablePointerdown":false,"pointerdownPayload":"","pointerdownPayloadType":"str","enablePointerup":false,"pointerupPayload":"","pointerupPayloadType":"str","x":190,"y":160,"wires":[["9239f8a7cca5c858"]]},{"id":"9239f8a7cca5c858","type":"mqtt out","z":"59887a8115c95eae","name":"","topic":"/LedControl","qos":"","retain":"","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"def97b29f5f7baab","x":390,"y":140,"wires":[]}]
```
::

Now, when you click either the "ON" or "OFF" button on the dashboard, it will send either 1 or 2 as the payload. The ESP32 will use this payload in its code to turn the LED on or off. To view the dashboard, switch to the Dashboard 2.0 tab on the right side and click the Open Dashboard button. The dashboard will look similar to the image below.

![FlowFuse Dashboard Build to control the ESP32 LED](https://flowfuse.com/blog/2024/11/images/dashboard2.png){dataZoomable=""}*FlowFuse Dashboard Build to control the ESP32 LED*

### Step 4: Programming ESP32 to receive commands from MQTT and Control LED

Now, let's move on to the final step. Before proceeding, make sure your ESP32 is **connected to your laptop or computer via USB**\*. The USB connection is essential for uploading the code (sketch) to the ESP32, which will enable it to connect to the internet and communicate with the MQTT broker.
The ESP32 will subscribe to the MQTT topic we configured earlier (e.g., /LEDControl). Based on the received payload (1 or 2), it will control the LED accordingly, turning it on or off.

**Setting up Arduino IDE:**

1. Open the Arduino IDE on your computer.
2. Ensure you have selected the correct board and port in the Tools menu.
3. Install the necessary library:
4. Go to Tools > "Manage Libraries".
5. Search for and install the "EspMQTTClient" library by Patrick Lapointe.
6. The library installation will prompt you to install its dependencies, ensure that you tick that option and proceed to install.

**Code for ESP32:**

1. Copy the following code into the Arduino IDE:

```cpp
#if defined(ESP32)
#include <WiFi.h>
#elif defined(ESP8266)
#include <ESP8266WiFi.h>
#endif

#include <PubSubClient.h>

#define LedPin 2 // ESP32 built-in LED pin

// WiFi and MQTT settings
const char* ssid = ""; // Change this to your WiFi SSID
const char* password = ""; // Change this to your WiFi password
const char* mqtt_server = "broker.flowfuse.cloud"; // FlowFuse MQTT broker server

// MQTT client credentials
const char* mqtt_client_id = ""; // Replace with your MQTT client ID
const char* mqtt_username = ""; // Replace with your MQTT username
const char* mqtt_password = ""; // Replace with your MQTT password

WiFiClient espClient;
PubSubClient client(espClient);

// Function to connect to WiFi
void setup_wifi() {
    delay(10);
    Serial.println();
    Serial.print("Connecting to ");
    Serial.print(ssid);
    WiFi.begin(ssid, password);

    while(WiFi.status() != WL_CONNECTED) {
        delay(500);
        Serial.print(".");
 }

    Serial.println("\nWiFi connected");
    Serial.print("IP address: ");
    Serial.println(WiFi.localIP());
}

// Callback function to handle messages from subscribed topics
void callback(char* topic, byte* payload, unsigned int length) {

 String msg;
    for (int i = 0; i < length; i++) {
 msg += (char)payload[i];
 }

 // Control LED based on message
    if (msg == "1") {
        digitalWrite(LedPin, HIGH); // Turn LED on
 }
    else if (msg == "2") {
        digitalWrite(LedPin, LOW); // Turn LED off
 }
}

// Function to connect to MQTT broker
void reconnect() {
    while (!client.connected()) {
        Serial.println("Attempting MQTT connection...");

 // Connect to MQTT broker with the client ID, username, and password
        if (client.connect(mqtt_client_id, mqtt_username, mqtt_password)) {
            Serial.println("Connected to MQTT broker");
            client.subscribe("/LedControl");
 }
        else {
            Serial.print("Failed, rc=");
            Serial.print(client.state());
            Serial.println(" trying again in 5 seconds");
            delay(5000);
 }
 }
}

void setup() {
    Serial.begin(115200);
    pinMode(LedPin, OUTPUT);
    setup_wifi();
    client.setServer(mqtt_server, 1883);
    client.setCallback(callback);
}

void loop() {
    if (!client.connected()) {
        reconnect();
 }
    client.loop();
}
```

2. Replace the placeholder values in the code: SSID (your Wi-Fi network's SSID), Wi-Fi Password (your Wi-Fi network's password), MQTT Client ID (the MQTT client ID you generated for esp32), MQTT Username and Password (the MQTT credentials you created).
3. After you've made these changes, click "Upload" in the Arduino IDE to upload the code to your ESP32.
4. Once the upload is complete, open the Serial Monitor (set the baud rate to 115200) to monitor the output.

If everything is set up correctly, you should see the output in the Serial Monitor as shown in the image.

![Serial monitor displaying the result when everything is set up correctly.](https://flowfuse.com/blog/2024/11/images/serial-monitor.png){dataZoomable=""}&#x2A;Serial monitor displays the result when everything is set up correctly.*

Once you verify the setup, you can unplug the USB from the computer and connect the ESP32 to a power adapter. With this, your ESP32 is now powered and connected to Wi-Fi (make sure your device is on the same Wi-Fi network as the one configured in the code), allowing you to control the LED from anywhere in the world via the MQTT commands sent through Node-RED.

### Troubleshooting

1. **Can't Upload Code to ESP32**
   - Solution: Make sure the correct board and port are selected in the Arduino IDE.
     Check Tools > Board for the right ESP32 model and Tools > Port for the correct connection.
     If the port is missing, [Download](https://www.silabs.com/developer-tools/usb-to-uart-bridge-vcp-drivers?tab=downloads){rel="&#x22;nofollow&#x22;"} and reinstall the CP210x USB drivers.
2. **ESP32 Keeps Disconnecting from MQTT**

- Solution: Make sure both the ESP32 and Node-RED have unique MQTT client IDs.
  If both devices share the same client ID, they will conflict and cause disconnections.

3. **ESP32 Doesn’t Respond to Commands (LED Not Turning On/Off)**
   - Solution: Verify the topic in the ESP32 code matches the one in Node-RED (e.g., /LedControl). If it still doesn't work, try rebooting your ESP32.

## Conclusion

In this tutorial, we successfully connected the ESP32 to Node-RED using MQTT, enabling remote control of an LED via a FlowFuse dashboard. This simple IoT setup demonstrates how easy it is to interact with devices using MQTT and Node-RED, offering a flexible and scalable solution for future projects. With the ESP32, Node-RED, and FlowFuse, you can easily expand and integrate more devices into your IoT system.


# FlowFuse 2.11: MQTT Topic Hierarchy, UI Revamp & Improved Logging

The focus of the FlowFuse 2.11 release has all been about providing clarity for our users and reducing friction in our user experience.

Navigation in FlowFuse has been streamlined with a new sidebar and team-wide search feature. We've provided an interactive visualization for your MQTT topic hierarchy, ensuring you have a clear view of your own MQTT/UNS architecture, and, we've re-architected the audit logging to ensure you have an easy-to-understand and searchable view of everything going on in your FlowFuse Team and it's respective Applications, Instances and Devices.

## Navigation Revamp

If you're using FlowFuse Cloud, you'll have already noticed a big improvement to our navigation sidebar on the left of the user interface that was released a couple of weeks ago. This is now packaged up into FlowFuse 2.11 and available to our self-hosted customers too.

![Screenshot of the new navigation sidebar in FlowFuse](https://flowfuse.com/blog/2024/11/images/screenshot-sidebar.png){dataZoomable=""}*Screenshot of the improve left-side navigation in FlowFuse*

This is the first stage of a navigation revamp we're working on, that will represent a big improvement for navigation around FlowFuse, and help make managing your applications easier.

You'll notice we've renamed "Devices" to "Edge Devices" to make it clearer that these are *instances of Node-RED* that are running on devices, rather than just a record of the device itself. We've also separated out many of the pages into sections, making it easier to find what you're looking for, and giving us scope to add in more in the coming weeks, which will make it easy to jump straight to the features you need.

### Team-wide Search

A very popular feature in the "home" view of FlowFuse is the search bar that helps you find the relevant Application, Instance, or Device you're looking for. This has been moved into the top header and will be available on every page of FlowFuse, making it even easier to find what you're looking for, wherever you are.

![Screenshot of the team-wide search](https://flowfuse.com/blog/2024/11/images/screenshot-search.png){dataZoomable=""}*Screenshot of the team-wide search*

This will soon be followed by an update to our "Applications" view which is currently quite over-crowded. We're always looking to reduce friction for our users, and this is a big step in doing that.

## MQTT Topic Hierarchy

We recently [announced our very own MQTT Service](https://flowfuse.com/blog/2024/10/announcement-mqtt-broker), and we're following that up with an update that lets you see what topics are being used by your MQTT clients in the UI:

![Screenshot of the UI to explore your MQTT topic hierarchy](https://flowfuse.com/blog/2024/11/images/screenshot-mqtt-hierarchy.png){dataZoomable=""}*Screenshot of the UI to explore your MQTT topic hierarchy*

This will make managing your event-driven applications even easier, giving you clarity on the structure of your topic-space, whether you're using the MQTT Broker for a unified namespace (UNS) or any other use case.

## Audit Logging Improvements

We've improved the Audit Log views at the Team and Application levels to given you better visibility on the actions taken by users across your whole team in FlowFuse.

Previously, only events associated to that "level" (e.g. Team, Application, Instance) were shown in the respective log. However, now, when you view the "Team" Audit Log, it shows not just events on that team specifically, e.g. a settings change, but also all Audit events for it's "children", i.e. the Applications, Instances, Pipelines, etc. that are part of that team too.

New filters on the right-side also make it easy to explore everything taking place in your FlowFuse Team, allowing you to dive into a given Instance, all from the top-level "Team" view.

![Screenshot of the improved audit log view](https://flowfuse.com/blog/2024/11/images/audit-log-child-events.png){dataZoomable=""}*Screenshot of the improved audit log view*

For a full list of everything that went into our 2.11 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.11.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try FlowFuse

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.

## Upgrading FlowFuse

If you're using \[FlowFuse Cloud]\({{ site.appURL }}), then there is nothing you need to do - it's already running 2.10, and you may have already been playing with the new features.

If you installed a previous version of FlowFuse and want to upgrade, our documentation provides a guide for [upgrading your FlowFuse instance](https://flowfuse.com/docs/upgrade/).

If you have an Enterprise license please make sure to review this [changelog entry](https://flowfuse.com/changelog/2024/08/enterprise-license-update)

## Getting help

Please check FlowFuse's [documentation](https://flowfuse.com/docs/) as the answers to many questions are covered there. Additionally you can go to the [community forum](https://discourse.nodered.org/c/vendors/flowfuse/24){rel="&#x22;nofollow&#x22;"} if you have
any feedback or feature requests.


# Getting the Most Out of MQTT for Industrial IoT

MQTT is a go-to protocol for industrial IoT, known for its efficiency, scalability, and ease of use. While it offers great flexibility in handling real-time data, there are key factors to consider in order to get the most out of it. From ensuring data consistency to addressing security and performance concerns, these factors can significantly enhance MQTT’s effectiveness in industrial settings.

This post dives into how to optimize MQTT for industrial IoT, covering best practices and key considerations. It also highlights how FlowFuse can help streamline MQTT communication, improving data reliability, security, and integration across devices and systems.

## Standardizing Data Formats for Better Quality and Consistency

Industrial data is generated by a wide variety of devices, machines, and systems, making it highly valuable. However, to fully leverage this data, it needs to be standardized and formatted in a way that ensures seamless processing across different systems, especially since it can come in a variety of formats.

One of MQTT’s key strengths is its flexibility in handling various data formats. While this is an advantage, it can sometimes require additional effort to ensure that the data is structured consistently and in a way that’s easy to use. Standardizing data formats helps organizations streamline processes, making data easier to interpret, analyze, and act upon. Without a consistent approach, data inconsistencies may arise, slowing down insights or causing compatibility issues.

Frameworks like [Sparkplug B](https://flowfuse.com/blog/2024/08/using-mqtt-sparkplugb-with-node-red/) are designed to help address this by providing a standardized way to handle MQTT payloads. By adopting such frameworks, companies can ensure that data is delivered in a consistent, well-structured format, improving compatibility and making it easier to analyze. This not only simplifies integration across diverse systems but also enables more reliable decision-making and efficient operations.

## Optimizing Payloads and Bandwidth for Efficient MQTT Communication

MQTT is designed for lightweight, efficient messaging, which makes it ideal for many IIoT applications. However, in cases where large amounts of data or high-frequency messages need to be transmitted, bandwidth constraints can sometimes impact performance.

While the MQTT protocol supports large message payloads (up to 250 MB), transmitting large files such as high-resolution images or detailed sensor data can slow down communication. Fortunately, there are simple yet effective strategies to keep your MQTT network running smoothly, even when dealing with sizable payloads.

To optimize performance, consider compressing your data before sending it, which reduces the overall size of the payload and makes transmission faster and more efficient. For even larger files, such as video or binary data, a great approach is to store these files externally (e.g., in cloud storage like AWS S3) and send only a reference or pointer to the data. This avoids the need to transmit large files over MQTT while ensuring data accessibility.

By using these strategies, you can optimize MQTT performance and ensure that your system runs efficiently, even when handling large or high-frequency data. These techniques allow MQTT to continue providing fast, reliable, and scalable communication, regardless of the data size or frequency.

## Ensuring Reliable Data Delivery with MQTT’s QoS Levels

In industrial environments, the accuracy and timeliness of data transmission are crucial for maintaining operational efficiency and safety. MQTT’s publish-subscribe model is designed for lightweight, real-time messaging, but it’s important to understand how to leverage its features to ensure the reliability and integrity of the data flow.

While the protocol is generally robust, in some cases, challenges such as network disruptions or temporary communication failures can occur. These can lead to issues such as message loss or delivery out of order. Fortunately, MQTT provides built-in mechanisms to address these challenges and ensure that messages reach their intended destination reliably.

One of the key feature for managing message delivery is Quality of Service (QoS), which defines how MQTT handles message delivery:

- **QoS 0**: Messages are delivered at most once, with no guarantee of delivery or order. This level is ideal for scenarios where occasional message loss is acceptable and minimizing network overhead is critical.
- **QoS 1**: Guarantees that messages are delivered at least once, although duplicates may occur. This is useful when data consistency is important, but some duplication can be handled by the system.
- **QoS 2**: Ensures messages are delivered exactly once and in the correct order. This highest level of QoS is suitable for scenarios where data integrity and sequencing are paramount, such as in robotic control systems or safety-critical operations.

By choosing the right QoS level, you can align MQTT’s behavior with the operational needs of your system, balancing between performance, data reliability, and system resources. For real-time applications, a lower QoS level may be sufficient, while in more critical situations, the higher QoS levels offer a stronger guarantee of data delivery and integrity.

With these options, MQTT allows you to fine-tune message delivery to meet the specific requirements of your industrial IoT environment, ensuring that data flows smoothly and reliably, even in challenging network conditions.

## Implementing Acknowledgment Mechanisms in MQTT

One important consideration when working with MQTT is the lack of built-in acknowledgment mechanisms. Unlike traditional request-response communication models, where the receiver explicitly confirms the receipt of a message, MQTT doesn't natively offer a direct way for the receiver to acknowledge successful message receipt.

This lack of visibility can pose challenges in scenarios where it’s crucial to ensure that data has been transmitted successfully and processed as expected. In some industrial systems, failure to confirm receipt of messages could lead to operational uncertainty or potential errors.

However, while MQTT does not provide this feature out-of-the-box, it is possible to implement acknowledgment mechanisms to enhance reliability. we can use a separate topic where the receiver sends a confirmation message (such as “ack” or “received”) back to the sender, indicating that the message was successfully processed.

This allow you to implement acknowledgment functionality, but they do require additional planning and development effort. Ensuring that these mechanisms are correctly designed and integrated can improve system reliability by providing the necessary feedback loop for confirming message receipt and processing.

By incorporating acknowledgment systems, you can enhance the visibility and confidence in data transmission, ensuring that your industrial IoT system operates smoothly and that no critical messages are missed or lost.

## Optimizing MQTT for Resource-Constrained Environments

While MQTT’s use of TCP/IP ensures reliable message delivery, it can introduce challenges in environments where devices have limited resources. Maintaining persistent TCP connections can consume significant processing power and memory, which may be a concern for low-power or resource-constrained devices.

To address this, some IoT systems use MQTT-SN (MQTT for Sensor Networks), a variant that operates over UDP and is specifically designed for devices with limited resources. MQTT-SN reduces the overhead associated with maintaining a TCP connection, making it a better fit for battery-powered or embedded devices that need to conserve energy. However, it's important to note that MQTT-SN is distinct from the standard MQTT specification, as it involves different message formats and communication mechanisms.

By carefully selecting the appropriate protocol and architecture for your specific use case, you can continue to leverage MQTT-like messaging capabilities, while optimizing performance in environments with limited resources.

## Ensuring Security in MQTT Deployments

Security is essential when using MQTT in industrial environments. While MQTT offers powerful features like encryption and authentication, it's crucial to configure these elements correctly to maximize security. A properly secured MQTT deployment ensures that your system remains protected from risks such as data interception, unauthorized access, or man-in-the-middle attacks, while ensuring that your communication remains secure and reliable.

To begin, implementing encryption (SSL/TLS) is an important step to protect the data transmitted between devices and brokers. This ensures that sensitive information is kept confidential and is shielded from unauthorized access. By enabling encryption, you create a secure communication pathway that prevents eavesdropping and data tampering.

Next, consider authentication for all devices and users. By using mechanisms such as usernames, passwords, or client certificates, you can ensure that only authorized devices and users can connect to your MQTT broker. This access control mechanism ensures that only the right people and devices have access to the network, safeguarding it from potential threats.

Topic-level access control is another key aspect of securing your MQTT deployment. By managing who can publish or subscribe to specific topics, you can prevent unauthorized access to sensitive data or critical commands. For example, you can restrict which devices or users are allowed to subscribe to specific topics that control industrial equipment or monitor sensitive processes. This level of control ensures that only trusted entities can interact with certain parts of your system, reducing the risk of malicious actions.

In addition to restricting access to topics, it's also important to regularly monitor your MQTT traffic for any unusual activity or anomalies. By staying vigilant and analyzing traffic patterns, you can identify potential security threats early and take action to prevent any disruptions.

By configuring your MQTT setup with encryption, authentication, topic-level access control, and ongoing monitoring, you can create a secure, reliable, and scalable IoT system. A well-secured MQTT deployment not only reduces risks but also enhances the efficiency and safety of industrial operations, providing peace of mind as your system grows.

## Minimizing Risks of Single Point of Failure and Vendor Lock-In

When using MQTT for industrial operations, it’s important to address the potential risks associated with a single point of failure, specifically the central broker. While the broker is crucial for managing message delivery, its failure could disrupt the entire data flow, impacting operations. However, this challenge can be effectively managed with strategies like high availability, load balancing, and robust backup solutions. By implementing these best practices, you ensure that your system remains reliable and resilient, even in the event of a failure.

Another consideration is vendor lock-in, which can occur when businesses become reliant on a specific MQTT broker or service. While this may seem convenient at first, it can make future changes or migrations difficult due to proprietary features or configurations that aren't easily compatible with other systems. This is a scenario that can be easily avoided with careful planning.

Although MQTT is an open standard, some cloud services may not fully adhere to the MQTT 3.1.1 specification. This can sometimes lead companies to rely on proprietary software development kits (SDKs) for sending MQTT messages. While these tools can work well initially, they can limit your ability to switch vendors or integrate with other systems down the road.

To maintain flexibility and avoid vendor lock-in, it's crucial to choose an MQTT broker that fully supports MQTT's open standards. Brokers that follow standards like MQTT 3.1.1 or MQTT 5.0 ensure compatibility and interoperability, making it easier to switch providers or integrate new technologies as your needs evolve.

## How FlowFuse Enhances Your Industrial IoT System

FlowFuse is an industrial data platform that streamlines the management, scaling, and security of IoT applications. Built on Node-RED at its core, FlowFuse offers seamless integration with various industrial protocols, including MQTT, ensuring reliable communication between devices. With its robust feature set, FlowFuse makes it easier to build secure, scalable, and efficient IoT solutions for industrial environments

A key strength of FlowFuse is its ability to standardize data before sending it to the MQTT broker. Using Node-RED’s intuitive low-code programming capabilities, you can define consistent data formats and topics across all connected devices. This ensures smooth integration between diverse systems and maintains data consistency, allowing everything to work together seamlessly. FlowFuse also supports frameworks like [Sparkplug B](https://flowfuse.com/blog/2024/08/using-mqtt-sparkplugb-with-node-red/), providing additional structure for more reliable communication with MQTT payloads.

Security is another area where FlowFuse excels. It allows you to configure MQTT nodes with SSL/TLS encryption, username/password authentication, and other security measures to ensure secure communication between devices. This protects sensitive data from unauthorized access and ensures that your system’s communications remain confidential.

FlowFuse also simplifies the creation of acknowledgment mechanisms. With Node-RED, you can design custom workflows to track message receipt and processing, ensuring data integrity and improving operational transparency. This level of control guarantees that your system operates smoothly and reliably.

Additionally, FlowFuse provides its own MQTT broker service that follows open standards, helping you avoid vendor lock-in and offering the flexibility to scale and adapt as your needs evolve. With built-in high availability, load balancing, and access control mechanisms, FlowFuse ensures continuous and reliable and secure data flow. And you can scale its capabilities by contacting FlowFuse support to meet the growing demands of your industrial IoT system.

## Conclusion

Getting the most out of MQTT for industrial IoT is all about smart strategies and the right tools. By focusing on data consistency, security, and performance, you can build a resilient and efficient IoT ecosystem. With FlowFuse, you get a powerful, flexible platform that not only streamlines MQTT communication but also helps you stay ahead of challenges like security risks and vendor lock-in. Whether you're optimizing payloads, enhancing security, or scaling your system, FlowFuse makes it easier to unlock the full potential of your industrial IoT operations.


# Introducing the Industrial Visionaries Podcast!

Today, we’re excited to announce our new podcast: Industrial Visionaries!

This show is dedicated to exploring the transformative power of technology in the manufacturing sector.

In each episode, our host ZJ van de Weg, CEO of FlowFuse, brings you face-to-face with industry leaders who are pioneering digital solutions, sharing insights that will help you navigate the future of manufacturing.

### Episode 1: FlowFuse’s Nick O’Leary on Low-Code Development and Its Impact on IoT

In our inaugural episode of Industrial Visionaries, our host ZJ van de Weg, chats with fellow FlowFuse exec, Nick O’Leary, CTO & Founder. Nick, who is also the creator of Node-RED, shares his extensive insights into the evolution of the Internet of Things (IoT). He discusses the early days of IoT and the transformative role of edge computing, highlighting how increased computing power has shifted data processing closer to devices.

Listen to the first episode on:

- [Apple Podcasts](https://podcasts.apple.com/us/podcast/ep-1-flowfuses-nick-oleary-on-low-code-development/id1781774461?i=1000678217258){rel="&#x22;nofollow&#x22;"}
- [Spotify](https://open.spotify.com/episode/6HJB35FbK1U7pVNpTyM6P2){rel="&#x22;nofollow&#x22;"}
- [YouTube](https://www.youtube.com/watch?v=AI-bjry8vLU){rel="&#x22;nofollow&#x22;"}

We look forward to bringing you more conversations with actionable insights that help in your pursuit to innovate in your industry.

For the latest episodes, search for “Industrial Visionaries” on Spotify, Apple, YouTube, or wherever you listen to podcasts!


# Migrating from Self-Managed Node-RED to FlowFuse-Managed Node-RED

Migrating your Node-RED instance to [FlowFuse](https://flowfuse.com) centralizes management and simplifies deployment. Once migrated, FlowFuse takes care of the infrastructure, security, and scalability, making the process much easier. This allows you to focus on building solutions without worrying about the complexities of self-hosting. Whether you're working with edge devices or want to work on cloud instances, this migration streamlines the management of your IIoT workflows, improving efficiency and scalability.

Let's explore how to migrate from a self-managed and self-hosted Node-RED setup to a FlowFuse-managed environment. We'll look at how the migration works for both edge devices and cloud instances.

## Why Switch from Self-Managed Node-RED to FlowFuse-Managed Node-RED?

Managing self-hosted Node-RED instances can introduce a range of challenges, especially as your Industrial Internet of Things (IIoT) environment scales. These challenges include:

- **Deployment Complexity**: Installing and configuring Node-RED across multiple devices or environments requires technical expertise and attention to detail. For large-scale deployments, managing numerous instances across different devices or servers can become cumbersome and error-prone.
- **Security and Maintenance**: Ensuring your Node-RED instances are secure and up-to-date requires continuous monitoring, timely security patches, and ongoing maintenance. Keeping instances stable and secure can be time-consuming and requires dedicated resources to avoid vulnerabilities.
- **Scalability**: As your IIoT environment grows, scaling your Node-RED infrastructure to handle increased workloads can be challenging. Managing multiple distributed instances often leads to inconsistencies and difficulties in maintaining optimal performance across your entire system.
- **Edge Device Management**: Managing Node-RED instances on edge devices introduces additional complexity. Remote access, secure monitoring, and seamless updates become more difficult as your network expands, especially when dealing with a large number of edge devices.

FlowFuse addresses these challenges by providing a fully managed, secure, and scalable environment for your Node-RED instances. With FlowFuse, you can focus on building and deploying your IIoT solutions, while FlowFuse handles the infrastructure, updates, and scalability. This reduces operational overhead and ensures your instances remain up-to-date and secure.

For more information, read the article: [Transform Chaos into Control: Centralize Node-RED Management with FlowFuse](https://flowfuse.com/blog/2024/10/managing-node-red-instances-in-centralize-platfrom/).

## Migrating from Node-RED to FlowFuse

Before you start, make sure you have a FlowFuse Account created. Next, consider how your Node-RED instance needs to be deployed. Decide whether it should run on the edge device or as a cloud instance.

Running Node-RED on an edge device is ideal when your application flow needs direct access to hardware components, such as reading sensors or controlling actuators. This setup allows immediate data processing and control, crucial for applications requiring low latency responses.

On the other hand, if your use case involves monitoring or collecting metrics, such as through MQTT, without needing direct hardware interaction, and you primarily need to transform, contextualize, visualize, or automate repetitive tasks that don't require hardware interaction, a **Cloud Instance** may be more suitable. This option allows you to centralize data collection and processing, making it easier to manage and analyze data from multiple devices.

*Note: The instructions provided in this article also work for [self-hosted](https://flowfuse.com/docs/install/introduction/) FlowFuse environments. Just ensure that when following the steps, you're performing the actions within your self-hosted FlowFuse setup rather than the FlowFuse cloud platform.*

### Creating a Cloud Instance

The FlowFuse snapshot feature, available through the `@flowfuse/nr-tools-plugin` for self-managed Node-RED (a plugin that allows you to create snapshots from a self-managed Node-RED instance to the FlowFuse platform), However, it does not support direct device snapshots. Instead, you must first create a snapshot for the Cloud Instance and then assign it as the target for your device.

1. Navigate to the FlowFuse platform and log in to your account.
2. Select the application under which you want to manage your Node-RED instance. You can either choose the default application created with your account or click the "Create Application" button to create a new one.
3. Once inside the application, select "Add Instance."
4. Enter a name (or let the system generate one automatically), select the instance type, and choose the Node-RED version that matches your current setup.
5. Click "Create" to launch the instance.

### Creating a Device Instance and Connecting It to FlowFuse

If you need to run Node-RED on the edge device itself but want to manage it remotely, follow the steps below. Skip this step if your Node-RED Application flow can run on the cloud.

1. Navigate to the cloud instance you created above.
2. Go to the "Devices" tab by clicking on top "Devices" option and select "Add Device".
3. Once you click "Add Device", a device configuration popup will appear. Copy the command provided and save it for later.
4. Follow the steps to install the FlowFuse Device Agent on your device as given in this [documentation](https://flowfuse.com/docs/device-agent/install/).
5. Execute the saved command on the device.
6. Start the FlowFuse device agent by executing the following command:

```bash
   flowfuse-device-agent --port=1881
```

Running on port `1881` ensures it doesn't conflict with your locally running Node-RED instance, allowing both to run without issues.

### Creating Essential Backups Before Migration

Creating a cloud instance is essential for the migration process, regardless of whether your Node-RED instance will run on the device or on the cloud. As discussed earlier, the `@flowfuse/nr-tools-plugin` does not support creating direct snapshots for devices on the platform. Therefore, you must first create a snapshot for the cloud instance before deploying it to the device.

Follow these steps to create a cloud instance:

1. Install the `@flowfuse/nr-tools-plugin` into your Node-RED instance via the Palette Manager.
2. Once installed, open the "FlowFuse tools" tab in the sidebar.
3. Connect to your FlowFuse Cloud account by clicking the "Connect to FlowFuse" button.&#x20;:b&#x72;&#x2A;(If you're migrating to a self-hosted FlowFuse instance, ensure you configure the plugin with the correct URL. For detailed steps, refer to the [FlowFuse Node-RED Tools plugin Documentation](https://flowfuse.com/docs/migration/node-red-tools/#connecting-to-flowfuse))*.
4. A browser popup will appear, prompting you to log in to your FlowFuse account. Click "Allow" to grant permission.
5. After successful authorization, you'll be able to select your team and the associated instance from the "FlowFuse tools" tab.
6. Choose the team and FlowFuse instance you want to migrate to or the one you will use to take snapshots for your device.
7. Click the "+ Snapshot" button to create a snapshot. A popup will appear asking for a name and description. Enter the required details and click "Create".
8. Once the snapshot is created, it will be listed in the sidebar.
9. To verify, navigate to the FlowFuse platform, go to the FlowFuse Cloud instance you created earlier, and switch to the "Snapshots" tab. The snapshot you created should be visible there.

#### Backing Up System-level Environment Variables

While the snapshot captures flows, credentials, and environment variables at the flow and global level, it does not capture **process environment variables**, those set in the Node-RED `settings.json` file.

To get these variables, you can use the following flow to dump a list of all process environment variables into the debug window:

::render-flow
```json
[{"id":"3ed886625239a5d0","type":"function","z":"a87879f70edc3463","name":"process.env","func":"msg.payload = process.env\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[{"var":"process","module":"process"}],"x":650,"y":480,"wires":[["9ca3edbd6857853f"]]},{"id":"b35ef390a46ff129","type":"inject","z":"a87879f70edc3463","name":"List env vars","props":[{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":430,"y":480,"wires":[["3ed886625239a5d0"]]},{"id":"9ca3edbd6857853f","type":"debug","z":"a87879f70edc3463","name":"debug 3","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":880,"y":480,"wires":[]}]
```
::

1. Import and deploy the flow into your self-managed Node-RED instance.
2. Click the Inject Node's button

Once clicked, the flow will print all environment variables in the debug window. Identify the environment variables required for your flow and save them in a notepad for later use.

#### Setting System-Level Environment Variables in FlowFuse

Now that you have created the snapshots and copied the process environment variables, you need to set these variables in the Node-RED instance to avoid errors during deployment and smooth application running.

1. Go to the your FlowFuse Cloud/Device instance.
2. Open the Settings tab by clicking the "Settings" option at the top of the page, then select the Environment tab.
3. Add the environment variables one by one by clicking the "+ Add" button in the bottom-left corner.
4. After adding all the environment variables, click "Save."

For more information refer to [Using Environment Variables in Node-RED](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/)

#### Migrating Static Assets to FlowFuse Static Assets

When working with dashboards or files required in your Node-RED project, these files are typically stored locally and are always available, even if you restart or modify the flows. However, when migrating from Node-RED to a FlowFuse cloud environment, you'll need to manually migrate these files to the cloud-based Node-RED instances. To make this process easier, FlowFuse offers a static assets service feature at the instance level.

Here’s how you can migrate your assets:

1. Locate your static assets in your local system that are used in your Self-managed Node-RED instance from the snapshot we have taken.
2. Upload them one by one through the Instance "Static Assets" tab. For more information, refer to the [Static Asset Service documentation](https://flowfuse.com/docs/user/static-asset-service/).

Once you have migrated all your assets, you will be able to access them in the instance created in the FlowFuse cloud. Just ensure that after deploying the snapshot, the path set in the flow matches the static assets migrated to the FlowFuse instance.

### Deploying Snapshot for the Cloud/Device instance

Once the system-level environment variables are set and all static assets have been migrated ( if your Node-RED application flow is using static assets), you can deploy the captured snapshot to either the Cloud or Device instance.

1. Navigate to the FlowFuse Cloud instance where you created the snapshot by clicking "Hosted Instance" in the left sidebar and selecting the instance from the list.
2. Switch to the "Snapshots" tab at the top to locate the snapshot you created from the list.
3. On the right side of the snapshot, click the three-dot icon:
   - If you are migrating to the Cloud Instance, select &#x2A;*"Restore Snapshot"**
   - If you are migrating to a Device Instance, select &#x2A;*"Set as Device Target"**

Setting a device target will ensure that the snapshot will be deployed on all of the devices associated with this instance.

## Conclusion

Migrating from a self-managed Node-RED setup to FlowFuse is simple and offers significant benefits. By transitioning, you’ll reduce operational complexity, enhance security, and improve scalability. FlowFuse handles the infrastructure, so you can focus on building and optimizing your IIoT solutions, whether on edge devices or in the cloud.


# The Death of Point-to-Point: Why You Need a Unified Namespace

Manufacturing has changed significantly over the years, driven by new technology and the need for better communication between systems. In the past, point-to-point (P2P) connections, where devices communicate directly with each other, were the standard. However, as factories become more complex, P2P connections are no longer practical. This article explains why P2P connections are outdated and how a Unified Namespace (UNS) offers a better, more flexible solution.

## What are Point-to-Point Connections?

![Point-to-point connection](https://flowfuse.com/blog/2024/11/images/p2p.png){dataZoomable=""}*Point-to-point connection*

Point-to-point (P2P) connections are direct links between two systems or devices, allowing them to communicate with each other. They can be physical, like cables, or network-based (client-server), like a machine sending data to a server.

In a P2P setup, each connection links exactly two systems. These systems could be hardware, software, or even databases, exchanging data tailored to their needs.

For example, a machine might send performance data directly to a control system, or a sensor could send real-time measurements to a monitoring device. It’s a straightforward way to get systems talking, but as the number of devices grows, it becomes increasingly complex to manage.

## Why Point-to-Point Connections No Longer Work

As manufacturing moves toward more modern, interconnected approaches like Industry 4.0, the limitations of point-to-point connections become more apparent. Here's why P2P connections are no longer sufficient for today’s manufacturing environments:

### 1. Limited Data Sharing, Visibility, and Delayed Data

Point-to-point connections often lead to data silos, where devices or machines communicate only with their immediate hierarchy level. This isolation severely limits system-wide visibility, making it challenging to share critical data in real-time. Consequently, problems such as defective products, unexpected downtime, and the need for rework may go unnoticed until the damage is done.

In modern manufacturing, real-time data is indispensable for maintaining operational efficiency. However, point-to-point connections introduce significant delays, as data must traverse multiple layers, control systems (Level 1), supervisory control (Level 2), manufacturing execution systems (Level 3), and finally, higher-level management systems (Level 4) as outlined in the ISA-95 model. Each additional layer compounds latency, slowing response times and postponing the detection of issues, see also our post on [Why the Automation Pyramid slows you down](https://flowfuse.com/blog/2023/08/isa-95-automation-pyramid-to-unified-namespace/).

Without integrated, real-time data across teams, such as quality control, problems like defective parts may not be addressed promptly, leading to increased waste and customer dissatisfaction. The lack of seamless data sharing results in visibility gaps that impede decision-making, reducing the ability to act swiftly. In fast-paced environments, these delays not only hinder operational efficiency but also have a direct negative impact on profitability.

### 2. Inflexibility, Limiting Innovation, and Causing Downtime

Point-to-point connections create a rigid and inflexible network. When new technology or equipment is added, the entire system often requires reconfiguration, leading to significant downtime. For instance, if a new machine is introduced to the production line, many connections may need to be adjusted or re-established, which can temporarily halt production.

This downtime disrupts the flow of operations and makes it harder to implement new technologies quickly, slowing down innovation. As a result, manufacturers may struggle to stay competitive, as they can't integrate advancements like automation, real-time analytics, or AI without significant delays and costly interruptions.

### 3. High Costs Over Time and Maintenance Complexity

At first glance, point-to-point (P2P) connections may appear to be a cost-effective and straightforward solution. However, as systems expand, the true costs and complexities become increasingly apparent. In the automation pyramid (ISA-95 model), communication occurs across multiple hierarchical levels, with field devices interacting with controllers, controllers with SCADA, and SCADA with higher-level systems such as MES and ERP.

While this layered structure can keep connections orderly, it quickly becomes a logistical nightmare when scaling. Introducing new devices often triggers a cascade of necessary updates and reconfigurations across various levels. For example, adding a new field device typically requires adjustments to the controller, followed by updates to the SCADA system, creating a ripple effect that impacts the entire system.

This ongoing need for constant reconfiguration not only drives up costs but also introduces significant complexity in maintenance. As the system grows, so does the effort and resources required to manage it, making the P2P model inefficient and prohibitively expensive in environments that demand agility, scalability, and long-term sustainability. Ultimately, the simplicity of P2P connections gives way to an increasingly cumbersome and expensive maintenance burden, undermining its initial advantages.

### 4. Security Vulnerabilities

As the number of point-to-point connections increases, so does the risk of security breaches. Each connection represents a potential vulnerability, and if one connection in the network is compromised, the entire system becomes a target for attackers.

In large manufacturing environments, securing every individual connection becomes daunting. Any new device or system can introduce additional vulnerabilities, creating more opportunities for attackers to exploit. A compromised point-to-point connection could lead to production halts, loss of sensitive data, or even physical damage to machinery.

For example, imagine a situation where a hacker gains access to a machine’s control system through a compromised point-to-point connection. The attacker could intentionally cause a malfunction, halt production, or extract confidential information. The complexity of managing security for each connection makes it difficult to maintain a secure, reliable network.

### 5. Scalability Issues

One of the most significant drawbacks of P2P connections in manufacturing is their inability to scale efficiently. As production lines grow, so too do the number of devices, systems, and connections that must be managed. With a P2P architecture, each new device or system typically requires a direct, dedicated connection to each relevant part of the network. This creates a spaghetti network of interwoven links that becomes increasingly unwieldy and difficult to manage as the system expands.

In a traditional P2P setup, scaling the network means manually creating additional links, configuring them, and ensuring that the new connections fit seamlessly into the existing infrastructure. This process is time-consuming, error-prone, and highly resource-intensive, leading to increased complexity and longer downtimes as you scale.

When scaling a P2P network, changes made to one part of the system often trigger a ripple effect throughout the entire network. For instance, adding a new sensor may require updating the controller, the SCADA system, and even the Manufacturing Execution System (MES). This cascading need for updates across different layers of the network makes scaling more complicated and costly. Furthermore, the introduction of new devices means additional configuration and troubleshooting, often leading to disruptions in operations and extended downtimes while the new devices are integrated.

These issues compound when scaling across multiple production lines or sites, creating an increasingly complex web of p2p connections. As the number of devices grows, so does the risk of errors, network failures, and delays. This makes it difficult for manufacturers to respond to the growing demands of production while maintaining efficiency, reliability, and uptime.

## Unified Namespace: The Modern Solution

![Hub and Spoke Model](https://flowfuse.com/blog/2024/11/images/hub.png){dataZoomable=""}{width="400px"}
*Hub and Spoke Model*

A Unified Namespace (UNS) is a more straightforward way to connect devices and systems in a factory. Instead of having separate connections between each device, everything is connected through one central hub, which we call the **hub-and-spoke** model. This means devices don’t need to be directly linked to each other, making the system easier to manage and maintain; for more information on Unified Namespace, read our article: [Introduction to unified namespace](https://flowfuse.com/blog/2023/12/introduction-to-unified-namespace/).

With a UNS, adding new devices or systems becomes straightforward. Rather than setting up multiple direct connections, like in a point-to-point system, new devices (spokes) connect to the central hub. This reduces the complexity of growing your system and eliminates downtime. If equipment is replaced or updated, only that device needs to be reconnected to the hub rather than reconfiguring the entire network.

A UNS also improves data sharing. All data is collected in one place, so any system that needs it can access it in real time. This leads to quicker decisions and faster responses to problems. With fewer connections to manage, the costs of maintaining the system are lower. Plus, the central hub makes the whole system more secure, as fewer direct connections need to be protected.

![Publish-Subscribe Archtecture](https://flowfuse.com/blog/2024/11/images/pub-sub.png){dataZoomable=""}*Publish-Subscribe Archtecture*

We use a &#x2A;*publish-subscribe (pub/sub)** architecture to implement a hub-and-spoke model in a UNS. In this architecture, devices, systems send data to a central broker, and other devices can subscribe to the data they need. This approach eliminates the need for a complex network of point-to-point connections, making it easier to scale, update, and maintain the system.

This model addresses all the significant problems of point-to-point connections. For more information on how pub/sub solves these problems or why UNS needs pub/sub, read the article: [Why UNS Needs Pub/Sub](https://flowfuse.com/blog/2024/11/why-pub-sub-in-uns/).

[MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/) is a widely used for implementing the publish-subscribe model. It is lightweight, efficient, and works well in manufacturing environments where network reliability can be inconsistent.

![Unified Namespace](https://flowfuse.com/blog/2024/11/images/nr-in-uns.png){dataZoomable=""}*Unified Namespace*

To simplify the creation of a UNS in your manufacturing environment, [FlowFuse](https://flowfuse.com) provides an integrated MQTT broker service. The platform makes building, scaling, and managing Node-RED solutions easy. It supports seamless connections between devices, services, and APIs using over 5,000 community-contributed nodes for data collection. FlowFuse also enables efficient data transformation and visualization with a low-code approach, remote management of edge devices, and team collaboration on projects. With everything centralized on one platform, FlowFuse offers high security, scalability, and availability to optimize and maintain your system effectively.

Get started with this article [Building UNS with FlowFuse](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/).

## Summary

Due to complexity, high maintenance costs, and security risks, point-to-point (P2P) connections are becoming less effective in modern factories. A Unified Namespace (UNS) solves these problems by connecting devices through a central hub, making managing, scaling, and securing systems easier. UNS improves data sharing and reduces downtime. Tools like FlowFuse make it simple to set up and manage a UNS, offering a more efficient and flexible solution for manufacturing.


# Why UNS needs Pub/Sub

As the manufacturing industry evolves and becomes increasingly connected through the Industrial Internet of Things (IIoT), the concept of a Unified Namespace (UNS) has emerged as a critical architecture for centralizing and organizing data. UNS serves as a central reference point where all operational data, from machines to the enterprise, can be accessed in a consistent and structured way. Over time, more and more manufacturers have adopted UNS to simplify data integration and improve real-time visibility across systems.

If you're unfamiliar with UNS, please read our [Introduction to Unified Namespace](https://flowfuse.com/blog/2023/12/introduction-to-unified-namespace/) for a basic understanding of UNS.

If you're familiar with or already using a UNS, you might be asking: **Why does a UNS need Pub/Sub**? Here, we’ll explore how combining the Pub/Sub model with a Unified Namespace can help manufacturers streamline data flow, reduce latency, and enable more responsive and scalable operations.

## What is Pub/Sub?

Before discussing why Publish/Subscribe (Pub/Sub) is essential for a UNS, let's first define the Pub/Sub model.

![Publish Subscribe Model](https://flowfuse.com/blog/2024/11/images/pub-sub.png){dataZoomable=""}*Publish Subscribe Model*

The Pub/Sub model is a way for systems to communicate where one component, called the publisher, sends messages to a central system ( Broker such as [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/), [RabitMQ](https://flowfuse.com/node-red/protocol/amqp/), and [Kafka](https://flowfuse.com/blog/2024/03/using-kafka-with-node-red/) ), and other components, called subscribers, receive those messages. The publisher doesn’t need to know who the subscribers are, and the subscribers don’t know who the publishers are. The central system, or broker, ensures the right messages go to the right subscribers based on their interests.

Additionally, it’s important to note that the roles of publisher and subscriber are not mutually exclusive. A component can act as a publisher in one context, sending messages to the broker, and as a subscriber in another, receiving messages from the broker.

## Why Does a UNS Need Pub/Sub?

Now that you have a basic understanding of Pub/Sub, let’s dive into why this architecture is essential for a Unified Namespace.

### Decoupling Producers and Consumers with Flexible Communication

In traditional manufacturing setups, various systems and machines often operate in silos, requiring point-to-point connections for communication. This means each device or system must be directly linked to others, which quickly becomes complex and cumbersome as the number of systems grows. Point-to-point integrations are hard to scale because each new device needs a dedicated connection. This not only makes data harder to access but also blocks innovation by creating dependencies between systems.

To learn more about how point-to-point systems restrict innovation, please read the article: [Why the Automation Pyramid Blocks Digital Transformation](https://flowfuse.com/blog/2023/08/isa-95-automation-pyramid-to-unified-namespace/)

The Pub/Sub model provides a more scalable solution. In this model, publishers (such as IoT devices or machines) generate data and send it to a central system. Subscribers (other systems, applications, or users) then receive only the data relevant to them. Crucially, the publishers and subscribers do not need to know about each other, relying instead on a central Namespace to distribute the data efficiently.

By using Pub/Sub in a UNS, industries can create a single reference point for all data, enabling systems to subscribe to the data streams they need, without direct connections to every other system. For example, a production line monitoring system can easily access data from temperature sensors, pressure gauges, and robotic arms without the need for complex point-to-point integrations.

Unlike point-to-point systems, the Pub/Sub model allows for flexible communication, whether one-to-one, one-to-many, or many-to-many, without the need for direct connections between each system. This flexibility ensures that as your factory evolves, new devices and applications can easily be integrated into the UNS, driving innovation.

### Event-driven and Asynchronous Communication

The Pub/Sub model is particularly well-suited for event-driven architectures, where systems react to changes in data rather than periodically polling for updates. This is important in environments where responsiveness is key, such as in predictive maintenance, supply chain optimization, or automated decision-making.

For instance, a predictive maintenance system can subscribe to real-time sensor data from machines in a UNS. When the system detects an anomaly (e.g., a machine vibration out of normal parameters), it can immediately trigger an alert or maintenance action. This type of asynchronous communication is more efficient and scalable than synchronous polling or direct communication between producers and consumers.

### Less Delay, More Efficiency

In industries where IIoT-enabled operations are prevalent, real-time data is essential for effective decision-making. Traditional systems often introduce delays due to multiple layers of data collection, storage, and processing. These delays can result in inefficiencies such as slow machine adjustments, missed production targets, or equipment failures.

The Pub/Sub model reduces latency by immediately pushing data to subscribers as soon as it’s available. There’s no need for systems to poll or wait for periodic updates. Instead, they can respond to real-time events as soon as they occur.

For instance, in a smart factory, if a machine’s temperature exceeds a threshold, a maintenance system could instantly react by scheduling a technician, triggering an alert, or even pausing operations. Without Pub/Sub, the system would have to rely on polling mechanisms, which are less efficient and often introduce unnecessary delays.

In real-time environments, these immediate actions can make the difference between preventing costly downtime or catching a problem too late.

### Easy to Scale as You Grow

Manufacturers are always expanding, whether by adding more machines to the production line, introducing new automation systems, or scaling up to handle more products or more data. Scaling traditional systems to keep up with this growth can be complex and costly, especially when new devices or technologies need to be integrated.

The beauty of Pub/Sub is that it scales effortlessly. When new machines or sensors are introduced, they simply publish their data to the namespace. No complex reconfiguration or integration is required. Similarly, if a new application needs to access this data, it can simply subscribe to the relevant streams.

For example, consider a car manufacturer adding new robotic arms to the production line. These robots can publish real-time performance data, such as arm movement speeds, energy consumption, and fault alerts, directly into the UNS. The factory’s existing data systems can then subscribe to this new data without requiring changes to the entire system, making integration quick and cost-effective.

This level of scalability helps manufacturers keep up with growth without worrying about complex system upgrades or slowdowns.

### Making Your Systems More Reliable

In manufacturing, system downtime is costly. However traditional, monolithic systems often rely on point-to-point connections, which can create vulnerabilities. If one part of the system goes down, it can bring down other systems or halt production entirely.

With a Pub/Sub architecture, this is less of a concern. If one publisher (like a sensor or machine) fails or goes offline, the rest of the systems can continue operating as normal. Other sensors or machines can continue to send their data, and subscribers can still receive real-time updates from other sources.

Consider a delivery system in a Point-to-Point setup, all vehicles send data directly to a central dispatch system. If the central dispatch system fails, data from all vehicles is lost. In a Pub/Sub setup, vehicles send their data to a central namespace instead of directly to the dispatch system. If the central dispatch system fails, it doesn’t result in data loss. Vehicles can still send their updates.

This decoupling of systems improves resilience, meaning that your factory can continue running smoothly even if individual components experience issues.

While the broker is a critical part of the Pub/Sub system and can also go down, this risk can be mitigated. Strategies such as high-availability brokers, failover mechanisms, and clustered deployments can be implemented to prevent downtime and ensure uninterrupted data flow.

### Taking Action

As we've discussed, the Pub/Sub model is a game-changer for Unified Namespace architectures in the manufacturing industry. One of the most widely adopted protocols for implementing Pub/Sub is MQTT (Message Queuing Telemetry Transport). MQTT is known for its simplicity, efficiency, and low-bandwidth requirements, making it an ideal choice for Industrial applications.

To help you leverage the power of MQTT in your manufacturing operations along with Node-RED, Flowfuse offers a robust MQTT broker service. Now, Flowfuse will not only help you build, scale, and manage Node-RED solutions, collaborate across teams, and manage edge devices, but it will also simplify your integration of IIoT data streams into your Unified Namespace. For more information on how our FlowFuse MQTT broker Service, read our [MQTT Broker Service Announcement](https://flowfuse.com/blog/2024/10/announcement-mqtt-broker/?utm_campaign=60718323-BCTA&utm_source=blog&utm_medium=cta%20mqtt%20announcement&utm_term=high_intent&utm_content=Why%20UNS%20needs%20Pub%2FSub).

Get started with this article [Building UNS with FlowFuse](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/).

## Conclusion

Integrating Pub/Sub with a Unified Namespace enhances manufacturing operations by enabling real-time data flow, reducing latency, and improving scalability. This combination ensures efficient, resilient, and future-ready systems, empowering manufacturers to stay competitive in the IIoT era.


# FlowFuse Cloud now available for free!

The new Free plan on FlowFuse Cloud will allow you to manage two remote instances using FlowFuse Device Agent, completely free of charge, forever! The new plan also provides Device Auto Snapshots, so any changes to your Node-RED flows running on your devices are backed up automatically.

:product-update-note

FlowFuse is an industrial data platform that enables engineers to build, manage, scale, and secure their Node-RED solutions for digitalizing processes and operations. More fundamentally though, it's a great platform to manage multiple instances of Node-RED.

::div{.blog-update-notes}
After careful consideration, we've decided to withdraw the free plan. You can still sign up for a 30-day trial to experience all that FlowFuse has to offer.
::

## What's Included?

Whether you're running multiple Node-RED instances at home for Home Automation, or running thousands of Node-RED instances in your factory, FlowFuse provides an easy-to-use, centralised view of your Node-RED instances, making it easy to manage and monitor them in one place.

In our new free tier on FlowFuse Cloud you get:

- 2 x Remote Node-RED Instances, managed through the FlowFuse [Device Agent](https://flowfuse.com/docs/device-agent/quickstart)
- Version control for your Node-RED flows with FlowFuse's [Snapshots](https://flowfuse.com/docs/user/snapshots/#introduction)
- Remote access to your Node-RED instances through FlowFuse Cloud, utilizing the Device Agent's [Developer Mode](https://flowfuse.com/docs/device-agent/quickstart/#developer-mode)

## Getting Started

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

### Create Your Free Team

To create a free team, simply [sign up to FlowFuse Cloud](https://app.flowfuse.com/create){rel="&#x22;nofollow&#x22;"}.

Once you've filled in your details, you'll be presented with the option to choose your team type. Select the "Free" option, and you're good to go.

![](https://flowfuse.com/blog/2024/12/images/onboarding-team-type.png){dataZoomable=""}&#x2A;Screenshot showing the UI for selecting your Team's type, when onboarding through on FlowFuse Cloud.*

### Remote Instances

When you create a Free team, an Application is created for you automatically. Applications in FlowFuse help you organise and group your resources, from Instances to DevOps Pipelines and Snapshots for Version Control. Within your new application, you can "register" your first Remote Instance.

A "Remote Instance" in FlowFuse is a just a term for an instance Node-RED, managed by FlowFuse, but running somewhere different from FlowFuse, e.g. on Edge hardware in a factory or your home. FlowFuse connects to these Remote Instances using the FlowFuse Device Agent, which is easy to setup and get running.

To get started with your Remote Instance, you need to complete two steps:

1. **Install Device Agent**: The FlowFuse Device Agent is installed onto the hardware where you want your Node-RED Instance to run.
2. **Add Your Remote Instance**: In the FlowFuse UI, add a new "Remote Instance", and connect to your hardware.

### Install Device Agent

Firstly, wherever you want your Node-RED to run, e.g. on a Raspberry Pi or your own Laptop, install the `flowfuse-device-agent` package:

#### Linux/MacOS

```bash
sudo npm install -g @flowfuse/device-agent
```

#### Windows

Issue the below command in an elevated command prompt:

```bash
npm install -g @flowfuse/device-agent
```

For alternative installation options and more details, please refer to our [documentation](https://flowfuse.com/docs/device-agent/).

### Connect Your Hardware to FlowFuse

To connect your Device Agent, in the FlowFuse Platform, click on the "Remote Instances" option in the left-hand menu, and then click the "Add Remote Instance" button.

Fill out the name, device type and select the application you've just created, and you'll be presented with the following:

![Screenshot showing the dialog with the one-time-code to connect your remote Node\_RED instance to FlowFuse](https://flowfuse.com/blog/2024/12/images/onboarding-device-registration.png){dataZoomable=""}*Screenshot showing the dialog with the one-time-code to connect your remote Node\_RED instance to FlowFuse*

The command presented is used to connect your device to FlowFuse. Run this where you just installed the `@flowfuse/device-agent` package. This will connect your remote Node-RED instance to the FlowFuse platform.

The final step to take is to then start running the device agent, which you can do by simply calling:

```bash
flowfuse-device-agent
```

### Developing on your Remote Instance

FlowFuse offers remote development capabilities, allowing you to edit your Node-RED flows directly, and securely, from the FlowFuse Cloud platform. This is done through "Developer Mode".

To get started with developing flows with your Remote Instance, simply select your newly created Instance in the FlowFuse UI, toggle on 'Developer Mode", and click "Open Editor"!

### Version Control with Snapshots

FlowFuse makes version control easy with [Snapshots](https://flowfuse.com/docs/user/snapshots/#introduction). The new Free plan includes Device Auto Snapshots, which will automatically create a snapshot any time a flow is deployed to your device.

## What Else is New?

In addition to the Free plan, we've also added two new views to the FlowFuse platform:

- **Pipelines**: This view provides a way to manage all of your DevOps Pipelines, making it even easier to manage your development, testing, staging and production environments.
- **Bill of Materials**: This view provides a way to manage all of your Node-RED dependencies, making it easy to see what versions of nodes are being used across all of your Node-RED instances.

For a full list of everything that went into our 2.12 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.12.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try FlowFuse

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.


# Streamlining Node-RED Collaboration with FlowFuse

A few weeks ago, we discussed how [FlowFuse centralizes edge device and Node-RED management](https://flowfuse.com/blog/2024/10/managing-node-red-instances-in-centralize-platfrom/), as well as its [security features](https://flowfuse.com/blog/2024/10/exploring-flowfuse-security-features/). Now, we're focusing on another key benefit of FlowFuse, making collaboration easier for teams in industrial environments.

As more manufacturing companies use FlowFuse for edge device management, data pipelines, and bridging IT-OT systems, the platform is becoming a key tool for handling complex data operations. Collaboration is critical in manufacturing environments with thousands of devices and data flows. FlowFuse accelerates industrial data operations by simplifying real-time collaboration while ensuring security and scalability.

Now, let’s look at how FlowFuse makes collaboration effortless. With features like centralized management, real-time updates, and easy sharing, FlowFuse helps teams stay on the same page, whether working on the same flow or across multiple projects. The platform eliminates the usual pain points of collaboration, allowing teams to quickly deploy, modify, and scale Node-RED solutions confidently while maintaining control and security.

## Laying the Foundation for Better Collaboration with Centralization

Effective collaboration starts with everyone having access to the same interface and information. When team members work with different versions of flows or data, things can easily get out of sync, making collaboration difficult.

This is exactly why centralized management is so crucial. With FlowFuse, everything (your Node-RED Instances, edge devices, settings, and data) is in one place. Everyone on your team sees the same interface, accesses the same up-to-date information, and works from the same set of resources. There’s no more hunting for the correct version or trying to sync up tools.

Everything in one place means fewer mistakes, fewer mix-ups, and much easier collaboration. Whether you're working in a single instance or managing a whole network of edge devices, FlowFuse makes it easy to stay aligned. You can move quickly and confidently without worrying about missing something important.

![List of all Node-RED instances organized centrally within your team.](https://flowfuse.com/blog/2024/12/images/application-wise-instance-organization.jpeg){dataZoomable=""}&#x2A;A centralized view of applications with Node-RED instances organized under each application for easier management.*

![List of all Node-RED instances organized centrally within your team.](https://flowfuse.com/blog/2024/12/images/list-of-instances.jpeg){dataZoomable=""}&#x2A;A list of all Node-RED instances is displayed centrally, allowing team members to manage and access them easily.*

![All edge devices centralized for easy management.](https://flowfuse.com/blog/2024/12/images/edge-devices.jpeg){dataZoomable=""}&#x2A;A centralized view of edge devices, providing streamlined management for all devices within the platform.*

In short, centralization makes everything simpler. It’s the backbone of effective teamwork, ensuring everyone works from the same starting point. With FlowFuse, you don't have to worry about syncing, everything's already in sync for you.

If you want to dive deeper into how FlowFuse centralizes things, check out this article: [Managing Node-RED Instances in a Centralized Platform](https://flowfuse.com/blog/2024/10/managing-node-red-instances-in-centralize-platfrom/).

## Creating and Managing Teams

Collaboration begins with the right team setup. In FlowFuse, you can quickly [create a team](https://flowfuse.com/docs/user/team/#creating-a-new-team) and assign it a name. Once your team is set up, you can easily [invite members to join](https://flowfuse.com/docs/user/team/#adding-team-members). As mentioned earlier, all your Node-RED instances, edge devices, configurations, settings, and data are organized and centralized within that team.

However, simply creating a team and inviting members isn’t enough. Not all team members need access to all information, features, or controls. It’s essential to ensure that the right people have the right level of access to do their work effectively. Providing excessive access to members who don’t require it or who might lack the necessary expertise can lead to accidental changes or mistakes.

![Invite new members to your FlowFuse team by assigning roles and permissions.](https://flowfuse.com/blog/2024/12/images/inviting-member-to-team.jpeg){dataZoomable=""}&#x2A;A centralized view of edge devices, providing streamlined management for all devices within the platform.*

![FlowFuse team management interface displaying team members and their roles for streamlined collaboration control.](https://flowfuse.com/blog/2024/12/images/team-members-list.jpeg){dataZoomable=""}*A comprehensive list of team members with assigned roles and permissions*

This is where [FlowFuse’s Role-Based Access Control (RBAC)](https://flowfuse.com/blog/2024/04/role-based-access-control-rbac-for-node-red-with-flowfuse/) comes in. When inviting new team members, you can assign them specific roles, each with different permissions and access scopes. This ensures that each team member has the appropriate level of access based on their role, reducing the risk of unintended changes or disruptions.

You can later update roles to adjust permissions as your team, and projects evolve if needed. FlowFuse’s RBAC helps maintain control and security while empowering each team member to contribute effectively to the project.

## Real-Time Collaboration and Monitoring

Once team members have been invited, Node-RED instances have been created, and edge devices have been added by the team owner, FlowFuse's real-time collaboration capabilities come into play. Team members, whether they have owner or member roles, can work on the same project simultaneously. They can update flows, deploy them, and monitor real-time progress.

With FlowFuse, tracking who is working on which project and at what stage is easy. The platform lets you see who has opened the Node-RED editor you are working on, which flow they are working on, and even which specific node they are interacting with. This visibility ensures that team members are always aligned and that collaboration happens seamlessly without stepping on each other’s toes.

![A screenshot showing multiple users working on the same Node-RED flow in real time within FlowFuse, with live updates and visibility of each user's actions.](https://flowfuse.com/blog/2024/12/images/multiplayer-flowfuse.jpeg){dataZoomable=""}&#x2A;Multiple users collaborate on the same Node-RED flow in real-time within FlowFuse.*

For instance, if two members modify different parts of the same flow, they can do so without interrupting each other’s work. They’ll both be able to see each other's updates in real-time, ensuring the project moves forward smoothly. This collaborative approach enhances teamwork and helps avoid mistakes, as everyone has the information they need when needed.

In addition, FlowFuse’s real-time monitoring features allow you to track the status of edge devices, Node-RED instances, and overall system health. You can also monitor Node-RED logs for troubleshooting, ensuring no issue slips through the cracks as your team works together efficiently.

## Version Controlling

In any collaborative environment, accidental changes or conflicts are inevitable, especially when multiple team members are working on the same project. While collaboration is essential for progress, the ability to track changes, roll back versions, and understand who made what updates is critical for maintaining control and continuity.

FlowFuse provides robust version control features that make it easier to manage changes across your Node-RED flows. Whether you revert to a previous version of a flow, roll back accidental changes, or track updates over time, FlowFuse ensures that you never lose critical work.

To view the version history, navigate to your Node-RED Instance view and switch to the 'Version History' tab. Here, you’ll find two key sections:

- Timeline: This section displays a timeline of who deployed, what is updated, and for which flow and when. Each deployment automatically creates a snapshot of your Node-RED instance. You can easily roll back to any previous version by clicking the three-dot icon on the right and selecting Restore Snapshot. You also have the option to compare the current version of your Node-RED instance with previous snapshots, download it, and more.

![A screenshot displaying the version history timeline in FlowFuse, showing deployment snapshots and the ability to track and roll back changes in Node-RED instances.](https://flowfuse.com/blog/2024/12/images/version-history-timeline.jpeg){dataZoomable=""}&#x2A;A version history timeline shows deployment and changes made in flows, making it easy to track updates and revert to previous versions.*

Snapshots: The second tab, Snapshots, provides a clean, list-style interface that shows all available snapshots. Unlike the timeline view, this section focuses solely on snapshots without the detailed deployment history. You can upload or download snapshots and even create a snapshot of your instance at any time by clicking the Create Snapshot button.

![A screenshot of the snapshots interface in FlowFuse, showing a list of available snapshots that can be restored or compared.](https://flowfuse.com/blog/2024/12/images/version-history-snapshots.jpeg){dataZoomable=""}&#x2A;The snapshots list interface in FlowFuse provides an organized view of all available snapshots for easy restoration or comparison.*

This version control functionality allows you to manage and recover Node-RED instances seamlessly, ensuring that your team can collaborate effectively without the risk of losing or overwriting important work.

## Shared Flow Library

When working on projects, it's common to develop reusable flows that can save time and effort for the entire team. For example, you might create a flow to calculate Overall Equipment Efficiency (OEE) or other valuable flows that can be reused across multiple projects.

FlowFuse makes this process easy with the [Shared Flow Library](https://flowfuse.com/docs/user/shared-library/). This feature allows owners and members to export significant flows and store them in a shared library, making them available to all team members. Once a flow is added to the library, anyone within the same team can import and use it in any Node-RED instance whenever needed.

![A screenshot of the Shared Flow Library in FlowFuse, showing a list of flows available for import and reuse by team members in any Node-RED instance.](https://flowfuse.com/blog/2024/12/images/shared-lib-import.jpeg){dataZoomable=""}&#x2A;Shared Flow Library in FlowFuse displays a list of reusable flows that team members can import and use across multiple Node-RED instances.*

This shared approach streamlines development, eliminates redundant work, and ensures project consistency, ultimately saving time. Whether it’s a reusable function, a typical configuration, or a flow for recurring tasks, FlowFuse’s Shared Flow Library enables your team to easily access and integrate these resources, boosting productivity and fostering better collaboration.

## Audit Logs

Accountability is essential when multiple team members collaborate on complex industrial projects. FlowFuse offers comprehensive Audit Logs to track every action taken within the platform. This feature provides a detailed record of who made which changes, when those changes were made, and the specifics of each action.

![A screenshot of the audit logs in FlowFuse, displaying detailed records of changes made by users, ensuring accountability and security within the platform.](https://flowfuse.com/blog/2024/12/images/application-audit-logs.jpeg){dataZoomable=""}&#x2A;Audit logs in FlowFuse, tracking every action taken within the platform to ensure accountability and transparency among team members.*

With Audit Logs, you can easily trace who deployed a flow, modified settings, or interacted with assets. This transparency ensures that all team members are accountable for their actions, enhancing security and reducing the risk of errors or unauthorized changes.

Audit Logs are especially valuable for troubleshooting. They allow you to pinpoint when issues arise and identify who made changes that could have contributed to the problem, providing crucial context for resolution.

For more information on using Audit Logs effectively, refer to our documentation on [Audit Logs in FlowFuse](https://flowfuse.com/docs/user/logs/#audit-log).

These are just a few of the features we’ve covered. FlowFuse has many more tools and capabilities that can further enhance collaboration, streamline workflows, and optimize your industrial operations.

In summary, FlowFuse is a platform that streamlines collaboration on Node-RED projects. Centralizing your Node-RED instances, devices, and data ensures that everyone on your team is aligned and has access to the same resources. Features like real-time updates, role-based access, version control, and audit logs make collaborating easier, staying secure, and avoiding errors easier. Whether you're managing small flows or large-scale industrial systems, FlowFuse helps your team work together more efficiently and effectively.

With FlowFuse, factories can achieve faster, safer, and more scalable collaboration on data pipelines, edge device management, and IT-OT integration.

[PowerWorkplace relies on this same collaborative workflow to rapidly develop and deploy tailored building management solutions to customer premises](https://flowfuse.com/customer-stories/node-red-building-management/), while giving security auditors confidence in the platform underneath.

## Up Next

Explore more resources and deepen your understanding of FlowFuse with these articles:

- **[Managing Node-RED Instances in a Centralized Platform](https://flowfuse.com/blog/2024/10/managing-node-red-instances-in-centralize-platfrom/)**:br
  Learn how to effectively manage Node-RED instances in a centralized environment with FlowFuse, simplifying deployment and ensuring scalability.
- **[Exploring FlowFuse Security Features](https://flowfuse.com/blog/2024/10/exploring-flowfuse-security-features/)**:br
  Discover the security tools and features built into FlowFuse to help protect your industrial data and keep your systems secure.
- **[Building on FlowFuse: Working with Devices](https://flowfuse.com/blog/2024/07/building-on-flowfuse-devices/)**:br
  Dive into how FlowFuse supports device management, enabling you to build, deploy, and monitor edge devices more efficiently.


# How to Bridge Modbus to MQTT: Step-by-Step Guide

Converting Modbus to MQTT unlocks the value trapped in legacy industrial equipment. Industrial facilities worldwide face a persistent challenge: their Modbus-based sensors, PLCs, and controllers generate valuable operational data, but that data remains isolated in local control networks, unable to feed modern cloud analytics, remote dashboards, or predictive maintenance systems.

:product-update-note

We've built Modbus to MQTT bridges for manufacturing plants ranging from small production lines to enterprise-scale facilities, and the root problem is always the same protocol mismatch. Modbus requires a master-slave architecture with polling, one device requests data, another responds. MQTT enables publish-subscribe messaging, devices push data to a central broker where any authorized application can subscribe. These are fundamentally incompatible communication patterns.

The proven solution is protocol bridging with Node-RED. This guide shows you how to build a reliable Modbus to MQTT gateway that reads holding registers from your devices, transforms raw sensor readings into human-readable formats, and publishes structured data to a Unified Namespace using FlowFuse's integrated MQTT broker. You'll bridge the OT/IT gap and enable cloud integration, real-time monitoring, and data-driven decision-making across your operations.

## Why Bridge Modbus to MQTT?

Modbus handles local device communication effectively. A PLC polls sensors, reads holding registers, writes control signals, standard automation workflows that have proven reliable for decades. The limitation appears when you need that same data elsewhere: in a cloud database, on a remote dashboard, or feeding a predictive maintenance algorithm.

The constraint is architectural. Modbus requires a master-slave relationship. One device initiates requests, others respond. You can't have multiple systems independently accessing the same Modbus device without coordination, and you can't push data, only pull it through polling. This creates the operational technology (OT) and information technology (IT) integration gap.

MQTT removes these constraints through its broker-based architecture. Devices publish data once to the broker. Any authorized system, whether on-premises or cloud-based, subscribes to relevant topics and receives updates. No polling loops, no master-slave coordination, no point-to-point connections to manage.

This is where the [Unified Namespace](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/) concept becomes practical. Instead of data scattered across disconnected Modbus networks, PLCs, and SCADA systems, you establish a single MQTT broker as the central data hub. All operational data flows through standardized topics organized by facility hierarchy: `enterprise/site/area/line/equipment`. Applications consume what they need through subscriptions.

Consider a production line running legacy Modbus equipment, VFDs controlling motor speeds, pressure transmitters monitoring hydraulic systems, temperature sensors on critical bearings. Historically, this data stays within the local control network. Bridge it to MQTT, and suddenly the maintenance team accesses real-time vibration data on their tablets, the operations dashboard displays line efficiency metrics, and the cloud analytics platform builds predictive models from historical trends, all from the same data stream.

FlowFuse provides both the Node-RED runtime for building these bridges and the MQTT broker infrastructure for the Unified Namespace. The integration is straightforward: Node-RED flows poll Modbus devices and publish to FlowFuse's MQTT broker, where any authorized application can subscribe.

## How to Bridge Modbus to MQTT

Let's look at the steps to bridge Modbus data to MQTT using FlowFuse, leveraging Node-RED's capabilities. The process involves retrieving data from a Modbus device (For Practical example, we are using OpenSim to simulate Modbus data), transforming and processing the data (e.g., scaling raw sensor data into human-readable formats), and sending it to your Unified Namespace.

![Bridging Modbus Data to MQTT using Node-RED](https://flowfuse.com/blog/2024/12/images/bridging-modbus-data-to-mqtt.png){dataZoomable=""}*Bridging Modbus Data to MQTT using Node-RED*

## Prerequisites

Before you start, make sure you have:

- **Modbus data source**: An actual Modbus device or a simulator like ModSim.
- **Node-RED Instance**: The easiest and production-ready option is FlowFuse, run Node-RED on edge devices, manage and build flows remotely with your team. Deploy, scale, and secure hundreds or thousands of instances with built-in team collaboration, version control, and production-grade features. [Sign up here](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"} and follow [this guide to run Node-RED with FlowFuse on your edge device](https://flowfuse.com/blog/2025/09/installing-node-red/). Alternatively, install Node-RED locally on hardware with access to your Modbus network.
- **MQTT Broker**: You need broker connection details (host, port, credentials). If you're using FlowFuse Pro or Enterprise, there's an integrated broker at `broker.flowfuse.cloud`, just create a client in the platform and you're done.

### Step 1: Collect Data from Modbus Devices

The first step is to collect data from your Modbus devices. To do this, you'll need to run Node-RED on your Device. If your Modbus device communicates via a serial port, Node-RED will need access to that port, which you can manage with the appropriate configuration. If you're using Modbus TCP and both Node-RED and your Modbus device are on the same network, the connection is straightforward.

**Step 1.1: Running the FlowFuse device agent on your edge device**

To run Node-RED on your edge device with just a few simple steps, you can use the [FlowFuse Device Agent](https://flowfuse.com/blog/2025/09/installing-node-red/). This allows you to run Node-RED locally and also connect it to FlowFuse Cloud for remote monitoring and management, making it easier to keep track of your devices and workflows from anywhere.

**Step 1.2: Install Modbus Nodes**

While Node-RED doesn't include Modbus nodes by default, adding them to your palette is simple. Installing the necessary Modbus nodes from the Node-RED library will enable communication with your Modbus devices, whether they’re connected via serial or TCP. This step ensures you can start reading data from your Modbus devices and processing it for further integration.

1. Open the **Palette Manager** by clicking the menu icon in the top-right corner of Node-RED and selecting **Palette Manager**.
2. In the Palette Manager, search for `node-red-contrib-modbus` in the search bar.
3. Click **Install** to add the Modbus nodes to your Node-RED environment.
4. Once installed, the nodes appear in the left-side palette under the **Modbus** category. These nodes will allow you to interact with Modbus devices in your flow.

**Step 1.3: Configure the Modbus Connection**

Next, you'll need to configure the Modbus connection based on your device type. Modbus devices can communicate using two primary protocols: **Modbus RTU** (over serial) or **Modbus TCP** (over Ethernet/Wi-Fi). The specific choice depends on the type of Device you are working with.

:cta-image{alt="Arch Systems scales automation across complex manufacturing environments with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/arch-systems-book-demo.png"}

1. Drag a **Modbus Read** node onto your Node-RED Canvas.
2. Double-click on the **Modbus Read** node to open its configuration.
3. In the configuration window:
   - Enter the **Unit ID** (this is the device address, typically **1**, but it may vary depending on your device).
   - Choose the **Function** you need, such as **Read Holding Registers**, **Read Input Registers**, etc. (this depends on the type of data you want to read).
   - Specify the **Start Address** (the address of the first register you want to start reading).
   - Set the **Quantity** (the number of registers to read).
   - Specify the **Poll Rate** (e.g., how often you want to collect data, such as every 1 second).
4. In the **Server*&#x2A; field, click the &#x2A;*+**&#x62;utton to add a new Modbus server, and select the type.
   - For **Modbus TCP**: Enter the **IP address** and **Port** (the default Modbus TCP port is **502**).
   - For **Modbus RTU**: If you're using a serial connection, you'll need to specify the serial port (such as `/dev/ttyUSB0` on Linux or `COM1` on Windows), as well as the baud rate and other serial settings.
   - Set the **Unit ID** (again, this should match the Unit ID you entered earlier).

![Image showing Modbus node configuration for reading holding registers](https://flowfuse.com/blog/2024/12/images/modbus-connection-configuration.png){dataZoomable=""}*Image showing Modbus node configuration for reading holding registers*

![Image showing Modbus client node configuration](https://flowfuse.com/blog/2024/12/images/modbus-connection-config.png){dataZoomable=""}*Image showing Modbus client node configuration*

5. Once the connection details are filled in, click **Add** to save the configuration, then click **Done**.

**Step 1.4: Test the Modbus Connection**

After configuring the connection, it's time to test the data collection.

1. Drag a **Debug** node onto the canvas.
2. Connect the **Modbus Read** node's output to to the input of **Debug** node.
3. Click **Deploy** in the top-right corner of Node-RED to deploy your flow.
4. Open the **Debug Panel** on the right side of the Node-RED interface. If the connection is successful, you should see the raw data from your Modbus device in the Debug Panel.

If no data appears, check the connection settings (IP address, Unit ID, port, etc.) and ensure your Modbus device is correctly configured and accessible. If you use a simulator like ModSim, ensure it’s running and properly configured to send data.

For more information on using Modbus with Node-RED, please read our tutorial on [Using Modbus with Node-RED](https://flowfuse.com/node-red/protocol/modbus/).

If you prefer a video explanation, [Kurt Braun](https://www.linkedin.com/in/wago-kurt-braun/){rel="&#x22;nofollow&#x22;"} from WAGO demonstrates how to collect Modbus data using Node-RED in FlowFuse:

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: Bridging Modbus to MQTT with Node-RED
videoid: PdVdGg__zUM
---
::

### Step 2: Transforming Modbus Data for UNS

After collecting data from your Modbus device, the next step is transforming it into a usable format for cloud-based IoT applications. Modbus data typically comes in raw register values, and you may need to convert these values into human-readable formats like temperature, pressure, or other measurements.

Let's walk through the transformation process step by step.

**Step 2.1: Parsing and Converting Raw Modbus Data**

Modbus devices often return data in registers that need to be interpreted. For example, a temperature sensor might return a register value like 350, which represents 35.0°C if the sensor stores values in tenths of degrees.

![The ModSim interface, generating simulated Modbus data](https://flowfuse.com/blog/2024/12/images/modsim.png){dataZoomable=""}*The ModSim interface, generating simulated Modbus data*

Here’s an example of the raw Modbus data I am receiving from ModSim: `[225, 1013, 29, 50, 603]`. These values represent the following:

- `225`: Temperature (in tenths of degrees, which would be 22.5°C)
- `1013`: Part 1 of the pressure value (higher register)
- `29`: Part 2 of the pressure value (lower register)
- `50`: Vibration (in tenths of degrees, which would be 5g)
- `603`: Humidity (in tenths of degrees, which would be 60.3%)

We must convert these raw register values into human-readable formats for cloud integration. For instance, we divide the temperature and vibration by 10 to get the actual values in degrees Celsius and g, respectively, and similarly for other parameters like humidity. For pressure, the higher and lower register values are combined to compute the complete value accurately.

To determine how to process raw Modbus data, such as dividing by a specific value, concatenating, or applying other transformation formulas, refer to the manual of the sensor you use for specific instructions.

In Node-RED, you can use various nodes for transformation. You can choose the [Function node](https://flowfuse.com/node-red/core-nodes/function/) for advanced processing, the [Change node](https://flowfuse.com/node-red/core-nodes/change/) for simpler operations, or the [Template node](https://flowfuse.com/node-red/core-nodes/template/) for defining schemas. For more complex data parsing scenarios, such as handling multiple data types (floats, 32-bit integers, strings), dealing with big-endian/little-endian conversions, or performing byte swapping, consider using the `node-red-contrib-buffer-parser` node. This specialized node simplifies parsing Modbus buffers into various data formats without writing custom code. Learn more in our guide on [using Buffer Parser for industrial data](https://flowfuse.com/blog/2025/12/node-red-buffer-parser-industrial-data/). In this article, I will demonstrate a low-code approach using the Change node to process the data cleanly.

Additionally, for better organization and accessibility, I will send each metric separately and include additional metadata such as the `timestamp` and `unit`.

**For Temperature**:

1. Drag a **Change** node onto the canvas.
2. Double-click the node to open its configuration panel.
3. Set the following in the **Set**rules:
   - Set `msg.data` to `msg.payload`.
   - Set `msg.payload` to `{}`.
   - Set `msg.payload.timestamp` to the timestamp function of the Change node.
   - Set `msg.payload.value` to `data[0] / 10`.
   - Set `msg.payload.unit` to `'c'`.

![Image showing the Change node rules transforming temperature data](https://flowfuse.com/blog/2024/12/images/temperature-data-tranformation.png){dataZoomable=""}*Image showing the Change node rules transforming temperature data*

4. Click **Done** to save the configuration.
5. Connect the first output of the **Modbus Read** node to the input of this **Change** node.

**For Pressure**:

1. Drag another **Change** node onto the canvas.
2. Double-click the node to open its configuration panel.
3. Set the following in the **Set**rules:
   - Set `msg.data` to `msg.payload`.
   - Set `msg.payload` to `{}`.
   - Set `msg.payload.timestamp` to the timestamp function of the Change node.
   - Set `msg.payload.value` to `$number($string(data[1]) & $string(data[2]))` as a JSONata expression.
   - Set `msg.payload.unit` to `'ppm'`.

![Image showing the Change node rules transforming pressure data](https://flowfuse.com/blog/2024/12/images/pressure-data-transformation.png){dataZoomable=""}*Image showing the Change node rules transforming pressure data*

4. Click **Done** to save the configuration.
5. Connect the first output of the **Modbus Read** node to the input of this **Change** node.

**For Vibration**

1. Drag another **Change** node onto the canvas.
2. Double-click the node to open its configuration panel.
3. Set the following in the **Set**rules:
   - Set `msg.data` to `msg.payload`.
   - Set `msg.payload` to `{}`.
   - Set `msg.payload.timestamp` to the timestamp function of the Change node.
   - Set `msg.payload.value` to `data[3] / 10` as a JSONata expression.
   - Set `msg.payload.unit` to `'g'`.

![Image showing the Change node rules transforming vibration data](https://flowfuse.com/blog/2024/12/images/vibration-data-transformation.png){dataZoomable=""}*Image showing the Change node rules transforming vibration data*

4. Click **Done** to save the configuration.
5. Connect the first output of the **Modbus Read** node to the input of this **Change** node.

**For Humidity**

1. Drag another **Change** node onto the canvas.
2. Double-click the node to open its configuration panel.
3. Set the following in the **Set**rules:
   - Set `msg.data` to `msg.payload`.
   - Set `msg.payload` to `{}`.
   - Set `msg.payload.timestamp` to the timestamp function of the Change node.
   - Set `msg.payload.value` to `data[4] / 10` as a JSONata expression.
   - Set `msg.payload.unit` to `'%'`.

![Image showing the Change node rules transforming humidity data](https://flowfuse.com/blog/2024/12/images/humidity-data-transformation.png){dataZoomable=""}*Image showing the Change node rules transforming humidity data*

4. Click **Done** to save the configuration.
5. Connect the first output of the **Modbus Read** node to the input of this **Change** node.

Once you have configured and connected all the Change nodes, add a **Debug** node to each Change node's output to verify that the transformed data appears as expected. Deploy the flow, then check the output in the Debug Panel to ensure that each metric is correctly formatted with the appropriate timestamp, value, and unit.

### Step 3: Publishing Modbus Data to MQTT

After transforming the Modbus data into a human-readable format, the next step is to publish it via MQTT to build your Unified Namespace (UNS). The UNS is created by organizing your MQTT topics into a standardized hierarchy, when you publish data to these structured topics, you're establishing the namespace that other systems can subscribe to.

**Step 3.1: Preparing Your MQTT Broker**

As mentioned in the prerequisites, FlowFuse provides an integrated MQTT broker service for Team and Enterprise users. The broker uses username and password authentication, you create clients on the platform with credentials that control topic access.

**To create MQTT clients:**

1. Navigate to the FlowFuse platform and click **Broker** in the left sidebar.
2. Click the **Create Client** button.
3. Enter a **username** and **password** for the client.
4. Configure **topic access control patterns** if needed, specifying which topics the client can publish to or subscribe from.
5. Click **Save** to create the client.
6. Once saved, copy the **Client ID** from the client list and save it for the next step.

For more details about the FlowFuse MQTT broker service, refer to the [MQTT Broker Service Announcement](https://flowfuse.com/blog/2024/10/announcement-mqtt-broker/).

**Step 3.2: Configure MQTT Nodes**

Now you'll configure Node-RED to publish your transformed Modbus data to the MQTT broker.

1. In the Node-RED editor, drag an **mqtt out** node onto the canvas.
2. Double-click the node, then click the &#x2A;*+** icon next to the **Server**field to add a new broker connection:
   - **Server**: Enter `broker.flowfuse.cloud` (for FlowFuse MQTT).
   - **Port**: Use the default MQTT port (1883 for non-TLS, 8883 for TLS).
   - **Client ID**: Paste the Client ID you copied earlier.
   - **Username**: Enter the username you created.
   - **Password**: Enter the password you created.

![MQTT broker node configuration](https://flowfuse.com/blog/2024/12/images/mqtt-broker-config-node.png){dataZoomable=""}*MQTT broker node configuration*

3. Click **Add** to save the broker configuration.
4. Back in the mqtt out node configuration:
   - **Topic**: Enter a topic following the ISA-95 equipment hierarchy, such as `plant2/Area4/Cell2/DeviceA/temperature`. This naming convention organizes data by enterprise, site, area, line, and equipment, making it easier to filter, manage, and scale your system as it grows.
   - **QoS**: Select the appropriate Quality of Service level:
     - **0** (At most once) - Fastest, but no delivery guarantee
     - **1** (At least once) - Ensures delivery, possible duplicates
     - **2** (Exactly once) - Slowest, but guarantees single delivery
   - **Retain**: Enable this if you want the broker to store the last message for new subscribers.

![MQTT Out node configuration for temperature data](https://flowfuse.com/blog/2024/12/images/mqtt-client-config-temperature.png){dataZoomable=""}*MQTT Out node configuration for temperature data*

*Note: This example uses environment variables for sensitive configuration data to prevent accidental exposure when sharing flows. For more information, refer to [Using Environment Variables with Node-RED](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/).*

5. Click **Done** to save the node configuration.
6. Connect the output of the **Change** node (which transforms your temperature data) to the input of this **mqtt out** node.

**Using FlowFuse MQTT Nodes**

If you're using the FlowFuse MQTT broker, FlowFuse provides specialized MQTT nodes that simplify configuration. These nodes automatically configure the broker connection details when you drop them onto the canvas, no manual setup of server address, Client ID, username, or password required. You also won't need to manually create clients in the broker; they're automatically created when you use these nodes. This streamlines the development process and reduces configuration errors. Learn more about [FlowFuse MQTT nodes](https://flowfuse.com/node-red/flowfuse/mqtt/).

**Step 3.3: Configure MQTT Nodes for Remaining Metrics**

Repeat the configuration process for each metric (pressure, vibration, humidity), creating separate **mqtt out** nodes with unique topics:

- **Pressure**: `plant2/Area4/Cell2/DeviceA/pressure`
- **Vibration**: `plant2/Area4/Cell2/DeviceA/vibration`
- **Humidity**: `plant2/Area4/Cell2/DeviceA/humidity`

Each mqtt out node should:

- Use the same broker configuration (click the pencil icon next to Server and select your existing broker)
- Have its own unique topic
- Be connected to the corresponding Change node output

**Step 3.4: Deploy and Verify the Connection**

1. Click **Deploy** in the top-right corner of Node-RED to activate your flow.
2. Check the status indicator beneath each **mqtt out** node:
   - **Green dot with "connected"**: Successfully connected and publishing data
   - **Red dot with "disconnected"**: Connection failed, check your broker credentials and network connectivity
   - **Yellow dot**: Connecting or waiting for data
3. To verify data is flowing to your UNS:
   - Navigate to the **Broker** section in the FlowFuse platform
   - Click the **Hierarchy** tab to view your topic structure
   - You should see your topics organized by the ISA-95 hierarchy you defined

![FlowFuse topic hierarchy interface showing UNS structure](https://flowfuse.com/blog/2024/12/images/flowfuse-mqtt-topic-hierarchy-monitoring.png){dataZoomable=""}*FlowFuse topic hierarchy interface showing UNS structure*

Once your flow is successfully publishing data, you've established your Unified Namespace. Other systems can now subscribe to these MQTT topics to consume the data for:

- **Cloud analytics platforms** for historical analysis and reporting
- **[FlowFuse Dashboard](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"}** for real-time monitoring and visualization
- **Predictive maintenance systems** for equipment health monitoring
- **Business intelligence tools** for operational insights
- **Alert and notification systems** for automated responses to threshold breaches

This setup effectively bridges legacy Modbus devices with modern IoT infrastructure, enabling data-driven decision-making and unlocking the full potential of your industrial operations.

For more information on using MQTT with Node-RED, please read [Using MQTT with Node-RED](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/).


# Data Modeling: The Key to a Successful Unified Namespace

In manufacturing, data flows from various sources, machines, sensors, enterprise systems, and more. A [Unified Namespace (UNS)](https://flowfuse.com/use-cases/uns/) brings all this data into a central hub. However, centralizing data isn't enough to truly call it a UNS. It's not just about aggregating information. A true UNS goes beyond being a data repository; it organizes, structures, and contextualizes that data, transforming it into something valuable and actionable for your business.

By applying a solid data model, you can turn scattered, unstructured data into a cohesive, meaningful system that supports better decision-making and drives operational improvements. Let's explore what data modeling is, why it is crucial for making your UNS function effectively, and how it turns scattered data into valuable insights.

*At its core, **data modeling** is designing how data will be structured, organized, and stored within the UNS. It’s about creating a blueprint or framework that defines the relationships between different data points, ensuring they’re logically structured, easily accessible, and aligned with the business's needs.*

A solid data model forms the foundation for understanding and using data effectively. It addresses essential questions like:

- **How should data be represented?** – What formats, units, or categories should be used to express the data?
- **When is it captured, and what does it represent?** – Is it sensor data, performance metrics, or supply chain information? When was it recorded, and what is its context?

The data model can vary significantly from business to business, depending on the use case. For example, in manufacturing, if a device is sending sensor metrics to a UNS, the data could look like this:

```json
{
  "timestamp": "2024-09-19T12:33:46.6035772+02:00",
  "machineId": "press_001",
  "manufacturer": "XYZ Corp",
  "model": "MPX-5000",
  "sensors": [
    {
      "name": "vibration",
      "value": 1.5,
      "unit": "mm/s"
    },
    {
      "name": "temperature",
      "value": 72.4,
      "unit": "Celsius"
    },
    {
      "name": "pressure",
      "value": 3.8,
      "unit": "Bar"
    }
  ]
}
```

Alternatively, a simpler model might look like this:

```json
{
  "timestamp": "2024-09-19T12:33:46+02:00",
  "machine": "press_001",
  "vibration": { "value": 1.5, "unit": "mm/s" },
  "temperature": { "value": 72.4, "unit": "Celsius" },
  "pressure": { "value": 3.8, "unit": "Bar" }
}
```

In both examples, the data is structured with critical elements like timestamps, machine identifiers, sensor readings, and units of measurement. The crucial difference between the two models lies in the level of detail, but both demonstrate how a well-defined data modeling adds immediate value. Organizing data clearly and consistently ensures its accuracy and enables it to be easily analyzed, integrated, and acted upon.

Now that you have a basic understanding of what data modeling is Let’s take a deep dive into why data modeling is essential to unlocking the full potential of your UNS:

### 1. Ensures Data Consistency and Standardization

As mentioned earlier, data is generated from various sources in manufacturing, including machines, sensors, ERP systems, and inventory management tools. Each source may provide data in different formats, units of measurement, or naming conventions.

For example, one machine might report temperature in Celsius, while another uses Fahrenheit. Some systems might track production rates in pieces per hour, while others use units per minute. These inconsistencies can create confusion and lead to errors in a computerized structure.

Data modeling addresses this issue by establishing clear standards for how data should be structured and labeled. It ensures uniform temperature, unit, and measurement formats across all systems. For example, a data model might require recording all temperature readings in Celsius and production rates in pieces per hour. This consistency simplifies data analysis from diverse sources and ensures that the system functions reliably and accurately.

### 2. Gives Data Meaning

Raw data on its own is just numbers, isolated and incomplete. For example, a temperature reading of 72.4°C or a vibration level of 1.5 mm/s doesn’t tell much without the proper context. This is where data modeling truly adds value. A data model turns simple measurements into meaningful insights by organizing data that includes critical details like timestamps, data sources, and relationships between data points.

Contextualizing data means understanding when it was captured, where it came from, and what it’s related to. A timestamp helps track trends over time, such as detecting a gradual temperature rise that could signal an issue before it becomes critical. Knowing the data source, whether it’s a specific machine or sensor, enables targeted troubleshooting and ensures that the right teams are working with the right data. Data modeling also links data points, like correlating vibration and temperature readings, to identify potential equipment failures. This structure makes data far more accessible and actionable, allowing teams to make informed, real-time decisions, prevent unplanned downtime, and drive process improvements.

In summary, data modeling transforms raw data into actionable insights, helping you understand what is happening in your operation, when it started, where it is occurring, and how to address it effectively.

### 3. Facilitates Data Interoperability and Integration

In manufacturing, various devices and systems generate data in different formats and use distinct communication protocols, making integrating and utilizing this data effectively challenging.

For example, PLCs may use one protocol, while SCADA systems or MES may rely on entirely different ones. This lack of consistency complicates consolidating data and extracting meaningful insights. Integrating other systems often requires addressing discrepancies in how data is structured and labeled. For instance, multiple sensors on a production line might send data in various formats or label the same metric differently. One sensor might label temperature as "temp," another as "temperature," and yet another as "T1." These inconsistencies can lead to errors or failures in integrated systems, such as monitoring tools that depend on consistent data labeling to function correctly.

This is where data modeling becomes essential. It creates a standard structure for organizing and labeling data, ensuring that different systems can "speak the same language" and integrate seamlessly.

For example, in a predictive maintenance system, sensor data such as temperature and vibration can be used to predict potential machine failures. With the right data model, this sensor data can be directly linked to your CMMS (Computerized Maintenance Management System), regardless of how many sensors are involved or added over time. Since engineers understand the standardized data structure, they can easily integrate the CMMS with minimal effort. This integration automatically triggers maintenance alerts and work orders, helping to prevent downtime without requiring manual intervention.

### 4. Enables Easy Access and Time Savings

Disorganized data wastes time and resources in manufacturing. A transparent data model makes essential information easy for troubleshooting, performance checks, and decision-making tasks.

With a standardized system, figuring out confusing labels or complex data is unnecessary. A consistent data model organizes information, helping operators respond faster, reduce downtime, and minimize errors.

Quick access to accurate data speeds up decision-making, cuts downtime, and improves efficiency, leading to cost savings.

### 5. Scalability and Continuous Improvement

A well-structured data model serves the needs of your current manufacturing operations and lays the groundwork for future growth and continuous improvement. As your production processes evolve or new technologies and data sources come online, a good data model allows your UNS to adapt without disrupting existing systems.

For example, as you add new machines, automated production lines, or advanced sensors to your operations, the data model ensures that these new elements integrate smoothly into the existing framework. It maintains consistency, enabling new data points to be mapped easily while keeping the system organized and efficient.

---

With all these benefits in mind, the next step is to consider how to implement data modeling effectively. Data modeling is a much deeper, more dynamic process that can reshape how you use data across your entire business. It's not only about structuring and integrating data but also about transforming your operations, unlocking new efficiencies, and driving growth. The right platform can help you go beyond essential organization and truly harness the power of your data.

## Leverage FlowFuse for Effective Data Modeling in Your UNS

[FlowFuse](https://flowfuse.com) makes building and managing a Unified Namespace (UNS) simple and efficient. It connects IT and OT systems, streamlines workflows, and transforms raw data into meaningful insights. With FlowFuse, you can:

- **Connect**: Integrate various services, hardware, and APIs effortlessly.
- **Collect**: Aggregate data from machines, sensors, and other sources.
- **Transform**: Easily standardize and add context to raw data, making it more meaningful and usable across your systems.
- **Visualize**: Create dashboards with a low-code approach to monitor and analyze your operations.

Learn how to build your UNS in just 15 minutes with [this article](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/).

FlowFuse uses Node-RED, an open-source low-code platform, to turn unstructured data into organized, actionable models. Its ability to transform and contextualize data ensures consistency and clarity, helping you get the most value from your data.

With support for over 5,000 community nodes and protocols like MQTT, OPC-UA, and Modbus, FlowFuse simplifies connecting systems and unifying data.

Check out [this article](https://flowfuse.com/blog/2023/12/unified-namespace-data-modelling/) to see how FlowFuse makes data modeling easier.

FlowFuse also offers enterprise-grade features to manage edge devices and Node-RED instances, helping you scale, collaborate, and stay compliant.


# Designing a Clear Topic Structure for Your UNS

Topic structuring is not just a technical concern when building a high-performance Unified Namespace (UNS) for manufacturing environments; it's a strategic design choice that can determine the system's scalability, efficiency, and overall effectiveness.

A well-structured topic hierarchy is critical in manufacturing, where vast amounts of data flow from sensors, machines, and systems. By organizing your topics correctly, you can streamline data flow, simplify scaling, and make your system more manageable as your operations grow.

In this post, we'll explore the significance of topic structuring for your UNS, outline why it's essential for scalability and performance, and share best practices for designing a robust topic hierarchy that can evolve alongside your business.

## Why Topic Structuring is Crucial for Your UNS

When building a UNS for manufacturing environments, [MQTT](https://flowfuse.com/blog/2025/01/mqtt-frontrunner-for-uns/) is one of the most popular and preferred choices due to its lightweight, efficient, and scalable design. MQTT’s publish-subscribe model is perfect for handling the real-time, high-volume data flow in factories, where machines, sensors, and devices constantly generate information. However, while MQTT is a powerful tool, how you structure your topics plays a pivotal role in ensuring that your UNS is scalable and efficient.

Manufacturing operations often experience rapid growth. The sheer number of sensors, machines, and production lines increases over time, and so does the complexity of the data. MQTT topics are hierarchical, which means they follow a tree-like structure with levels separated by a forward slash (/). This hierarchical structure can mirror the physical layout of your factory floor, providing a logical, scalable framework for your data.

For example:

`/factory/line1/machine1/temperature`

This topic structure indicates that the data comes from machine1 on line1 of your factory, specifically from a temperature sensor. The structure is intuitive because it directly reflects the factory’s layout.
Adding more machines, sensors, or production lines is straightforward as your factory grows.

For instance, as your factory adds a second production line, you can add topics like:

- `/factory/line2/machine1/temperature`
- `/factory/line2/machine1/vibration`
- `/factory/line2/machine2/temperature`

This hierarchical system scales seamlessly as you add more machines, sensors, and production lines without creating unnecessary complexity.

A well-structured topic hierarchy improves the performance of both the network and edge devices. When monitoring or data analysis systems subscribe to topics, they can choose the data they need. This means they are not overwhelmed by unnecessary traffic, which could otherwise strain network bandwidth and device processing power.

For example, imagine a maintenance team only needs to monitor the temperature of machines in line 1. With a clean topic structure, they can subscribe to:

- `/factory/line1/machine1/temperature`
- `/factory/line1/machine2/temperature`

By filtering the data, they avoid receiving irrelevant data, such as vibration readings from other machines or temperatures from machines on different production lines. This reduces network load, ensures more responsive performance, and prevents overloads on edge devices.

A well-organized topic structure makes maintenance and troubleshooting much more efficient. When equipment malfunctions or a sensor starts reporting erroneous data in a smart factory, the ability to pinpoint the issue quickly is crucial. With a hierarchical topic system, you can easily trace the problem to a specific machine, sensor, or production line.

For instance, imagine a temperature sensor on machine 3 in line 2 reporting abnormal values. A topic like:

- `/factory/line2/machine3/temperature`

Immediately indicates the affected machine and production line. This clarity lets your team act quickly, reducing downtime and improving system reliability.

Without a clear topic structure, identifying and diagnosing problems can become time-consuming, leading to extended downtime and inefficiencies.

As new equipment, sensors, or production lines are added to the factory, a well-structured topic system helps onboard new engineers, technicians, and operators easily. A clear hierarchy provides a visual map of the system, making it easier for new users to understand the architecture and begin working with it quickly.

## Designing a Topic Structure for Your UNS

Before you start collecting data in your UNS, it’s essential to design your topic structure. While it might seem like a small step, it’s the foundation of your system. Taking the time to plan will save you significant time and effort down the road. More importantly, it gives you a clear, high-level view of your entire factory, which is crucial for scaling effectively.

First, think about the key components of your factory. For example, you might have different plants or production lines in a manufacturing setting. There will be machines or devices within each production line that produce data. Then, you’ll have various data points coming from sensors on these machines, such as temperature, humidity, or pressure.

By organizing your topics around these components, you’re setting up a structure that’s easy to scale.

Next, remember that MQTT topics are hierarchical, so think of them like a tree. At the top of the tree, you’ll have the broadest categories (like plants or regions). As you go down, you’ll get more specific, with production lines, machines, and then individual data points like sensor readings. The key is to keep things logical so that you can locate the data you need quickly. This organization lets you promptly expand your system later by adding new plants, lines, or machines without disrupting the entire structure.

The concept of structuring topics logically and hierarchically draws from a well-known framework in manufacturing: ISA-95. ISA-95 is a standard that defines a hierarchical model for organizing and managing manufacturing systems. It divides operations from the company level to individual machines, providing a clear structure for system management.

![ISA-95 Equipment Hierarchy Model](https://flowfuse.com/blog/2025/01/images/isa-95-equipement-model.png){dataZoomable=""}*ISA-95 Equipment Hierarchy Model*

Here’s a brief breakdown of the ISA-95 levels and how they can be translated to MQTT topics:

- **Level 0 – Physical Devices and Control**

This is where the physical data originates: sensors, actuators, and devices directly interacting with machinery and production lines. These are typically represented as devices in your MQTT topic structure.

Example Topics:

- `/plantA/productionLine1/machineB/sensor/temperature`
- `/plantA/productionLine1/machineB/sensor/pressure`
- `/plantA/productionLine2/machineC/sensor/humidity`

At this level, you're dealing with specific machines and sensors. The topic name clearly defines the device type (e.g., "sensor") and the type of data it generates (e.g., "temperature"). This structure makes tracking sensor data easy for each machine or production line.

- **Level 1 – Control Devices and Systems**

This level represents the control systems that operate the machinery and manage the data flow. These systems include PLCs, SCADA systems, or other control devices that manage real-time operations.

Example Topics:

- `/plantA/productionLine1/machineB/PLC/status`
- `/plantA/productionLine1/machineB/PLC/mode`
- `/plantA/productionLine2/machineC/SCADA/alerts`

Topics at this level might focus on the status and control functions of the machines. Separating control systems like PLCs or SCADA ensures that operational data (e.g., machine modes or alerts) is distinct from raw sensor data. This approach ensures that each system component can be monitored and managed independently.

- **Level 2 – Monitoring and Supervisory Control**

At this level, systems monitor and manage operations. They might include higher-level systems that oversee the production lines, collect data from multiple PLCs, and trigger alerts or analyses based on predefined criteria.

Example Topics:

- `/plantA/productionLine1/supervisor/alerts`
- `/plantA/productionLine1/supervisor/performance`
- `/plantA/productionLine2/supervisor/utilization`

Here, you might aggregate data from several control devices (like PLCs) and provide higher-level insight into the overall system. For example, a "performance" topic could aggregate sensor data to monitor the efficiency of a production line, while "alerts" might be used for system-wide warnings.

- **Level 3 – Manufacturing Operations Management**

This level encompasses managing the overall production process, such as scheduling, production orders, and resource management. This is often where MES (Manufacturing Execution Systems) comes into play.

Example Topics:

- `/plantA/productionLine1/MES/productionOrder`
- `/plantA/productionLine2/MES/scheduling`
- `/plantB/productionLine1/MES/inventoryStatus`

The data becomes more abstract at this level as you deal with business logic, production orders, and scheduling systems. For example, the "productionOrder" topic could track orders for specific products, while "inventoryStatus" could provide data on material availability for each production line.

- **Level 4 – Enterprise Resource Planning (ERP)**

The highest level in the ISA-95 hierarchy is focused on enterprise-wide resource planning, financials, and decision-making processes. ERP systems integrate with manufacturing systems to provide broader business insights.

Example Topics:

- `/enterprise/ERP/inventory/overview`
- `/enterprise/ERP/sales/orders`
- `/enterprise/ERP/production/metrics`

At the ERP level, topics reflect cross-plant business data like inventory, order management, or performance metrics. These are less granular than lower levels and provide decision-makers with high-level insights into the health of the overall business.

## Best Practices for Managing Your Topic Structure

As your UNS scales, following some essential best practices will ensure your topic structure remains efficient, secure, and easy to manage.

1. Maintain Clear Documentation:

First and foremost, maintaining clear documentation is key. A well-documented topic hierarchy is a reference point for everyone involved in the system, from developers and engineers to system administrators. This documentation should outline the naming conventions, the purpose of each topic, and how new issues should be added. Without it, there's a risk of inconsistency creeping into your system, especially as new data streams and devices are introduced. An apparent, organized reference ensures your team can efficiently navigate and expand the system without confusion.

2. Ensuring Consistency in Naming and Structure:

Using clear, descriptive names for each topic and sticking to a consistent naming pattern across your system is essential for long-term success. A well-defined naming convention ensures that everyone involved, whether developers, engineers, or system administrators, can easily understand the purpose of each topic. Navigating your UNS becomes intuitive when topics are consistently named, and troubleshooting issues is much easier.

For instance, avoid vague or overly generic names like `/sensor1/data`, which don’t offer much context. Instead, adopt more descriptive, hierarchical names that reflect the actual source and nature of the data, such as `/plantA/productionLine1/machineB/temperature`. A consistent structure not only enhances system readability but also ensures scalability.

3. Keep Topic Names Simple and Avoid Special Characters:

While it’s essential to have descriptive topic names, they should also be simple and easy to use. Long topic names can make working with your UNS quickly and efficiently harder. Also, avoid using spaces or special characters, which might cause compatibility issues with some MQTT brokers or clients.

4. Perform Regular Topic Cleanup and Expiration:

Next, don’t overlook the importance of topic cleanup and expiration. Over time, unused or obsolete topics can accumulate, adding unnecessary complexity and overhead to the system. Left unchecked, these stale topics can lead to unwanted confusion. It’s important to regularly audit the issues in your UNS, archiving or removing those no longer needed. While some MQTT systems support automatic topic expiration, implementing manual checks as part of your routine system maintenance is still a good practice. You’ll also want to manage the use of retained messages carefully. While they can help provide the latest state to new subscribers, overuse or misuse can lead to outdated information circulating across the system. Be mindful about which topics should retain data and ensure they are updated or cleaned up regularly.

5. Implement Robust Access Control:

Access control is essential in managing a large-scale UNS. The hierarchical structure of MQTT topics naturally supports role-based access control (RBAC), allowing you to assign permissions based on topics. This ensures users and devices only access the data they need.

For example, engineers might only need access to machine-level sensor data, while plant managers require broader visibility into performance metrics across production lines. Additionally, you can restrict which devices can publish data on specific topics, ensuring only authorized systems send critical updates.

By defining clear access rules, you enhance security, maintain data integrity, and ensure that your UNS can scale efficiently as your organization grows.

## Effortless MQTT and Topic Management with FlowFuse

FlowFuse is more than just a low-code platform; it’s a game-changer for building and scaling your UNS. By seamlessly integrating MQTT, FlowFuse empowers you to connect, manage, and scale your industrial data systems efficiently.

FlowFuse's built-in MQTT broker gives you high-performance data handling without additional infrastructure overhead. The platform also features an interface for managing MQTT clients with access control for topics and an intuitive Topic Hierarchy View, which provides a real-time, visual representation of your entire MQTT topic structure. This makes organizing, monitoring, and managing your topics easy, ensuring clarity and consistency as your system grows.

![Image showing FlowFuse topic hierarchy interface for UNS](https://flowfuse.com/blog/2025/01/images/flowfuse-mqtt-topic-hierarchy-monitoring.png){dataZoomable=""}*Image showing FlowFuse topic hierarchy interface for UNS*

What truly stands out is FlowFuse's ability to handle both legacy and modern industrial protocols, effortlessly bridging the gap between old and new systems. Whether adding new devices, integrating data streams, or scaling to thousands of devices, FlowFuse gives you the flexibility, scalability, and security you need to optimize your UNS at every step.

FlowFuse doesn’t just help you manage topics, it streamlines collaboration, enhances system performance, and accelerates your journey toward a fully integrated, future-proof UNS.


# FlowFuse 2.13: Remote Instances, UNS Schemas & Improved Management at Scale

Happy New Year everyone! We're back with another release of FlowFuse, and whilst it's been a shorter sprint for us this time round, with most of the team out for a well-earned break over Christmas and New Year, that hasn't stopped us packing in lot of great new value into FlowFuse nonetheless.

:product-update-note

## Hosted & Remote Instances

This release you'll notice that we've changed the terminology of two of our key concepts in FlowFuse:

- **Instances** are now referred to as **Hosted Instances**
- **Devices** are now referred to **Remote Instances**

We were finding that customers and prospects were getting confused over the term "Device", when in fact, it is a running *Instance* of Node-RED. You can have many Remote Instances running on the same piece of hardware, all using the FlowFuse Device Agent, and the term, "Device" made that misleading.

Remote Instances are just instances of Node-RED, deployed onto your own hardware and managed via FlowFuse and the FlowFuse Device Agent. We hope this change will make it clearer for everyone, and wanted to include this graphic which shows the updated terminology in the hierarchy of FlowFuse:

![FlowFuse Hierarchy](https://flowfuse.com/blog/2025/01/images/flowfuse-hierarchy.jpg){dataZoomable=""}*Diagram to show the hierarchy of different concepts in FlowFuse*

## Documenting Your UNS

Just under three months ago, we [released our own MQTT Service](https://flowfuse.com/blog/2024/10/flowfuse-release-2-10/), making it easy for your to configure MQTT clients through FlowFuse, and connect your hardware and applications. With the Unified Namespace (UNS) growing in popularity in Industry, we wanted to make sure that if you're using MQTT to run your UNS, then FlowFuse offers the best experience for managing it.

![FlowFuse Topic Hierarchy Schema](https://flowfuse.com/blog/2025/01/images/flowfuse-topic-schema.png){dataZoomable=""}

With this in mind, we're now generating a formal schema for your MQTT Broker's topic hierarchy automatically, and we've made it possible to access the underlying schema through the FlowFuse interface. The schema we generate is using the industry-standard, open-sourced, [AsyncAPI](https://www.asyncapi.com/){rel="&#x22;nofollow&#x22;"}.

If you're interested in learning more about UNS, then we recommend taking a look at some of the following resources:

- [Introduction to the Unified Namespace](https://flowfuse.com/blog/2023/12/introduction-to-unified-namespace/)
- [Why you need a Unified Namespace](https://flowfuse.com/blog/2024/11/why-point-to-point-connection-is-dead/)
- [Building a Unified Namespace (UNS) with FlowFuse](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/)
- [**Free whitepaper:** UNS - Decoupling data producers and consumers](https://flowfuse.com/whitepaper/uns-decoupling-data-producers-and-consumers/)

### Future Plans

This is very much a first iteration and we have work underway to improve it. Right now, the generated spec is pretty minimal - there is lots of scope to add more information and present it in a clearer and more interactive format. This will make it easy for your whole development team, and anyone else that needs to know, to get a clear picture of the topics and payloads that are being used in your MQTT Broker.

We're also looking at how this information can enhance the development experience within Node-RED itself.

## Managing Groups of Instances

We've introduced a new view in FlowFuse which you can find in the "Operations" section of the side navigation. This new view is called "Groups" and it allows you to group your Remote Instances together, making it easier to manage and deploy to multiple instances at once.

![FlowFuse Groups view](https://flowfuse.com/blog/2025/01/images/flowfuse-team-groups.png){dataZoomable=""}

This functionality has been in FlowFuse for a little while, but was buried down in the "Applications" view, and found users were missing it. We've now brought it to the forefront, and made it easier to use, and help you deploy out to thousands of Remote Instances with the single click of a button.

## New Onboarding Tour

![Screenshot from the new Free Tier onboarding tour](https://flowfuse.com/blog/2025/01/images/free-tier-tour.png){dataZoomable=""}

We have a new onboarding tour that will be shown to those users signing up to our [new Free Tier on FlowFuse Cloud](https://flowfuse.com/blog/2024/12/flowfuse-release-2-12/).

This tour is purpose built to help you get up and running with your first Remote Instance in FlowFuse, setting up the Device Agent on your own hardware, and accessing your Remote Instance via FlowFuse Cloud.

## In Case You Missed It...

Last month we [released a new Free Tier on FlowFuse Cloud](https://flowfuse.com/blog/2024/12/flowfuse-release-2-12/), but announced it in the same article as our latest release and so a lot of the other new features we'd added to FlowFuse were lost in the weeds a little. We had a few self-hosted customers mention that they missed the updates for 2.12, so we also wanted to re-highlight some new features from that release too:

- **Pipelines** - New view at the team-level to manage your DevOps Pipelines, making it easier to deploy between development, test and production environments. Pipelines can also be used to push updates out to thousands of Remote Instances at once using the new "Groups" feature.
- **Bill of Materials** - New view at the team-level to get a clear picture of all dependencies that your Instances are using. Makes it easier to manage out-of-date packages, and help with auditing and compliance.
- **Device Agent Performance Improvements** - For those running Node-RED 4.0.x and higher, the Device Agent has had some significant updates to performance, making the experience of remote editing much faster and smoother, especially when the device is on a slow network link.
- **Dashboards in iFrames** - FlowFuse-hosted Dashboards can now be configured to run inside iFrames. You can find this option under the "Settings" of the Instance in question.

## What Else Is New?

For a full list of everything that went into our 2.13 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.13.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try FlowFuse

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.


# How to Choose the Right IIoT Device Management Software for Your Business

With more devices being connected across industrial environments, managing them can get pretty overwhelming. The right IIoT device management software can help you stay on top of things, keeping everything secure, up-to-date, and running smoothly. But with so many options out there, how do you figure out which one’s best for your business?

:product-update-note

This guide will take you through the key features and considerations to keep in mind when choosing IIoT device management software. Whether you’re just starting out with IIoT or looking to improve your current setup, we’ve got some helpful insights to point you in the right direction.

### 1. Vendor Reputation and Support

When it comes to IIoT systems, the right vendor can make all the difference. After all, your device management platform will be at the heart of your manufacturing operations, and any hiccups can result in costly downtime. That's why choosing a vendor with a solid reputation is non-negotiable. Start by researching companies that have a proven track record in industrial environments. Look for vendors who not only understand the technical side of IIoT but also know how to support real-world use cases in manufacturing. Customer reviews and case studies can provide valuable insight into their reliability, service quality, and expertise.

One of the most important factors to consider is the availability of customer support. Your platform should be backed by a responsive, accessible support team, especially when things go wrong. In high-pressure situations, like production delays or equipment failures, 24/7 support can be a game-changer. You don’t want to be waiting hours for help when every minute counts. Look for vendors that offer clear, well-documented resources along with robust, round-the-clock support to guide you through troubleshooting and problem resolution.

### 2. Remote Access

The best device management software should make it easy to manage devices from anywhere. Remote access is crucial, especially for businesses with devices spread across different locations or those that operate 24/7. With remote access, your team can monitor device performance, troubleshoot issues, and push updates without needing to be on-site. This flexibility reduces downtime and ensures everything stays operational, no matter where you are.

For example, imagine you have a factory in a remote area and a critical device experiences a malfunction. Without remote access, you would need to send a technician on-site, which could involve travel time, accommodation, and delays in getting the machine back up and running. This can be costly, not just in terms of money but also in lost production time. With remote access, however, your team can instantly diagnose the issue, push an update, or even resolve the problem without the need for a costly site visit. This means less downtime, faster resolutions, and a more efficient operation overall.

### 3. Automated Monitoring and Alerts

In manufacturing, keeping a constant watch on device health is crucial to avoid unexpected failures that could lead to costly downtime. The ideal device management platform should automatically track key performance metrics, such as device crashes, CPU usage, and more. By continuously monitoring these metrics, the platform can quickly identify any abnormalities and alert your team before small issues escalate into major problems.

For example, imagine a device on the factory floor experiences high CPU usage and is about to crash. An automated alert would immediately notify your team, allowing them to take swift action and address the issue before it causes a disruption. This proactive approach helps keep production running smoothly and minimizes unnecessary downtime.

The platform should also allow you to set custom thresholds for specific performance metrics. This way, your team will only receive alerts for critical issues, reducing the noise from less important events. With this level of precision, responses become faster and more focused, ensuring that the most pressing concerns are addressed promptly.

Automated monitoring and alerts not only save time but also increase the reliability and productivity of your IIoT ecosystem. By catching potential failures early, you can prevent unplanned downtime and ensure that your operations remain efficient and uninterrupted.

### 4. Device Grouping and Scalability

As your IIoT network grows, managing each device individually can quickly become overwhelming. That's why it's essential to choose a platform that allows you to group devices by function, location, or type. For example, you could group all the devices in Production Line 1, making it easier to deploy workflows, software updates, or configurations with just a single click for all.

Device grouping simplifies the management process, enabling you to update settings, deploy updates, and troubleshoot multiple devices at once. Scalability is also crucial, your platform should seamlessly accommodate new devices as your operations expand, without adding unnecessary complexity or slowing down performance.

With the right platform, you can keep your IIoT network organized and scalable, ensuring that as your business grows, device management remains efficient and hassle-free.

### 5. Wide Range of Device Support

In a busy manufacturing environment, you're working with a mix of devices, some on Linux, some on Windows, and others with their own custom software. The last thing you want is to have to juggle multiple platforms to manage all your devices.

Find a device management system that works with all of them. A flexible platform will let you manage all your devices, regardless of their operating system, from one central dashboard. This makes your life a lot easier and keeps your operations running smoothly.

### 6. Built-in DevOps Toolset

Automation is essential for boosting manufacturing efficiency. device management platforms with built-in DevOps tools integrate easily with production systems. They automate tasks like device setup, configuration, and software updates, helping reduce downtime and speed up troubleshooting.

DevOps pipelines allow you to create workflows tailored to your needs, automating updates and maintenance for IIoT devices. This means your platform can push updates without interrupting production, reducing the need for manual work.

With the flexibility to create custom DevOps pipelines, you can manage devices more efficiently, save time, minimize errors, and keep everything aligned with production requirements.

### 7. Real-Time Collaboration

Managing IIoT devices often involves teams working together, sometimes from different locations. That’s why having a platform that supports real-time collaboration is so important. It allows your team to stay in sync, making it easier to troubleshoot issues or implement updates without delays.

Look for a platform that lets multiple team members access and manage devices at the same time. This way, everyone can contribute to resolving problems or pushing updates without stepping on each other’s toes. Real-time collaboration helps keep things running smoothly, especially when quick responses are needed.

### 8. Accidental Recovery or Rollback

Another essential feature to look for is the ability to recover from system failures or accidental misconfigurations. Accidents can happen at any time, and being able to revert to a previous stable state quickly can save you from costly downtime and operational disruptions.

The ideal IIoT device management platform should include a snapshot or rollback functionality. This allows you to take snapshots of your device configurations and system state at various points in time. In the event of an issue, you can simply roll back to a previous snapshot, restoring your devices to their last known good state.

This feature is especially critical in production environments where system stability is key to preventing operations interruptions. It minimizes downtime, ensures data integrity, and provides peace of mind, knowing that you can recover quickly from mistakes or technical failures.

### 9. System And Audit Log Management

When it comes to managing IIoT devices, keeping track of what’s happening in your system is essential. A good platform will automatically log everything, device activities, errors, and user actions, so you can stay on top of things.

Audit logs are especially helpful because they tell you who accessed the system, what actions were taken, and when they happened. This level of visibility makes it easier to spot any security risks or unauthorized changes early, helping you address them before they turn into bigger issues.

These logs are also crucial for compliance. By maintaining a clear record of all changes, you can easily demonstrate that your system meets industry regulations and standards. This adds an extra layer of security and peace of mind, knowing that everything is being properly documented and monitored.

### 10. Strong Security Features

When it comes to IIoT, security is a top priority, especially with sensitive production data involved. Look for a platform that offers end-to-end encryption to ensure your data stays protected as it moves between devices and the cloud.

Access control is also important. A good IIoT platform will limit device access based on user roles, so only authorized personnel can view or make changes to sensitive data. This helps keep things secure by preventing unauthorized access.

To stay ahead of potential security risks, the platform should include vulnerability scanning tools like SBOM (Software Bill of Materials). These tools help you track and manage any risks from third-party software, giving you peace of mind.

For added protection, choose a platform that supports multi-factor authentication (MFA). MFA provides an extra layer of security in case login credentials are compromised.

Finally, make sure the platform secures device-to-cloud for remote accesss connections with methods like SSH tunneling and VPNs. These help ensure that data is transmitted safely and only accessible by trusted users, no matter where your devices are located.

### 11. User-Friendly Interface

Your team shouldn’t waste time struggling with a complicated platform in a busy manufacturing environment. Choose a device management platform with a simple, intuitive interface that makes monitoring devices, adjusting settings, and resolving issues quick and easy.

A clean, easy-to-navigate UI allows your team to stay focused on key tasks like tracking device health and performance without unnecessary complexity. Simple controls for configuring devices, applying updates, and onboarding new devices will save time and reduce frustration.

### 12. Cost Considerations

When selecting a device management platform, it's crucial to look beyond just the initial cost. Consider the total cost of ownership, which includes licensing fees, ongoing maintenance, training, and technical support. These factors can add up over time, so it’s important to factor them into your decision-making process.

For example, a platform that charges based on the number of devices may seem affordable when you're just starting with a small network. However, as your operations scale, those costs can quickly increase. Take the time to compare different pricing models and choose the one that best fits your budget and future growth plans. This will ensure that your investment remains sustainable and supports your business over the long term.

### 13. Integration with Existing Systems

A good device management platform should make it easy for your devices to integrate with your existing systems, whether that’s your ERP, CRM, or maintenance software. This helps prevent data silos and ensures all your existing systems can work together and share data in real-time.

When your devices, machines, and software are connected, it keeps important information flowing freely across your operations. This makes it simpler to track inventory, monitor device health, or manage maintenance, and it helps you make more informed decisions.

The right platform should support a wide range of industrial protocols, from the latest to older systems, so everything can be included. By linking all your existing systems, you can create a single source of truth, keeping things running more smoothly and efficiently.

---

So, after all’s said and done, the secret to choosing the right IIoT device management software isn’t just about checking boxes on a list. It’s about finding a solution that keeps things simple, secure, and scalable for the long haul. Look for something that lets you stay in control, whether you're managing one device or a thousand, and make sure it’s backed by solid support when you need it most. In the end, the right platform should feel less like a tool and more like a partner that grows with you. Trust me, the right fit will make your life a whole lot easier.

## FlowFuse – The Ultimate IIoT Device Management Solution

FlowFuse is an open-source industrial data platform that simplifies the management, scaling, and security of IIoT devices. Whether you're managing a handful of devices or overseeing thousands, FlowFuse [consolidates everything into a single, intuitive interface](https://flowfuse.com/blog/2024/10/managing-node-red-instances-in-centralize-platfrom/). With seamless cross-platform support, you can control all your devices from one central hub, streamlining operations and enhancing efficiency.

[Paloma Irrigation and Drainage District chose FlowFuse for exactly this reason](https://flowfuse.com/customer-stories/leveraging-node-red-and-flowfuse-to-revolutionize-irrigation/), managing remote Node-RED edge applications to automate delivery of 185,000 acre-feet of water annually.

Built on the flexible [Node-RED](https://flowfuse.com/node-red) framework, FlowFuse easily integrates with a wide range of hardware, services, and APIs with over [5000 community contributed nodes](https://flowfuse.com/integrations/), allowing you to tailor and scale your IIoT network to meet evolving demands. The best part? You don’t need coding knowledge to get started, Node-RED’s visual programming interface makes it easy to create custom workflows with drag-and-drop functionality. With 24/7 expert support and an active community, you'll have access to the resources you need to resolve any challenges quickly.

[Security is a top priority for FlowFuse](https://flowfuse.com/blog/2024/10/exploring-flowfuse-security-features/). With features like SSH tunneling for secure remote device access, end-to-end encryption, and multi-factor authentication, your data is protected no matter where it’s being transferred. Role-Based Access Control (RBAC) ensures that only authorized users can make critical changes, while SOC 2 compliance provides an added layer of assurance for your sensitive operations.

[Real-time collaboration is built into the platform](https://flowfuse.com/blog/2024/12/flowfuse-team-collaboration/), enabling your team to work together on projects, monitor devices remotely, and deploy updates simultaneously, all within a secure environment. [Role-Based Access Control (RBAC)](https://flowfuse.com/blog/2024/04/role-based-access-control-rbac-for-node-red-with-flowfuse/) ensures that each team member has appropriate permissions based on their role. For example, admins can make critical changes, while operators can only monitor or update devices. This helps maintain control over sensitive functions while allowing your team to collaborate effectively. Together with RBAC, FlowFuse maximizes both security and productivity by ensuring the right people have access to the right tasks, at the right time.

If things go awry, FlowFuse’s [snapshot](https://flowfuse.com/blog/2024/09/node-red-version-control-with-snapshots/) feature lets you quickly revert to a previous stable state, minimizing downtime and keeping your systems running smoothly. Advanced monitoring tools continuously track device performance, sending alerts if issues like crashes or resource overloads arise, so your team can act before problems escalate. Detailed device logs and audit trails make troubleshooting straightforward, helping you quickly pinpoint issues and maintain a secure environment.


# How to Read and Write Siemens S7 PLC Data, A Node-RED Guide (2026)

Siemens S7 PLCs are a staple in industrial automation, powering everything from basic control functions to complex, large-scale processes. However, integrating these PLCs with other systems for remote monitoring or data sharing can present challenges.

This is where Node-RED comes in, offering a user-friendly solution to seamlessly connect Siemens S7 PLCs with a variety of platforms. With its intuitive flow-based interface, Node-RED enables you to create custom workflows and dashboards, no deep technical expertise required.

Siemens S7 PLCs are typically programmed using TIA Portal, Siemens' integrated development environment, and communication with external systems usually relies on the S7 protocol (ISO over TCP/IP). In this article, we’ll walk you through how to use Node-RED to read from and write to Siemens S7 PLCs via the S7 protocol, unlocking new possibilities for remote control and system integration in your industrial automation setup.

## Prerequisite

Before integrating your Siemens S7 PLC with Node-RED, make sure you have the following :

1. Before downloading the ladder program and all configurations and settings to your PLC, make sure you have the following settings:

- Allow PUT/GET Communication from remote partners.

![PUT/GET Communication from remote partners is Allowed](https://flowfuse.com/blog/2025/01/images/allow-put-get-communication.png){dataZoomable=""}*PUT/GET Communication from remote partners is Allowed*

- Provide full access to the PLC (no protection), allowing unrestricted access to data exchange.

![Providing complete access to the PLC](https://flowfuse.com/blog/2025/01/images/providing-full-access-to-plc.png){dataZoomable=""}*Providing complete access to the PLC*

2. Ensure that the appropriate ladder program (or any other logic) is written according to your requirements and successfully downloaded to the PLC. However, before downloading, make sure the 'Optimized Block Access' option is disabled for the data block that your ladder program using.

![Untick 'Optimized Block Access'.](https://flowfuse.com/blog/2025/01/images/optimized-block-access.png){dataZoomable=""}&#x2A;Untick 'Optimized Block Access.'*

3. Install Node-RED on the device that will communicate with the S7 PLC. You cannot install Node-RED directly on the S7 PLC, as PLCs are typically controllers, not computers. For example, you can use a device like the Revolutionary Pi to connect and transfer data across systems. Use the [FlowFuse Device Agent](https://flowfuse.com/platform/device-agent/) to install Node-RED on your device.

- Why FlowFuse Device Agent? It allows you to manage Node-RED remotely, enabling control, monitoring, and flow creation without the need for on-site visits. FlowFuse also offers a suite of enterprise-grade features such as collaboration, device management, and DevOps pipelines, which are essential in industrial environments. These features help streamline operations and ensure scalability in complex automation systems. [Sign up for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} to get started.

4. Verify that the device running Node-RED is in the same network as the PLC and can successfully ping the PLC. Also, a firewall should not block the S7 port (typically port 102).

## Integrating Siemens S7 PLCs with Node-RED

Now that everything is set up, let's integrate your Siemens S7 PLC with Node-RED. In this article, I’ll demonstrate the process using a Siemens S7-1212C PLC. I’ve connected it to a stack/tower light and will walk you through how to write data to the PLC to control this light. Later, I’ll show you how to read data and reflect the status of the light.

My program in TIA Portal is structured as shown below, utilizing DB (Data Blocks) and Q (physical outputs) to control devices. However, Node-RED can retrieve almost all types of data from the PLC. The process is similar for most data types.

![Ladder Logic to Control Outputs for Managing Lights](https://flowfuse.com/blog/2025/01/images/ladder-to-control-lights.png)*Ladder Logic to Control Outputs for Managing Lights*

Let’s break down what’s happening in the ladder logic above. First, we have open contacts, each with address variables defined in a separate Data Block. There are three open branches, each starting with an open contact. Each contact is connected to an output that alters the status of a Q physical address. Each Q corresponds to a physical output on the PLC, which is wired to the lights. When we change the status of a contact to "true," it activates the corresponding light by altering the state of the Q output, which reflects the change in the physical output.

### Installing the S7 Node

To communicate from Node-RED to the PLC, we need to install the S7 node, which allows Node-RED to interface with Siemens S7 PLCs. In this article, we will be using `node-red-contrib-s7`, which is quite popular. If this particular node is not suitable for your workflow you can find alternatives in the [Node-RED catalog](https://flows.nodered.org/search?term=siemens&type=node){rel="&#x22;nofollow&#x22;"}.

#### Steps to Install the S7 Node:

1. Open your Node-RED editor in a web browser.
2. Open the main menu by clicking the three horizontal lines in the top-right corner.
3. Click "Manage Palette" from the menu.
4. Switch to the "Install" tab and type `node-red-contrib-s7` in the search field.
5. Click "Install" next to the node name.

Once the installation is complete, the S7 nodes will be available in your Node-RED palette, and you can start using it to communicate with your Siemens S7 PLC.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

### Addressing Scheme for Variables in Node-RED with the S7 Node

Before we start, it's important to note that the variables and their addresses configured on the S7 endpoint follow a slightly different addressing scheme compared to those used in Step 7 or the TIA Portal. Therefore, when adding variables to the S7 node in Node-RED, you must ensure that you follow the correct addressing format outlined in the table below.

| **Node-RED Address** | **Step7 Equivalent** | **Data Type**       | **Description**                                  |
| -------------------- | -------------------- | ------------------- | ------------------------------------------------ |
| `DB5,X0.1`           | `DB5.DBX0.1`         | Boolean             | Bit 1 of byte 0 in DB5                           |
| `DB23,BYTE1`         | `DB23.DBB1`          | Number (Byte)       | Byte 1 (0-255) of DB23                           |
| `DB100,CHAR2`        | `DB100.DBB2`         | String              | Byte 2 of DB100 as Char                          |
| `DB42,INT3`          | `DB42.DBW3`          | Number (16-bit)     | Signed 16-bit number at byte 3 in DB42           |
| `DB57,WORD4`         | `DB57.DBW4`          | Number (16-bit)     | Unsigned 16-bit number at byte 4 in DB57         |
| `DB13,DINT5`         | `DB13.DBD5`          | Number (32-bit)     | Signed 32-bit number at byte 5 in DB13           |
| `DB19,DWORD6`        | `DB19.DBD6`          | Number (32-bit)     | Unsigned 32-bit number at byte 6 in DB19         |
| `DB21,REAL7`         | `DB21.DBD7`          | Floating Point (32) | Floating point number at byte 7 in DB21          |
| `DB2,S7.10*`         | -                    | String              | String (length 10) starting at byte 7 in DB2     |
| `I1.0`               | `I1.0`               | Boolean             | Bit 0 of byte 1 in input area                    |
| `Q2.1`               | `Q2.1`               | Boolean             | Bit 1 of byte 2 in output area                   |
| `M3.2`               | `M3.2`               | Boolean             | Bit 2 of byte 3 in memory area                   |
| `IB4`                | `IB4`                | Number (Byte)       | Byte 4 (0-255) in input area                     |
| `QB5`                | `QB5`                | Number (Byte)       | Byte 5 (0-255) in output area                    |
| `MB6`                | `MB6`                | Number (Byte)       | Byte 6 (0-255) in memory area                    |
| `IC7`                | `IB7`                | String              | Byte 7 of input area as Char                     |
| `QC8`                | `QB8`                | String              | Byte 8 of output area as Char                    |
| `MC9`                | `MB9`                | String              | Byte 9 of memory area as Char                    |
| `II10`               | `IW10`               | Number (16-bit)     | Signed 16-bit number at byte 10 in input area    |
| `QI12`               | `QW12`               | Number (16-bit)     | Signed 16-bit number at byte 12 in output area   |
| `MI14`               | `MW14`               | Number (16-bit)     | Signed 16-bit number at byte 14 in memory area   |
| `IW16`               | `IW16`               | Number (16-bit)     | Unsigned 16-bit number at byte 16 in input area  |
| `QW18`               | `QW18`               | Number (16-bit)     | Unsigned 16-bit number at byte 18 in output area |
| `MW20`               | `MW20`               | Number (16-bit)     | Unsigned 16-bit number at byte 20 in memory area |
| `IDI22`              | `ID22`               | Number (32-bit)     | Signed 32-bit number at byte 22 in input area    |
| `QDI24`              | `QD24`               | Number (32-bit)     | Signed 32-bit number at byte 24 in output area   |
| `MDI26`              | `MD26`               | Number (32-bit)     | Signed 32-bit number at byte 26 in memory area   |
| `ID28`               | `ID28`               | Number (32-bit)     | Unsigned 32-bit number at byte 28 in input area  |
| `QD30`               | `QD30`               | Number (32-bit)     | Unsigned 32-bit number at byte 30 in output area |
| `MD32`               | `MD32`               | Number (32-bit)     | Unsigned 32-bit number at byte 32 in memory area |
| `IR34`               | `IR34`               | Floating Point      | Floating point number at byte 34 in input area   |
| `QR36`               | `QR36`               | Floating Point      | Floating point number at byte 36 in output area  |
| `MR38`               | `MR38`               | Floating Point      | Floating point number at byte 38 in memory area  |
| `DB1,DT0`            | -                    | Date                | Timestamp in DATE\_AND\_TIME format              |
| `DB1,DTZ10`          | -                    | Date                | Timestamp in DATE\_AND\_TIME format (UTC)        |
| `DB2,DTL2`           | -                    | Date                | Timestamp in DTL format                          |
| `DB2,DTLZ12`         | -                    | Date                | Timestamp in DTL format (UTC)                    |
| `DB57,RWORD4`        | `DB57.DBW4`          | Number (16-bit)     | Unsigned 16-bit number, Little-Endian at byte 4  |
| `DB13,RDI5`          | `DB13.DBD5`          | Number (32-bit)     | Signed 32-bit number, Little-Endian at byte 5    |
| `MRW20`              | `MW20`               | Number (16-bit)     | Unsigned 16-bit number, Little-Endian at byte 20 |

For example, consider that you have a ladder logic program in the TIA Portal with addresses like DB5.DBX0.0 and DB13.DBW4. You must adjust the address format slightly when you want to use these in the Node-RED S7 node. In Node-RED, DB5.DBX0.0 would be represented as DB5,X0.0 and DB13.DBW4 would be written as DB13,WORD4. Essentially, you look at the TIA Portal address, find the corresponding format in the Node-RED address column, and use that format in the S7 node configuration.

If you wanted integrate Siemens LOGO, please refer to the node's [README](https://flows.nodered.org/node/node-red-contrib-s7){rel="&#x22;nofollow&#x22;"}, as the addressing differs.

### Configuring the S7 Node to Connect to the PLC

Now that you have all the necessary knowledge and setup, let's start by establishing a connection between Node-RED and your Siemens S7 PLC. The S7 node in Node-RED simplifies the process, making it easy to configure communication. Follow the steps below to connect and start interacting with your PLC

1. Drag the S7 node onto the Node-RED canvas.
2. Double-click on the S7 node and click on the "+" icon to add a PLC configuration.
3. Select "Ethernet (ISO on TCP)" as the transport protocol, then enter your PLC's IP address. The default port (102) is used for S7 communication, so leave it unchanged.
4. Set the Mode to "Rack," then enter the Rack ID and Slot ID. These values can be found in the TIA Portal under the Device View tab on your configured device.

![Image showing window from where you will get the Rack No and Slot No](https://flowfuse.com/blog/2025/01/images/showing-rack-and-slot.png){dataZoomable=""}*Image showing window from where you will get the Rack No and Slot No*

5. Enter the Cycle Time (interval for communication with the PLC) and Timeout Duration (maximum time to wait for a response).
6. Once done, switch to the Variables tab and add all the variables with the correct address and name you want to read or write.

![Adding Variables into s7 node](https://flowfuse.com/blog/2025/01/images/s7-config-variables.png){dataZoomable=""}*Adding Variables into s7 node*

7. After adding the variables, click Add and then Done.
8. Deploy the flow by clicking the top-right Deploy button. Once deployed, the connection status will be displayed at the bottom of the node. If connected successfully, it will show a green squre with "online" status.

![Configuring S7 node for connection](https://flowfuse.com/blog/2025/01/images/s7-connection-configuration.png){dataZoomable=""}*Configuring S7 node for connection*

### Writing Data to the PLC

Now that you’ve configured the connection, it’s time to use Node-RED to write data to the PLC to control light.

1. Drag the s7-out node onto the canvas.
2. Double-click on the node and select the variable to which you want to update or write a value.
3. Select the PLC configuration that we have added.
4. Click Done.

![Configuring S7-out Node to write data to plc](https://flowfuse.com/blog/2025/01/images/configuring-s7-out-node.png){dataZoomable=""}*Configuring S7-out Node to write data to plc*

5. The node is now ready to write data to the PLC. You can use standard Node-RED nodes like Inject, Change, or Function to create a workflow that sends the data. Ensure the data type matches the configuration set in the PLC program. For example, in my ladder logic, I need to modify the status of individual open contacts, each with its own address, such as DB1.DBX0.0, DB1.DBX0.1, and DB1.DBX0.2, to control the tower lights. Setting these contacts to TRUE will turn on the red, yellow, and green lights, respectively. You can send the data using the nodes I’ve mentioned, or you can build a custom dashboard with [FlowFuse Dashboard](https://flowfuse.com/platform/dashboard/) for easier interaction.
6. Once your flow is set up and the s7-out node for each variable is configured, click Deploy in the top-right corner to activate the flow.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: AilWMNPzP1Q
---
::

In the video above, the dashboard interface is built to control the stack light. At the end of this article, I will provide the complete flow for you to download.

If you're building a dashboard, keep in mind that while you can create it on Node-RED within the remote instance on FlowFuse Device Agent, you won’t be able to access it remotely across the editor tunnel. You can of course access it locally on the device or on the local LAN. For this demonstration, I wish to access the dashboard remotely across the internet and so I will create the dashboard in a hosted instance of Node-RED and use the FlowFuse Projects nodes to simply and securely pass the necessary values to and from the remote Node-RED instance. For more details on how to set this up, check out our article: [Exploring FlowFuse Project Nodes](https://flowfuse.com/blog/2024/10/exploring-flowfuse-project-nodes/).

### Reading Data from the PLC

Now that we’ve covered how to write data to your Siemens S7 PLC, let's move on to reading data from it. Node-RED makes it easy to retrieve important information such as the status of inputs, outputs, or internal memory. By pulling this data into your workflows or visualizing it on a dashboard, you can monitor key parameters in real time and gain valuable insights.

However, before we dive in, it's important to consider that reading individual data points one by one in large-scale manufacturing systems can lead to delays. This approach may not be efficient, especially when dealing with a large number of data points. For more information on these challenges and potential solutions, you can refer to this article: [Modernize Your Legacy Industrial Data - Part 2](https://flowfuse.com/blog/2023/09/modernize-your-legacy-industrial-data-part2/).

To address this issue, you can optimize data retrieval by storing output status values in a single word or double word within the PLC. For our example, I have created a custom function in my program that assigns the output values to individual bits of the word.

![Ladder diagram showing a custom function that stores the status of outputs in a single word within the PLC.](https://flowfuse.com/blog/2025/01/images/custom-function-storing-bits-in-word.png){dataZoomable=""}&#x2A;Custom ladder diagram function storing output statuses in a single word for optimized data retrieval.*

There are several ways to implement this, and depending on your system’s needs, some methods may be more efficient than others. In this case, the output values are stored in a single word within the PLC, as shown in the ladder diagram above. This is not the only correct method, it's simply one approach that works for this particular scenario. Feel free to adapt or explore other methods that might better suit your setup.

Additionally, if the data you’re reading is mission-critical and you can't afford to lose any, consider using a FIFO stack or buffer in your PLC program. This method ensures that even if there is a network outage or computer problem, no data is lost as it will remain siting in the stack until your Node-RED is back on line and retrieves it. This ensures no gaps or interruptions in your data and guarantees data integrity.

Now, let’s begin reading the data from the PLC.

1. Drag the `s7-in` node onto the canvas.
2. Double-click on the node to open the configuration and select the appropriate PLC configuration from the list of available connections.
3. Choose the appropriate mode based on your requirements. If you want to read only one variable, select "Single Variable Mode". In this mode, the "Variable" dropdown will allow you to select only a single variable at a time. If you need to read multiple variables, you can select "All Variables" mode, but be aware that the node might still process each request sequentially, depending on its internal workings (which is not fully documented). This can be inefficient when dealing with hundreds of variables.
4. Choose the variable that corresponds to the word or double word containing all the data points you want to read. For example, if you’ve configured the word in the PLC as `DB.DBW2`, the format in the s7-in node will be `DB,WORD2`.
5. Enable the "Emit only when value changes (diff)" option to ensure that the node only triggers when the value of the variable changes, reducing unnecessary reads and improving efficiency.
6. Once your configuration is set, click "Done" and then deploy the flow to start reading data from the PLC.

![Configuring S7-in Node to Read data from plc](https://flowfuse.com/blog/2025/01/images/configuring-s7-in-node.png){dataZoomable=""}*Configuring S7-in Node to Read data from plc*

You can add a "Debug" node to the `s7-in` node's output to verify that the data is being read correctly.

Once you see the printed data, you might be surprised, or perhaps you already expected this: since the word data type we're reading is not directly available in Node.js or Node-RED, we'll receive it as an integer. But don't worry, you can convert it into the format that suits your needs using node-red-contrib-buffer-parser. In this integer scenario, you'll need to shift the bits or extract individual values to match your desired output, such as isolating specific bits to represent different statuses or control points. The flow provided at the end demonstrates the implementation of this conversion.

Now that you have the desired format for your output data, you may want to build a dashboard interface with LEDs, gauges, or charts to monitor and visualize the data you've retrieved. You can use the FlowFuse Dashboard, as suggested earlier.

The video below shows the updated dashboard interface used to monitor the stack light LED status:

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: Nlyk_BATKGE
---
::

Here is the flow you can import into your FlowFuse remote instance and deploy. Ensure that you have installed `node-red-contrib-s7` and `node-red-contrib-buffer-parser`. This flow includes S7 nodes for interacting with the S7 PLC and Project nodes for communicating with the FlowFuse hosted instance, where you will build the dashboard.

::render-flow
```json
[{"id":"0ffc8c2703b5e059","type":"group","z":"FFF0000000000001","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["061313277591a004","a8499bc2443f0bd9","2974dd47fda54b9c","4c009f6076f47eb6","f4378d1e7c268e1e","63abd67743263739"],"x":54,"y":99,"w":732,"h":202},{"id":"061313277591a004","type":"s7 out","z":"FFF0000000000001","g":"0ffc8c2703b5e059","endpoint":"f2f06ce027c97e4d","variable":"Button_1","name":"Button to Turn the RED Light ON","x":620,"y":140,"wires":[]},{"id":"a8499bc2443f0bd9","type":"s7 out","z":"FFF0000000000001","g":"0ffc8c2703b5e059","endpoint":"f2f06ce027c97e4d","variable":"Button_2","name":"Button to turn the Yellow light ON","x":620,"y":200,"wires":[]},{"id":"2974dd47fda54b9c","type":"s7 out","z":"FFF0000000000001","g":"0ffc8c2703b5e059","endpoint":"f2f06ce027c97e4d","variable":"Button_3","name":"Button to turn Green light  ON","x":610,"y":260,"wires":[]},{"id":"4c009f6076f47eb6","type":"project link in","z":"FFF0000000000001","g":"0ffc8c2703b5e059","name":"Project in node to control the red light","project":"all","broadcast":true,"topic":"light_control_red","x":230,"y":140,"wires":[["061313277591a004"]]},{"id":"f4378d1e7c268e1e","type":"project link in","z":"FFF0000000000001","g":"0ffc8c2703b5e059","name":"Project in node to control the yellow light","project":"all","broadcast":true,"topic":"light_control_yellow","x":240,"y":200,"wires":[["a8499bc2443f0bd9"]]},{"id":"63abd67743263739","type":"project link in","z":"FFF0000000000001","g":"0ffc8c2703b5e059","name":"Project in node to control the green light","project":"all","broadcast":true,"topic":"light_control_green","x":240,"y":260,"wires":[["2974dd47fda54b9c"]]},{"id":"f2f06ce027c97e4d","type":"s7 endpoint","transport":"iso-on-tcp","address":"192.168.1.6","port":"102","rack":"0","slot":"1","localtsaphi":"01","localtsaplo":"00","remotetsaphi":"01","remotetsaplo":"00","connmode":"rack-slot","adapter":"","busaddr":"2","cycletime":"1000","timeout":"2000","name":"S7 Connection Configuration","vartable":[{"addr":"DB1,X0.0","name":"Button_1"},{"addr":"DB1,X0.1","name":"Button_2"},{"addr":"DB1,X0.2","name":"Button_3"},{"addr":"DB1,WORD2","name":"LightStatus"}]},{"id":"23fd40630dbef712","type":"group","z":"FFF0000000000001","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["a45637418005d0e5","a8ea1622d1fad4ba","8d9a9dc4183a778e","d60a74a5430df7ae"],"x":54,"y":339,"w":972,"h":82},{"id":"a45637418005d0e5","type":"s7 in","z":"FFF0000000000001","g":"23fd40630dbef712","endpoint":"f2f06ce027c97e4d","mode":"single","variable":"LightStatus","diff":true,"name":"","x":150,"y":380,"wires":[["d60a74a5430df7ae"]]},{"id":"a8ea1622d1fad4ba","type":"project link out","z":"FFF0000000000001","g":"23fd40630dbef712","name":"project out node to send the light status","mode":"link","broadcast":true,"project":"c51f38c2-6c80-442a-a9e2-10ddd68fb606","topic":"light_status","x":840,"y":380,"wires":[]},{"id":"8d9a9dc4183a778e","type":"buffer-parser","z":"FFF0000000000001","g":"23fd40630dbef712","name":"","data":"payload","dataType":"msg","specification":"spec","specificationType":"ui","items":[{"type":"bool","name":"red","offset":0,"length":1,"offsetbit":0,"scale":"1","mask":""},{"type":"bool","name":"yellow","offset":0,"length":1,"offsetbit":1,"scale":"1","mask":""},{"type":"bool","name":"green","offset":0,"length":1,"offsetbit":2,"scale":"1","mask":""},{"type":"bool","name":"all","offset":0,"length":16,"offsetbit":0,"scale":"1","mask":""}],"swap1":"","swap2":"","swap3":"","swap1Type":"swap","swap2Type":"swap","swap3Type":"swap","msgProperty":"payload","msgPropertyType":"str","resultType":"keyvalue","resultTypeType":"return","multipleResult":false,"fanOutMultipleResult":false,"setTopic":true,"outputs":1,"x":530,"y":380,"wires":[["a8ea1622d1fad4ba"]]},{"id":"d60a74a5430df7ae","type":"buffer-maker","z":"FFF0000000000001","g":"23fd40630dbef712","name":"","specification":"spec","specificationType":"ui","items":[{"name":"1stword","type":"uint16le","length":1,"dataType":"msg","data":"payload"}],"swap1":"","swap2":"","swap3":"","swap1Type":"swap","swap2Type":"swap","swap3Type":"swap","msgProperty":"payload","msgPropertyType":"str","x":330,"y":380,"wires":[["8d9a9dc4183a778e"]]}]
```
::

Below is the flow that you can import and deploy into the hosted instance created on FlowFuse. With this flow, you'll have a dashboard to control and monitor the tower lights. Just make sure you have installed `@flowfuse/node-red-dashboard` and `@flowfuse/node-red-dashboard-2-ui-led`, and ensure the hosted instance is in the same FlowFuse team as your remote instance.

::render-flow
```json
[{"id":"1f56099d53798b99","type":"group","z":"eb351e503901d04f","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["1e6a379c83bac6b4","f015125886fec5a6","76c696f160db3ca2","1974cfc417898151","9c503fe31081dc2f","9501e2eb7690a0b5"],"x":74,"y":79,"w":652,"h":202},{"id":"1e6a379c83bac6b4","type":"ui-button","z":"eb351e503901d04f","g":"1f56099d53798b99","group":"d4102809d229cb95","name":"","label":"YELLOW","order":5,"width":"3","height":"2","emulateClick":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","iconPosition":"left","payload":"","payloadType":"str","topic":"topic","topicType":"msg","buttonColor":"yellow","textColor":"","iconColor":"","enableClick":false,"enablePointerdown":true,"pointerdownPayload":"1","pointerdownPayloadType":"num","enablePointerup":true,"pointerupPayload":"0","pointerupPayloadType":"num","x":160,"y":180,"wires":[["1974cfc417898151"]]},{"id":"f015125886fec5a6","type":"ui-button","z":"eb351e503901d04f","g":"1f56099d53798b99","group":"d4102809d229cb95","name":"","label":"RED","order":4,"width":"3","height":"2","emulateClick":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","iconPosition":"left","payload":"","payloadType":"str","topic":"topic","topicType":"msg","buttonColor":"red","textColor":"","iconColor":"","enableClick":false,"enablePointerdown":true,"pointerdownPayload":"1","pointerdownPayloadType":"num","enablePointerup":true,"pointerupPayload":"0","pointerupPayloadType":"num","x":150,"y":120,"wires":[["9501e2eb7690a0b5"]]},{"id":"76c696f160db3ca2","type":"ui-button","z":"eb351e503901d04f","g":"1f56099d53798b99","group":"d4102809d229cb95","name":"","label":"GREEN","order":6,"width":"3","height":"2","emulateClick":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","iconPosition":"left","payload":"","payloadType":"str","topic":"topic","topicType":"msg","buttonColor":"green","textColor":"","iconColor":"","enableClick":false,"enablePointerdown":true,"pointerdownPayload":"1","pointerdownPayloadType":"num","enablePointerup":true,"pointerupPayload":"0","pointerupPayloadType":"num","x":160,"y":240,"wires":[["9c503fe31081dc2f"]]},{"id":"1974cfc417898151","type":"project link out","z":"eb351e503901d04f","g":"1f56099d53798b99","name":"Project out node to control the yellow light","mode":"link","broadcast":true,"project":"c51f38c2-6c80-442a-a9e2-10ddd68fb606","topic":"light_control_yellow","x":530,"y":180,"wires":[]},{"id":"9c503fe31081dc2f","type":"project link out","z":"eb351e503901d04f","g":"1f56099d53798b99","name":"Project out node to control the green light","mode":"link","broadcast":true,"project":"c51f38c2-6c80-442a-a9e2-10ddd68fb606","topic":"light_control_green","x":520,"y":240,"wires":[]},{"id":"9501e2eb7690a0b5","type":"project link out","z":"eb351e503901d04f","g":"1f56099d53798b99","name":"Project out node to control the red light","mode":"link","broadcast":true,"project":"c51f38c2-6c80-442a-a9e2-10ddd68fb606","topic":"light_control_red","x":520,"y":120,"wires":[]},{"id":"d4102809d229cb95","type":"ui-group","name":"Group 1","page":"62085b96f178f643","width":"3","height":1,"order":1,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"62085b96f178f643","type":"ui-page","name":"Page 1","ui":"02c25e8a30f9379d","path":"/page1","icon":"home","layout":"notebook","theme":"f6f5e7ae33bf6878","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"02c25e8a30f9379d","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"showPageTitle":true,"navigationStyle":"default","titleBarStyle":"hidden"},{"id":"f6f5e7ae33bf6878","type":"ui-theme","name":"Default Theme","colors":{"surface":"#ffffff","primary":"#0094ce","bgPage":"#1a1a1a","groupBg":"#000000","groupOutline":"#000000"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"82cc6997fddd0b4b","type":"group","z":"eb351e503901d04f","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["d163a7ab23f7458f","20d211683534362b","b1477193956e591b","fb8801a4accc3c15","2f62948afcfde259","6966f129e718d20a","a5cecf8e8adf6eef"],"x":74,"y":299,"w":872,"h":202},{"id":"d163a7ab23f7458f","type":"ui-led","z":"eb351e503901d04f","g":"82cc6997fddd0b4b","name":"Status of RED light","group":"d4102809d229cb95","order":1,"width":"1","height":"3","label":"","labelPlacement":"left","labelAlignment":"left","states":[{"value":"true","valueType":"bool","color":"#ff0000"},{"value":"false","valueType":"bool","color":"#787878"}],"allowColorForValueInMessage":false,"shape":"circle","showBorder":true,"showGlow":true,"x":810,"y":340,"wires":[]},{"id":"20d211683534362b","type":"ui-led","z":"eb351e503901d04f","g":"82cc6997fddd0b4b","name":"Status of Yellow light","group":"d4102809d229cb95","order":2,"width":"1","height":"3","label":"","labelPlacement":"left","labelAlignment":"left","states":[{"value":"true","valueType":"bool","color":"#c8ff00"},{"value":"false","valueType":"bool","color":"#787878"}],"allowColorForValueInMessage":false,"shape":"circle","showBorder":true,"showGlow":true,"x":820,"y":400,"wires":[]},{"id":"b1477193956e591b","type":"ui-led","z":"eb351e503901d04f","g":"82cc6997fddd0b4b","name":"Status of Green light","group":"d4102809d229cb95","order":3,"width":"1","height":"3","label":"","labelPlacement":"left","labelAlignment":"left","states":[{"value":"true","valueType":"bool","color":"#41891a"},{"value":"false","valueType":"bool","color":"#787878"}],"allowColorForValueInMessage":false,"shape":"circle","showBorder":true,"showGlow":true,"x":820,"y":460,"wires":[]},{"id":"fb8801a4accc3c15","type":"change","z":"eb351e503901d04f","g":"82cc6997fddd0b4b","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.red","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":600,"y":340,"wires":[["d163a7ab23f7458f"]]},{"id":"2f62948afcfde259","type":"change","z":"eb351e503901d04f","g":"82cc6997fddd0b4b","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.yellow","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":600,"y":400,"wires":[["20d211683534362b"]]},{"id":"6966f129e718d20a","type":"change","z":"eb351e503901d04f","g":"82cc6997fddd0b4b","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.green","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":600,"y":460,"wires":[["b1477193956e591b"]]},{"id":"a5cecf8e8adf6eef","type":"project link in","z":"eb351e503901d04f","g":"82cc6997fddd0b4b","name":"project in node to receive the light status","project":"all","broadcast":true,"topic":"light_status","x":260,"y":400,"wires":[["fb8801a4accc3c15","2f62948afcfde259","6966f129e718d20a"]]}]
```
::

## Troubleshooting

When you try to establish a connection with the PLC, you may encounter the following error. This error occurs because your device has established the connection but is unable to communicate. To resolve this issue, ensure that you have configured all the settings mentioned in the prerequisites. If the problem persists, it could be because your PLC and the device running Node-RED are on different networks.

!["Error: This service is not implemented on the modeul or frame error was reported"](https://flowfuse.com/blog/2025/01/images/error.png){dataZoomable=""}&#x2A;"Error: This service is not implemented on the modeul or frame error was reported"*

Make sure the IP addresses of your device and PLC are in the same subnet. If the PLC is connected to the internet via a router, all devices (PLC, Node-RED device, and router) should have IP addresses within the same subnet. For example, if your PLC has the address 192.168.1.1, ensure that the other devices have IP addresses in the range 192.168.1.x.

## Conclusion

Integrating Siemens S7 PLCs with Node-RED opens up powerful automation possibilities with minimal complexity. By following the steps outlined in this guide, you can easily connect your PLC to Node-RED, control devices, and visualize real-time data on dashboards. Whether you're writing data to control outputs or reading sensor values, Node-RED offers a flexible, user-friendly platform for industrial automation.

Beyond Siemens S7, FlowFuse connects Allen-Bradley, Omron, Beckhoff, and any Modbus or OPC UA-enabled PLC to MQTT, cloud, and enterprise systems. See the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/) for all supported protocols and use cases.


# MQTT: The Frontrunner for Your UNS Broker - Part 1

Choosing the right broker for your UNS is crucial. It must support real-time data, scale easily, and integrate seamlessly with devices and services. MQTT often comes out as the best choice for these needs.

In this first part of our series, we’ll explain why MQTT is the standout choice for UNS implementations. With its focus on lightweight, real-time messaging and robust reliability, MQTT delivers the performance IIoT environments demand, making it the perfect fit for a future-proof, scalable UNS.

The [Unified Namespace (UNS)](https://flowfuse.com/use-cases/uns/) is a data architecture (not just a tool or new technology) that centralizes and organizes data from various sources into a single, unified structure. It eliminates data silos by providing a standardized way to represent, access, and share information across different devices, systems, and services. For more information on what is UNS, read our article: [Introduction to the Unified Namespace](https://flowfuse.com/blog/2023/12/introduction-to-unified-namespace/).

When choosing a broker for your UNS, it's crucial to consider how well the selected broker fits the specific requirements of your IIoT environment, including the types of devices and systems involved, as well as factors like scalability, reliability, and ease of integration. Several options are available alongside MQTT, including [AMQP](https://flowfuse.com/node-red/protocol/amqp/), [Kafka](https://flowfuse.com/blog/2024/03/using-kafka-with-node-red/), and cloud message brokers like AWS Kinesis and GCP Pub/Sub. While these alternatives offer unique features, MQTT stands out, and we’ll explain why later in this article. But If you’re interested in a brief overview of why these alternatives are not the best fit for UNS, check out our article: [Unified Namespace: What Broker to Use?](https://flowfuse.com/blog/2024/01/unified-namespace-what-broker/)

There is also an ongoing debate regarding the use of OPC-UA and other protocols for implementing UNS. While I won’t dive into this in detail here as i havent explored it much yet, I encourage you to start with the approach we call reverse engineering. First, understand why MQTT is the preferred choice for implementing UNS, and then explore how its features align with UNS needs. From there, you can evaluate whether other protocols offer similar capabilities. By following this process, you will find the right answer of your questions.

## Background of MQTT

Before diving into its specific advantages for UNS, let’s take a brief look at the history of **MQTT** and how it became the backbone of modern IoT communication.

[MQTT](https://flowfuse.com/node-red/protocol/mqtt/) was developed in the late 1990s by Andy Stanford-Clark at IBM and Arlen Nipper at Eurotech to address communication challenges in low-bandwidth, unreliable networks. This early focus on lightweight messaging paved the way for MQTT to become a pioneering solution for the rapidly expanding IoT space.

Since then, MQTT has evolved significantly. The protocol has gone through several iterations, from MQTT 3.1.1 to the more feature-rich MQTT 5.0, each version enhancing the protocol's capabilities to meet the demands of an increasingly connected world. Today, more than 25 years later, MQTT remains the **de facto protocol** for IoT applications, and its simplicity, scalability, and reliability continue to make it an ideal choice for industrial systems.

But, what exactly makes MQTT the frontrunner for UNS implementations? Let's take a deeper look at some of its key features?

## Publish-Subscribe Model and Event-Driven Architecture

One of the standout features of MQTT is its publish-subscribe (Pub/Sub) model, which is the primary need of an UNS. In this model, data producers (such as sensors or devices) don’t need to know who is receiving the data or how many consumers are out there. Instead, they publish their data to a central broker, and any consumer (like a monitoring system, data warehouse, or analytics engine) that is interested simply subscribes to the relevant data stream.

This approach decouples producers and consumers, removing the need for direct, point-to-point connections between them. In traditional systems, every device would need to know about every other device it communicates with, leading to a messy, tightly coupled network. As your IIoT ecosystem grows, managing these connections becomes increasingly difficult and prone to error. But with MQTT’s Pub/Sub model, adding new devices or services is seamless and doesn’t disrupt existing data flows.

Beyond this, MQTT’s event-driven architecture takes the system to a whole new level of efficiency and responsiveness. Imagine a scenario where a machine detects an issue, rather than waiting for a periodic check-in, the event is immediately sent to the right consumer, triggering an alert in real time. This push mechanism is far more efficient than traditional polling, where systems continuously ask, “Is there new data yet?” and waste precious resources in the process.

With MQTT, data is pushed as soon as it’s available, enabling faster decision-making and real-time responses. This means events like machine faults or environmental changes are addressed immediately, making the Our UNS more agile, responsive, and capable of scaling as needed which is one of priamary need of IIoT environemnt.

If you’d like to understand the importance of Publish-Subscribe (Pub/Sub) architecture in detail for UNS, I highly recommend reading our article: [Why UNS Needs Pub/Sub](https://flowfuse.com/blog/2024/11/why-pub-sub-in-uns/).

### Low Latency and Lightweight Messaging

Downtime in industrial operations can be very costly, ranging from [[]{.katex-mathml}[[[]{.strut style="height:0.8389em;vertical-align:-0.1944em;"}[15]{.mord}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[000]{.mord}[t]{.mord.mathnormal}[o]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 20,000 per minute or more. For engineers and operators watching over machines, waiting for data can mean the difference between smooth operations and expensive disruptions, If you're interested in learning more about downtime, read this research by Siemens from 2022: [True Cost of Downtime 2022](https://assets.new.siemens.com/siemens/assets/api/uuid:3d606495-dbe0-43e4-80b1-d04e27ada920/dics-b10153-00-7600truecostofdowntime2022-144.pdf){rel="&#x22;nofollow&#x22;"}. Low-latency messaging is key in these situations, which is why data architectures like UNS are being explored to make sure systems and devices in your IIoT setup communicate without delays. MQTT is the protocol that makes this possible.

As we explored, MQTT uses a publish-subscribe model, which is built for real-time communication with minimal delay. Unlike traditional request-response systems that can cause delays due to constant querying, MQTT keeps a persistent connection open. Once a device connects, it can immediately send data or receive updates on important topics, cutting out the need for repeated requests and making sure data flows instantly. This helps engineers make decisions and take action faster.

In addition to being fast, MQTT is very efficient. Its messages are small and use little bandwidth, important when working with low-bandwidth networks or many connected devices. Even with limited resources, MQTT allows devices to send data without overwhelming the system. The result? As soon as a sensor detects a change, like a temperature spike or a production issue, it can send the information right away to the right system, triggering immediate actions to avoid costly downtime.

![MQTT Packet Structer](https://flowfuse.com/blog/2025/01/images/mqtt-packate-size.png)  *MQTT Packet Structer*

### Reliability

When it comes to building a UNS, reliability is absolutely crucial. Missing or duplicate data can lead to poor decision-making, system malfunctions, or even costly downtime, things no one wants in their IIoT environment.

This is where MQTT truly shines. It’s built with a Quality of Service (QoS) mechanism that allows you to control how reliably your messages are delivered. Depending on the level you choose, you can ensure that data is delivered exactly as you need it, without compromising on system performance.

MQTT offers three levels of QoS to suit different use cases:

- QoS 0 - "At most once": The message is delivered once and isn’t acknowledged. This is fine for non-critical data where the occasional loss of a message is acceptable.
- QoS 1 - "At least once": The message is delivered at least once, with an acknowledgment to ensure it was received. This is ideal for most IIoT applications, where you need reliable delivery, but duplicate messages are not a major concern.
- QoS 2 - "Exactly once": This guarantees the message is delivered exactly once, no duplicates, no omissions. It's the best choice for mission-critical applications where data integrity is paramount.

Now, some other protocols like AMQP or Kafka also provide reliability guarantees, but they tend to be more complex and come with heavier infrastructure requirements. MQTT, on the other hand, offers a simple and lightweight design while still giving you just the right level of reliability for most IIoT scenarios. You can scale your network with ease, all while maintaining a high standard of reliability in your data flows.

MQTT is the ideal broker for a UNS in IIoT environments, offering real-time, low-latency communication through its Publish-Subscribe model. With Quality of Service (QoS) options for reliable data delivery, it balances performance, scalability, and simplicity. MQTT’s lightweight design makes it perfect for handling large-scale, mission-critical data flows without the complexity of heavier protocols.

In Part 2, we will explore MQTT's scalability, topic organization, and wide connectivity providing even more compelling reasons why it is the ultimate choice for UNS brokers.

If you're looking to build your own UNS with MQTT, check out our step-by-step [Article on Building UNS with FlowFuse](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/). Plus, we've made it even easier by offering a built-in MQTT broker service within the FlowFuse Platform, allowing you to manage all your MQTT clients, devices, services, and data from a single, centralized interface. Check it out [here](https://flowfuse.com/blog/2024/10/announcement-mqtt-broker/?utm_campaign=60718323-BCTA&utm_source=blog&utm_medium=cta%20mqtt%20announcement&utm_term=high_intent&utm_content=MQTT%3A%20The%20Frontrunner%20for%20Your%20UNS%20Broker%20-%20Part%201)!


# MQTT: The Frontrunner for Your UNS Broker - Part 2

In [Part 1](https://flowfuse.com/blog/2025/01/mqtt-frontrunner-for-uns/), we discussed the reasons behind MQTT's popularity as a choice for Unified Namespace (UNS) implementations; focusing on its lightweight design, low latency, and reliable message delivery. In this second part, we’ll explore additional factors that further establish MQTT as the leading protocol for UNS brokers, diving into its connectivity, scalability, structured topic management.

## Wide Connectivity

For your UNS to be truly effective, it must be able to connect seamlessly with every part of your IIoT environment, whether it’s a device or the cloud. MQTT is an excellent protocol for this because it’s widely adopted in both cloud-based systems and industrial environments.

In a typical industrial data architecture, you typically have a mix of physical devices (like sensors and machines) and cloud systems. To make real-time decisions, data needs to flow seamlessly from the shop floor to the cloud. MQTT excels at connecting modern devices with the cloud. However, one challenge is that it doesn’t natively support older systems that typically use protocols like OPC UA or MODBUS.

This isn’t a major issue, though. You can bridge the gap using tools like FlowFuse and Node-RED, which allow MQTT to communicate with older systems.

Overall, MQTT has better compatibility than many other protocols. Some other protocols may offer better compatibility, but they can hardly surpass MQTT in meeting the core requirements of a UNS.

![MQTT's Compatibility](https://flowfuse.com/blog/2025/01/images/mqtt-compatiblity.png){dataZoomable=""}{width="550px"}
*MQTT's Compatibility*

## Easily Scalable

A UNS broker needs to be able to grow as your factory or system expands. What starts with just a few sensors or devices might quickly scale up to hundreds or thousands over time. Can MQTT handle this growth? Absolutely.

MQTT's lightweight architecture, based on a simple publish-subscribe model, makes it easy to scale. Adding new devices doesn’t disrupt existing operations. The system can handle thousands of devices and connections without performance issues. As your network grows, new devices can easily connect to the broker and start exchanging data without major changes to the infrastructure.

MQTT brokers handle large volumes of data and can distribute messages to many clients at once. This ensures that as more devices are added, the system remains stable. The broker can also scale horizontally, meaning you can add more brokers or resources to handle the increased load, without affecting the performance or reliability of the system.

## Semantic Hierarchy with Topics

When setting up a UNS, it’s not just about collecting all your data in one place, it’s about organizing it so that it’s easy to navigate. A semantic hierarchy helps do this by arranging data from broad categories down to more specific details. For example, in a factory, you might have levels like factory, area, line, and machine, with data points like temperature or humidity at the bottom. This is similar to how files are organized in folders, making it simple to find what you need.

MQTT works well for this kind of organization because its topics are already structured in a hierarchical way. Topics in MQTT are like paths that break down data into different levels, such as `factory/area-2/line-1/machine-5/temperature`. You can easily follow these paths to find the exact data you need. Furthermore, MQTT supports wildcard characters, which offer flexibility for subscriptions. The # wildcard matches all levels beneath a given level, so a subscription to `factory/#` will match any topic under the "factory" level, regardless of how deep the path goes. Similarly, the `+` wildcard matches only a single level, so `factory/+/line-1/machine-5/temperature` will match any topic that follows the same structure but with different areas.

While AMQP and Kafka also support topics and wildcards, they handle them differently. AMQP uses routing keys for message routing rather than a direct hierarchical topic structure like MQTT. Though AMQP has a topic exchange for routing based on patterns (similar to topics), it doesn’t provide the same natural hierarchical organization. Kafka, on the other hand, uses a flat topic model without a hierarchy, which can make it more difficult to maintain clarity and structure as the system grows in complexity. While both AMQP and Kafka can still be used in a UNS, their lack of a natural topic hierarchy makes them more challenging manage compared to MQTT, which provides a simpler, more intuitive way to organize and access data.

In conclusion, MQTT is an excellent choice for your UNS broker because it offers simplicity, scalability, and efficient data organization. Its lightweight design ensures smooth performance as your system grows, while the publish-subscribe model decouples producers and consumers, allowing them to operate independently. This reduces direct dependencies between devices and systems, making the overall architecture more flexible and easier to scale. MQTT’s hierarchical topic structure further simplifies data management and access. Compared to other options like AMQP and Kafka, MQTT provides a more intuitive, reliable, and scalable and most importantly simple solution for building a Unified Namespace that can adapt to future needs.

## Build Your UNS with FlowFuse Now

Now that you understand why MQTT is the best choice for your UNS, it’s time to build it. FlowFuse is the ideal platform for implementing your UNS with MQTT.

Please read our article: [Building Your UNS with FlowFuse](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/) where I show you how to build it quickly, just in 15 minutes!

**Why choose FlowFuse?**

FlowFuse is an industrial data platform that leverages the power of Node-RED, a popular open-source low-code platform for industrial automation. With over 5000 community-contributed nodes, it simplifies the process of collecting, transforming, and integrating data from a wide variety of industrial hardware and services, supporting nearly all industrial protocols. This means you have nearly everything you need to implement a UNS, all you need is the MQTT broker service.

Good news! Recently, FlowFuse has added a built-in MQTT broker service within the platform, making it even easier to manage your MQTT connections. This includes an interface for securely managing MQTT clients and, most importantly, a comprehensive topic hierarchy monitoring tool that’s ideal for managing your UNS.

FlowFuse not only allows you to build and manage your UNS, but also provides a collaborative environment where teams can work in real time. It offers scalability, security, and ease of use, making it simple to grow your system as your needs evolve.

With FlowFuse, you get everything you need to handle data pipelines, implement a UNS, and scale efficiently, all within a single platform.


# Why FlowFuse is the Complete Toolkit For Building UNS?

Unified Namespace (UNS) is changing the way data is managed in industrial environments. It’s becoming the key to more successful and productive operations. Many organizations have already implemented it, and others are still figuring out the best approach and platform to implement it. There are so many tools out there; how do you know which one is right for your UNS? It’s a big decision, and it can be overwhelming. The good news? FlowFuse is the toolkit you’ve been looking for! It’s an all-in-one platform to build your UNS, and it’s open-source!

At its core, a Unified Namespace ([UNS](https://flowfuse.com/use-cases/uns/)) is a data architecture that centralizes all your data from devices, sensors, and systems into a single hub. It helps you make sense of everything by organizing, structuring, and standardizing your data for easy access and analysis. Instead of dealing with fragmented data silos, you get a unified, real-time view of your entire operation.

Think of it as the brain of your entire operation, connecting all your business events in one place. Whether you're tracking performance, optimizing workflows, or making real-time decisions, a well-designed UNS makes it all possible. For more details, check out our article: [Introduction to the Unified Namespace](https://flowfuse.com/blog/2023/12/introduction-to-unified-namespace/).

## **Core Components of UNS and How FlowFuse Fits In**

To truly understand why FlowFuse is the ultimate toolkit for building and managing UNS, we need to explore its core components and see how FlowFuse enhances each one to help create a successful Unified Namespace in industrial IoT environments.

![Core Components of UNS](https://flowfuse.com/blog/2025/01/images/components-of-uns.jpeg){dataZoomable=""}:br*Core Components of UNS: Key Elements to Consider When Building Your UNS*

#### **1. Connectivity Layer**

The Connectivity Layer is the foundation of your UNS ecosystem. It’s what collects data from all your devices and systems, whether that’s sensors on the factory floor, PLCs, or IoT devices, and sends it to your UNS. Without a strong connectivity layer, your UNS won’t have the data it needs to create a complete view of your operations.

**How FlowFuse Helps:**

This is where FlowFuse comes in. Built on the powerful Node-RED platform, FlowFuse takes the complexity out of connecting devices. Whether you're dealing with legacy systems (think Modbus or OPC-UA) or the latest IoT devices (like MQTT or HTTP), FlowFuse ensures that everything can speak the same language. It connects your old and new technologies, effortlessly streaming data into your UNS.

With more than 5,000 available community contributed nodes, FlowFuse helps bridge the gap between old and new technologies. For example, if you have machines that use Modbus and new sensors using MQTT, FlowFuse can help them all send data into your UNS without any issues.

#### **2. Data Transformation Layer**

Once you’ve connected your devices and started collecting data, it’s time to send that data to your UNS. However, before that happens, there's an important step: data transformation. The data you collect often comes in different formats, units, or structures, which can create confusion and inefficiency when trying to use it across your system.

This is where the Data Transformation Layer plays a key role. It’s responsible for standardizing and enriching the data, ensuring it’s consistent, accurate, and ready to be used by your entire IIoT system. Without this layer, your data would remain fragmented and inconsistent, making integration difficult and analysis unreliable. Without proper transformation, your UNS wouldn’t be a true UNS; it would just be an data repository or dump.

**How FlowFuse Fits In:**

FlowFuse simplifies data transformation with its intuitive Node-RED interface. This allows engineers to set up complex data processing workflows with minimal effort. Whether you need to convert units of measurement, clean raw data, or reformat it, FlowFuse offers a low-code environment where you can drag and drop nodes to handle these tasks without needing to write custom code.

Beyond transforming data formats, FlowFuse also enables data contextualization. As raw data flows in, it can be enriched with important metadata, such as timestamps, equipment IDs, or sensor locations, that add context and make the data more meaningful. This is vital for accurate analysis and informed decision-making.

For instance, imagine temperature readings coming from multiple devices, with some sensors reporting in Celsius, others in Fahrenheit, and others in Kelvin. FlowFuse can automatically standardize all these readings to a single unit (like Celsius) and add contextual information, such as which machine the data came from and its current operating status. This makes the data easy to understand and act upon in your UNS.

#### **3. Message Broker**

In UNS), the Message Broker is the central hub where your data resides until it’s accessed or consumed by other systems. It ensures that data flows smoothly between devices and applications, using a publish-subscribe (pub-sub) model. Systems "subscribe" to topics and receive automatic updates whenever new data is published, keeping everything in sync and up to date.

The Message Broker must support the pub-sub model, which is a core requirement for the UNS. For more information on why this model is essential, please read our article on why UNS needs pub-sub. The pub-sub model decouples producers (publishers) from consumers (subscribers), meaning they don’t need to be directly connected or even aware of each other. This decoupling enhances flexibility and scalability. Additionally, it makes the UNS event-driven, eliminating the need for constant polling. Systems only receive data when it’s relevant, boosting efficiency and responsiveness.

MQTT is the ideal broker that supports the pub-sub model and popular choice for uns. It’s lightweight, efficient, and works well in environments with limited resources.

**How FlowFuse Fits In:**

With FlowFuse, you get a built-in MQTT Broker, which means there's no need to configure and maintain a separate system. This simplifies the connection of all your devices and systems, ensuring smooth data exchange within your UNS.
FlowFuse makes it easy to manage connections, organize topics, and configure security features such as TLS encryption and username/password authentication, all within a single platform. This keeps your setup streamlined and secure.

The MQTT Broker supports hierarchical topic structuring, allowing you to efficiently organize and manage your data flows. In FlowFuse, you have an interface to monitor all your UNS topics in a tree view, as well as a secure interface to manage your MQTT clients.

Node-RED in FlowFuse comes with standard MQTT nodes, making it easy to set up secure connections to your broker. You can quickly configure security features like TLS encryption and username/password authentication or dynamically subscribe to topics

---

FlowFuse makes building and managing a Unified Namespace (UNS) easy. It connects devices, transforms data into a usable format, and ensures smooth communication using an MQTT broker. Powered by Node-RED, it works with old and new systems, helping you scale and adapt quickly.

## **What Makes FlowFuse Stand Out in Industrial IoT?**

FlowFuse isn’t just another tool, it's a complete solution for building and managing a &#x2A;*Unified Namespace (UNS)**. While other platforms may specialize in certain areas, FlowFuse brings everything together: connectivity, data transformation, and message brokering, all in one platform.

Many tools excel in one area but fall short in others. Some may connect devices well but struggle with legacy systems or data transformation. FlowFuse solves these challenges by offering an all-in-one solution that works seamlessly with both modern and legacy systems.

As an open-source platform, FlowFuse removes the worry of vendor lock-in. You have the flexibility to transition to other services if your needs evolve, without worrying about compatibility issues.

FlowFuse also includes powerful features tailored for industrial environments. One standout is [real-time collaboration](https://flowfuse.com/blog/2024/12/flowfuse-team-collaboration/), which allows multiple engineers to work on **Node-RED flows** simultaneously, speeding up development and deployment. Additionally, you can [remotely manage edge devices](https://flowfuse.com/blog/2024/07/building-on-flowfuse-devices/), reducing the need for costly on-site visits for troubleshooting or updates.

When it comes to scaling, FlowFuse is built to grow with you. It supports horizontal scaling to balance workloads across multiple instances and vertical scaling to add more resources as your needs increase. Whether you’re scaling up or dealing with high workloads, FlowFuse ensures your infrastructure remains stable and efficient.

Security is a major priority with FlowFuse. It includes features like [role-based access control](https://flowfuse.com/blog/2024/04/role-based-access-control-rbac-for-node-red-with-flowfuse/), encryption, multi-factory authentication, and detailed [audit logs](https://flowfuse.com/docs/user/logs/#audit-log) to keep your data secure and meet industry standards.

On top of that, FlowFuse provides features like [DevOps pipeline management](https://flowfuse.com/blog/2024/10/how-to-build-automate-devops-pipelines-node-red-deployments/), [snapshots for disaster recovery](https://flowfuse.com/blog/2024/09/node-red-version-control-with-snapshots/), and much more, ensuring your systems are always running smoothly and reliably.

## **Summary**

FlowFuse is a complete platform for building and managing a Unified Namespace. It combines everything you need, connectivity, data transformation, and message brokering, into one easy-to-use solution. Open-source flexibility makes it simple to connect devices, scale your system, and keep data secure.


# FlowFuse 2.14: Announcing Third-Party Broker Integration, UNS Schemas, Enhanced Auth on Remote Instances and more!

This release is full of highlights, which we’ll break down into two key areas - the **FlowFuse MQTT Experience** and **Remote Instances** - so you can better digest all of the great new functionality introduced in FlowFuse 2.14.

:product-update-note

## MQTT Experience in FlowFuse

In [October we announced the FlowFuse MQTT Broker](https://flowfuse.com/blog/2024/10/announcement-mqtt-broker/), included in our Starter, Team, and Enterprise tiers. It lets you setup your own secure clients to begin publishing and subscribing to your own topics, and building out your full event-driven applications.

We see the MQTT experience and Node-RED experience regularly paired together, and so it's one of our missions at FlowFuse to provide the best developer experience for building out your event-driven applications when these two elements are in play.

### Third Party Broker Integration

Whilst the Team Broker is a great addition, we are aware that many of our customers already have their own existing MQTT brokers and infrastructure, so what does FlowFuse bring to the table for them?

With this new release, it is now possible for you to connect your external brokers to FlowFuse. With that, you'll get access to the same great features to help you gain a clear understanding of the activity on your broker, and the structure of the data and topics that are being used.

### Schema Generation

A pain point we've seen for many customers is collaboration around a single UNS, or MQTT Broker. There is limited (if any) documentation, and to create that, especially at industrial scale, would be a monstrous and time-consuming task. With that in mind, FlowFuse now offers **automated schema generation**.

FlowFuse now generates a schema for your MQTT Broker's topic hierarchy, whether you're using the in-built FlowFuse Team Broker, or integrating your own, without you needing to do anything. The schema is generated using the industry-standard, open-sourced, [AsyncAPI](https://www.asyncapi.com/){rel="&#x22;nofollow&#x22;"}, and is clearly presented to you in the FlowFuse UI in two formats.

#### Topic Hierarchy Editor

The first view lives within the FlowFuse UI that you're familiar with, will display your interactive topic hierarchy which you can explore, and is predominantly the "edit" and "review" view of your hierarchy.

![Screenshot of the Topic Hierarchy view for a given Broker in FlowFuse](https://flowfuse.com/blog/2025/02/images/screenshot-topic-hierarchy.png){dataZoomable=""}*Screenshot of the Topic Hierarchy view for a given Broker in FlowFuse*

For each topic, you can define descriptions so that team members and anyone interacting with your broker can get a clear understanding of how to get the most out of the hierarchy and associated data.

We have also hopped the first piece of our Smart Suggestions, which is an agent that runs and works out the structure of the payloads to each of your topics. Right now, this is shown in the UI under "Detected Schema", but we have bigger plans here, that hopefully you'll be seeing more of in the very near future.

#### Personalized UNS Documentation

The second view is focussed on clarity, and collaboration.

![Screenshot of the new "Schema Documentation" view provided for brokers on FlowFuse](https://flowfuse.com/blog/2025/02/images/screenshot-topic-docs.png){dataZoomable=""}*Screenshot of the new "Schema Documentation" view provided for brokers on FlowFuse*

A big challenge with the Unified Namespace, and wider MQTT too, can be the lack of centralized structure and information around the topics and payloads that are being used. This can make it difficult to understand what is being published and subscribed to, and can make it hard to onboard new projects, team members or partners.

That is why we have built in a new "Schema Documentation" view, available for both the in-built FlowFuse Broker, and any third-party broker that you choose to connect.

This view is built from the automated topic hierarchy, manually added topic descriptions and will soon feature payload schema information from our upcoming Smart Schemas.

## Remote Instances

This release sees two new major features coming to Remote Instances (previously known as "Devices").

### FlowFuse Authentication now Supported

You can now secure your Remote Instances with FlowFuse Authentication.

This means that you can now use the same credentials you use to log into FlowFuse, to authenticate any HTTP endpoints, such as the [FlowFuse Dashboard](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"}, on your Remote Instances. This also unlocks features like [Multi-Tenant Dashboards](https://dashboard.flowfuse.com/user/multi-tenancy.html){rel="&#x22;nofollow&#x22;"} that can run on your own hardware at the Edge.

Please note that this does require that your hardware has a connection to FlowFuse.

### Version History for Remote Instances

![Screenshot of the new "Version History" timeline view available for Remote Instances](https://flowfuse.com/blog/2025/02/images/screenshot-timeline.png){dataZoomable=""}*Screenshot of the new "Version History" timeline view available for Remote Instances*

This release brings another great update for Remote Instances: the "Timeline" view has been rolled out to provide you a clear picture of everything that has been running on your Remote Instance.

Here you will be able to see every time flows were deployed (for example from within [Developer Mode](https://flowfuse.com/docs/device-agent/quickstart/#developer-mode)), when settings have updated, [Snapshots](https://flowfuse.com/docs/user/snapshots/) have been created, or new flows have been deployed via a [DevOps Pipeline](https://flowfuse.com/docs/user/devops-pipelines/).

## What Else Is New?

For a full list of everything that went into our 2.13 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.14.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try FlowFuse

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.


# Interacting with Arduino using Node-RED

Arduino is a popular open-source platform that lets you build cool electronics projects. It’s affordable and flexible, with lots of different boards and sensors to choose from. However, unlike some other boards, Arduino doesn’t have built-in internet connectivity, which can make remote control a bit tricky. Plus, it usually requires some coding to make things work.

:product-update-note

In this guide, I’ll show you how to control and automate your Arduino remotely using Node-RED and FlowFuse, all without writing any code. We’ll use the Firmata protocol to make it easy to send commands and get data from your Arduino. By the end of this tutorial, you’ll have a simple automation setup that you can control from anywhere. Just keep in mind, the Arduino will need to be connected to the device running Node-RED!

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: FTuxOy16nwo
---
::

## Prerequisites

To follow this tutorial, you'll need the following:

- Arduino Board: The hardware you'll be using for this project.
- USB cable: To connect the Arduino to your computer.
- Arduino IDE: Installed and set up to program your Arduino. Download the Arduino IDE if you haven't already done so. we will be using this for initial firmata implementation, not for programming
- FlowFuse Account: You will need a FlowFuse instance running on the device connected to the Arduino. FlowFuse allows you to access that remote instance, build flows, create remotely available dashboards, collaborate with your team on the instance, provide robust security, and much more.

## Getting Started with Arduino and Node-RED

In this section, we’ll set up Node-RED on FlowFuse and download the Firmata protocol setup on the Arduino using Arduino IDE. We will also create a flow that will control an LED on the Arduino and read input data. We will later control the LED based on object detection using an object sensor to make it more interesting. If you don’t have the sensor, don't worry, you can still follow the article. The goal of this example is to demonstrate both reading and writing operations, as well as build an automation flow that reacts to input.

### Step 1: Running Node-RED on the Device connected to Arduino

To begin, you need to run Node-RED on the device connected to your Arduino, whether it is a Raspberry Pi, Windows, or Linux system. However, simply running Node-RED locally is not sufficient if you require remote access. Setting up a server, securing it, and ensuring accessibility can be time-consuming and complex.

Using the FlowFuse device agent simplifies this process. It allows you to remotely access and manage your Node-RED instance without the need for extensive configuration or security management. This approach ensures a more efficient and secure deployment, enabling you to focus on building automation solutions.

For a step-by-step guide on installing and running the FlowFuse device agent, refer to the official documentation: [FlowFuse Device Agent Quickstart](https://flowfuse.com/docs/device-agent/quickstart/). By the way, we also offer a [free tier](https://flowfuse.com/blog/2024/12/flowfuse-release-2-12/) that lets you manage up to two edge devices for free. [Sign up today](https://app.flowfuse.com/account/create?utm_campaign=60718323-BCTA&utm_source=blog&utm_medium=cta&utm_term=high_intent&utm_content=Interacting%20with%20Arduino%20using%20Node-RED){rel="&#x22;nofollow&#x22;"}!

### Step 2: Downloading Firmata protocol setup to Arduino.

[Firmata](https://github.com/firmata/protocol){rel="&#x22;nofollow&#x22;"} is a protocol for communicating between an Arduino (and other microcontrollers) and the host computer, providing direct access to the IO pins.

Now, let's download the setup to the Arduino. Before proceeding, ensure your Arduino is connected to your laptop or computer via the correct USB cable. The USB connection is essential for uploading the code (sketch) to the Arduino and will also be used by Firmata for communication later.

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

**Setting up Arduino IDE and Download the setup from examples:**

1. Open the Arduino IDE on your computer.
2. Ensure you have selected the correct board and port in the Tools menu. Since I am using an Arduino Uno 3 board, I’ve selected the Arduino Uno board.
3. Go to File → Examples → Firmata, and then click on StandardFirmata. This will open the Firmata setup code.
4. Click the Upload button in the Arduino IDE to upload the setup to your Arduino board.

![Importing Standard Firmata setup sketch from examples in Arduino IDE](https://flowfuse.com/blog/2025/02/images/firmata-import.png){dataZoomable=""}*Importing Standard Firmata setup sketch from examples in Arduino IDE*

Once the upload is complete, the Arduino is ready to communicate via the Firmata protocol.

### Step 3: Connecting Node-RED to Arduino via Serial Communication

As mentioned earlier, Firmata typically works over a serial connection (such as USB), enabling communication between the Arduino board and your Node-RED instance. The serial communication allows Node-RED to send commands to the Arduino and receive data from it.

First, we will need to install a node that will enable communication between Node-RED and the Arduino via Firmata.

**Installing Arduino Node**

1. Open the main menu by clicking the three horizontal lines in the top-right corner.
2. Click "Manage Palette" from the menu.
3. Switch to the "Install" tab and type "node-red-node-arduino" in the search field.
4. Click "Install" next to the node name.

After installing the required node for Arduino, we will set up the flow in Node-RED to establish a connection with the Arduino.

**Establishing Connection with Arduino**

1. Drag any Arduino node onto the canvas
2. Double-click the node to open its configuration window.
3. In the new window that opens, enter the port name for your Arduino (for example, COM5 on Windows or /dev/ttyUSB0 on Linux/macOS). You can find the correct port in the Arduino IDE or your system’s device manager.

![Adding the port to the Arduino node](https://flowfuse.com/blog/2025/02/images/serial-port-config.png){dataZoomable=""}*Adding the port to the Arduino node*

4. Click and deploy by clicking the top-right deploy button.

Once deployed, after a few seconds, the node will establish a connection with the Arduino board. You should see a green square below the node, indicating that the connection is successful and the status is "Connected."

### Step 4: Sending Commands to Arduino

In this section, I'll show you how to send commands to your Arduino. For this practical demonstration, we will control the default Arduino LED, which is typically connected to pin 13.

1. Drag the Arduino-out node onto the canvas.
2. Double-click the node to open its configuration window.
3. Select the correct configuration (serial port) that you set up in Step 3.
4. Next, choose the type of pin you want to interact with (e.g., digital, analog, servo, etc.). Since in this example we will be interacting with an LED, which only requires on or off commands, I’ve selected Digital (0/1).

Based on the type of data you want to send, select the appropriate pin type:

- Digital (0/1) – accepts 0, 1
- Analog (0-255) (PWM) – accepts Integer values from 0 to 255
- Servo (0-180) – accepts Integer values from 0 to 180
- String – to send a string to the Arduino

5. Once you've configured the pin type, enter the pin number (e.g., 13 for the built-in LED).
6. Click Done.

![Configuring Arduino-out node](https://flowfuse.com/blog/2025/02/images/control-led.png){dataZoomable=""}:br*Configuring Arduino-out node*

7. Drag two Inject nodes onto the canvas. For one Inject node, set the payload to true (to turn the LED on), and for the other, set the payload to false (to turn the LED off).
8. Connect the output of each Inject node to the input of the Arduino-out node.
9. Deploy the flow.

Now, you can turn the LED on and off by clicking the inject buttons. Instead of using the inject node, you can also use the FlowFuse dashboard to build an interactive dashboard. The dashboard will allow you to control the LED directly from a web interface.

Below is the flow that allows you to control the LED connected to pin 13.

::render-flow
```json
[{"id":"fbe0eb6547cbfed7","type":"arduino out","z":"FFF0000000000001","name":"","pin":"13","state":"OUTPUT","arduino":"d7663aaf.47194","x":739.8345947265625,"y":645.8272094726562,"wires":[]},{"id":"e222d2df8c62483d","type":"inject","z":"FFF0000000000001","name":"Turn LED on","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"true","payloadType":"bool","x":530,"y":580,"wires":[["fbe0eb6547cbfed7"]]},{"id":"c82bd0280ee45b3b","type":"inject","z":"FFF0000000000001","name":"Turn LED off","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"false","payloadType":"bool","x":530,"y":680,"wires":[["fbe0eb6547cbfed7"]]},{"id":"d7663aaf.47194","type":"arduino-board","device":"COM5"}]
```
::

If you're interested in learning how to create a dashboard, you can refer to the [Getting Started Guide](https://flowfuse.com/blog/2024/03/dashboard-getting-started/). It will help clarify basic dashboard concepts and guide you through building a simple dashboard interface.

### Step 5: Receiving Inputs from the Arduino

In this step, we’ll focus on receiving inputs from the Arduino to Node-RED. For this practical demonstration, we will use the input from the IR object detection sensor connected to the Arduino.

1. Drag the Arduino-in node onto the canvas.
2. Double-click the node to open its configuration window.
3. Select the serial port to which your Arduino is connected.
4. Based on the input type, choose the correct pin type (e.g., digital, analog). Since we are using an IR sensor, which typically provides a digital output, select the "Digital pin" type.
5. Enter the pin number (e.g., pin 9, if your sensor is connected to pin 9 on the Arduino).

![Configuring Arduino-in node](https://flowfuse.com/blog/2025/02/images/read-sensor-data.png){dataZoomable=""}:br*Configuring Arduino-in node*

*Note: You cannot use the same pin for both output and input on the Arduino simultaneously. Ensure the pin you use for input (like the IR sensor) is separate from the pin you're using for output (like the LED).*

6. Click Done.
7. Drag the Debug node onto the canvas and connect its input to the output of the Arduino-in node.
8. Deploy the flow.

Now, the Arduino will send the sensor input data to Node-RED. If a change is detected in the input, the Arduino will output that input, and you will see it in the debug panel.

Below, I have provided the flow that reads the IR object detection sensor data connected to pin 9, in case you need it.

::render-flow
```json
[{"id":"2b871fb5d0923355","type":"arduino in","z":"FFF0000000000001","name":"Read Sensor Data","pin":"9","state":"INPUT","arduino":"d7663aaf.47194","x":170,"y":360,"wires":[["e3e52e51a2e4e058"]]},{"id":"e3e52e51a2e4e058","type":"debug","z":"FFF0000000000001","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":360,"y":360,"wires":[]},{"id":"d7663aaf.47194","type":"arduino-board","device":"COM5"}]
```
::

### Step 6: Creating an Automation Flow

Now that you've learned how to send commands and read inputs from the Arduino, let’s move on to creating an automation flow. This section aims to show you how to program the Arduino without writing a single line of code, using only Node-RED.

The idea is to trigger an action, such as turning on an LED, when the sensor detects an object.

1. Drag a Switch node onto the canvas.
2. Double-click on the Switch node to open its configuration window and add the following conditions:

- msg.payload == 1
- msg.payload == 0

3. Click Done to save the configuration.

![Adding conditions in the Switch node to check if the object is detected or not.](https://flowfuse.com/blog/2025/02/images/switch.png){dataZoomable=""}&#x2A;Adding conditions in the Switch node to check if the object is detected or not.*

4. Connect the Switch node's input to the Arduino-in node's output.
5. Next, drag two Change nodes onto the canvas. Set the payload to false for the first Change node and true for the second Change node.
6. Connect the first output of the Switch node to the input of the first Change node, and the second output of the Switch node to the input of the second Change node.

Since IR object detection sensors output a LOW (0) signal when an object is detected and a HIGH (1) signal when no object is detected, this flow will turn the LED on when an object is detected (when msg.payload is equal to 0) and turn the LED off object is not detected (when msg.payload is equal to 1).

Below, I have provided the complete flow of how we read the IR object detection sensor data and control the LED in response to the input. I have also included a video demo.

::render-flow
```json
[{"id":"2b871fb5d0923355","type":"arduino in","z":"FFF0000000000001","name":"Read Sensor Data","pin":"9","state":"INPUT","arduino":"d7663aaf.47194","x":130,"y":460,"wires":[["8ad3d1504ba05942"]]},{"id":"49b04d8b6f015846","type":"change","z":"FFF0000000000001","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":530,"y":480,"wires":[["d6e251e983f908ac"]]},{"id":"8f56a3d6ac64e87c","type":"change","z":"FFF0000000000001","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"false","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":530,"y":440,"wires":[["d6e251e983f908ac"]]},{"id":"8ad3d1504ba05942","type":"switch","z":"FFF0000000000001","name":"","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"1","vt":"num"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":330,"y":460,"wires":[["8f56a3d6ac64e87c"],["49b04d8b6f015846"]]},{"id":"d6e251e983f908ac","type":"arduino out","z":"FFF0000000000001","name":"Control LED","pin":"13","state":"OUTPUT","arduino":"d7663aaf.47194","x":770,"y":460,"wires":[]},{"id":"d7663aaf.47194","type":"arduino-board","device":"COM5"}]
```
::

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: FTuxOy16nwo
---
::

## Conclusion

In this tutorial, you’ve learned how to connect your Arduino to Node-RED and control it using the Firmata protocol. We started by turning an LED on and off, reading sensor data, and building a flow to automate actions based on input from an IR sensor.

This approach is so powerful that you don’t need to write any code; FlowFuse lets you create automation flows with just a few clicks. You can quickly expand this setup to include more sensors, devices, and dashboards to build your IoT projects.

It’s a simple yet powerful way to interact with your Arduino, with endless possibilities. Enjoy exploring and building!


# Monitoring Device Health and Performance at Scale with FlowFuse

Edge devices are everywhere, and their numbers are skyrocketing, from 2.7 billion in 2020 to a projected 7.8 billion by 2030, according to [various reports](https://transformainsights.com/news/edge-computing-rapid-growth-iot#:~\:text=New%20Transforma%20Insights%20reports%20covering,edge%20capabilities%20in%20IoT%20devices.){rel="&#x22;nofollow&#x22;"}. As these devices become critical for automation and data processing, monitoring their health is essential to ensure reliability and efficiency.

Tracking CPU usage, memory, and system performance helps detect potential issues early, preventing downtime and optimizing operations. In this post, we will explore how to monitor devices using Node-RED and scale this process efficiently with FlowFuse.

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: 43te5aD1RRw
---
::

## What is Device Health Monitoring, and Why is it Important?

Edge devices power IoT and automation, handling communication and data processing. As their numbers grow, ensuring they run efficiently is crucial.

Monitoring device health means tracking key metrics like CPU usage, memory, uptime, and system load. High CPU usage or low memory can slow down processes, disrupt data flow, and reduce efficiency.

For example, in manufacturing, edge devices connect machines to cloud systems for real-time data. If a device fails, production can be impacted.

Regular monitoring helps detect issues early, prevents downtime, and keeps devices running smoothly.

## Getting Started with Monitoring Devices

We will begin by monitoring a single device, such as a Raspberry Pi, collecting system data, and visualizing it using FlowFuse. Once the process is clear, we will expand it to monitor multiple devices at scale.

### Prerequisites

Before you begin, ensure you have the following:

1. **Running Node-RED Instance:** You need a running Node-RED instance on the device you want to monitor. The easiest way to set this up is with the [FlowFuse Device Agent](https://flowfuse.com/platform/device-agent/), which provides secure remote access, real-time collaboration, snapshots for quick recovery, DevOps tools, and device group management. With it, you can push updates to multiple devices with a single click.

For a step-by-step installation guide, refer to the [FlowFuse Device Agent Quickstart](https://flowfuse.com/docs/device-agent/quickstart/).

If you haven’t yet signed up for a FlowFuse account, [sign up now](https://app.flowfuse.com/account/create?utm_campaign=60718323-BCTA&utm_source=blog&utm_medium=cta&utm_term=high_intent&utm_content=Monitoring%20Device%20Health%20and%20Performance%20at%20Scale%20with%20FlowFuse){rel="&#x22;nofollow&#x22;"}.

1. **Required Node-RED Nodes:** To collect system data and display it on a dashboard, install the following Node-RED nodes via the [Node-RED Palette Manager](https://nodered.org/docs/user-guide/editor/palette/manager){rel="&#x22;nofollow&#x22;"}:

- `node-red-contrib-os`: Retrieves system information such as memory, uptime, and load.
- `node-red-contrib-cpu`: Monitors CPU usage.
- `@flowfuse/node-red-dashboard`: Provides UI components for visualizing system metrics.
- `node-red-contrib-moment`: Formats uptime duration in a human-readable format.

### Collecting CPU and System Metrics with Node-RED

Now that Node-RED is running on your device, it’s time to gather essential system metrics. Monitoring CPU usage, memory consumption, system uptime, and load averages helps you monitormonitor performance and spot potential issues before they become serious problems.

Let’s break it down step by step.

#### Collecting CPU Usage Data

To start, let’s capture CPU usage in real time:

1. Drag a **CPU** node from the "Performance" category onto the canvas.
2. Double-click the node and uncheck all options except "Send a message for overall usage." This ensures you get a clear view of total CPU performance. If you need per-core metrics, you can enable the other options.
3. Add an **Inject** node, double-click it, and set it to trigger at a suitable interval (e.g., every second, every 10 seconds, or every 30 seconds). Connect its output to the CPU node.
4. Add a **Debug** node and connect it to the output of the CPU node. This lets you view CPU data in the debug pane.
5. **Click Deploy** in the top-right corner of the Node-RED editor.

Your debug pane will now start showing live CPU usage data:

![An image showing the flow that gathers CPU usage data and prints it in the debug pane](https://flowfuse.com/blog/2025/02/images/cpu-usage.png){dataZoomable=""}*An image showing the flow that gathers CPU usage data and prints it in the debug pane*

#### Monitoring Memory Usage

Next, let’s track memory consumption:

1. Drag a Memory node onto the canvas and double-click it.
2. Choose the unit for memory display (e.g., gigabytes for easier readability).
3. Connect the Memory node’s input to the Inject node’s output.
4. Connect the Memory node’s output to the existing Debug node.
5. Click Deploy to start monitoring.

Once deployed, you will see a structured object in the debug pane containing along with cpu usage:

![An image showing the flow that gathers memory usage data and prints it in the debug pane](https://flowfuse.com/blog/2025/02/images/memory-usage.png){dataZoomable=""}*An image showing the flow that gathers memory usage data and prints it in the debug pane*

- totalmem: Total available memory
- freemem: Free memory
- memusage: Current memory usage

#### Tracking System Uptime

Monitoring uptime helps detect unexpected reboots and ensures system stability.

1. Drag an Uptime node onto the canvas.
2. Connect its input to the Inject node’s output.
3. Connect its output to the Debug node.
4. Click Deploy to activate uptime tracking.

Each time the Inject node triggers, the debug pane will display the uptime in seconds and CPU and memory usage.

![An image showing the flow that gathers system uptime data and prints it in the debug pane](https://flowfuse.com/blog/2025/02/images/uptime.png){dataZoomable=""}*An image showing the flow that gathers system uptime data and prints it in the debug pane*

#### Analyzing Load Average

To understand how busy your system has been over time, let’s analyze the load average:

1. Drag a **Loadavg** node onto the canvas.
2. Connect its input to the Inject node’s output.
3. Connect its output to the Debug node.
4. Click Deploy to start tracking.

This will give you three key metrics:

![An image showing the flow that gathers system load average data and prints it in the debug pane](https://flowfuse.com/blog/2025/02/images/load-avg.png){dataZoomable=""}

- 1-minute load average: Immediate system load
- 5-minute load average: Recent short-term trend
- 15-minute load average: Long-term system trend

If these values remain consistently high, your system may struggle under excessive demand, signaling a need for optimization or additional processing power.

With these metrics in place, you have a solid foundation for real-time system monitoring.

### Sharing Data Across Different Node-RED Instances

Once we have the data, we must send it to the Node-RED instance handling visualization. Keeping the dashboard separate is essential for scalability. As the number of devices increases, a dedicated instance ensures we can monitor all of them from a single, centralized dashboard. This approach also makes management more efficient.

To send data between multiple Node-RED instances we can use [FlowFuse's Project Nodes](https://flowfuse.com/blog/2024/10/exploring-flowfuse-project-nodes/).

Before sending the data though, we combine all collected metrics into a single object for better organization and easier processing. Currently, each node sends its metrics as a separate message object. Merging them into a single object streamlines data handling and reduces message overhead.

Import the following flow and deploy it in the device instance. While I am not covering the step-by-step process here, the explanation below covers what the flow includes and how it works.

::render-flow
```json
[{"id":"6f655630d97bac87","type":"cpu","z":"FFF0000000000001","name":"","msgCore":false,"msgOverall":true,"msgArray":false,"msgTemp":false,"x":870,"y":460,"wires":[["d47b2da8024123bf"]]},{"id":"733dc91d94f03e49","type":"inject","z":"FFF0000000000001","name":"","props":[],"repeat":"10","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":630,"y":520,"wires":[["6f655630d97bac87","bcddc3aba82a12da","7af11ed245ddf9c3","d6d58c81cea93671"]]},{"id":"bcddc3aba82a12da","type":"Memory","z":"FFF0000000000001","name":"","scale":"Gigabyte","x":860,"y":500,"wires":[["03ee32ddbd80d7a2"]]},{"id":"7af11ed245ddf9c3","type":"Uptime","z":"FFF0000000000001","name":"","x":860,"y":540,"wires":[["6117e013be2a11ac"]]},{"id":"d6d58c81cea93671","type":"Loadavg","z":"FFF0000000000001","name":"","x":860,"y":580,"wires":[["b759167c1663eb21"]]},{"id":"d47b2da8024123bf","type":"change","z":"FFF0000000000001","name":"CPU USAGE","rules":[{"t":"set","p":"data","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"data.CPU_USAGE","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1070,"y":460,"wires":[["7429fa970d1e3099"]]},{"id":"03ee32ddbd80d7a2","type":"change","z":"FFF0000000000001","name":"MEMORY USAGE","rules":[{"t":"set","p":"data","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"data.MEMORY_USAGE","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1090,"y":500,"wires":[["7429fa970d1e3099"]]},{"id":"6117e013be2a11ac","type":"change","z":"FFF0000000000001","name":"SYSTEM UPTIME","rules":[{"t":"set","p":"data","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"data.UPTIME","pt":"msg","to":"$floor(payload.uptime)\t","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":1090,"y":540,"wires":[["7429fa970d1e3099"]]},{"id":"b759167c1663eb21","type":"change","z":"FFF0000000000001","name":"LOAD AVERAGE","rules":[{"t":"set","p":"data","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"data.LOAD_AVERAGE.ONE_MIN","pt":"msg","to":"payload.loadavg[0]","tot":"msg"},{"t":"set","p":"data.LOAD_AVERAGE.FIVE_MIN","pt":"msg","to":"payload.loadavg[1]","tot":"msg"},{"t":"set","p":"data.LOAD_AVERAGE.FIFTEEN_MIN","pt":"msg","to":"payload.loadavg[2]","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1090,"y":580,"wires":[["7429fa970d1e3099"]]},{"id":"7429fa970d1e3099","type":"join","z":"FFF0000000000001","name":"","mode":"custom","build":"merged","property":"data","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","useparts":false,"accumulate":true,"timeout":"","count":"4","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":1310,"y":520,"wires":[["133d57048a7b057d"]]},{"id":"133d57048a7b057d","type":"change","z":"FFF0000000000001","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"data","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1490,"y":520,"wires":[["8123ad61cf50e61e"]]},{"id":"8123ad61cf50e61e","type":"project link out","z":"FFF0000000000001","name":"project out 1","mode":"link","broadcast":true,"project":"28a809c6-b8f3-499f-bb20-e357c292b443","topic":"${FF_DEVICE_NAME}","x":1670,"y":520,"wires":[]}]
```
::

Let's understand the flow.

In the flow above, four Change nodes are used, each connected to the output of the **CPU**, **Memory**, **Uptime**, and **Loadavg** nodes. As mentioned earlier, these nodes provide their data separately as `msg.payload`. We use Change nodes to modify the message structure before sending the data to ensure a more structured and organized format.

Next, a Join node merges the `msg.data` objects from all Change nodes into a single data object. After that, another Change node assigns this combined object to `msg.payload`.

The final combined object appears as shown in the image below:

![Combined object containing system data such as CPU usage, memory usage, uptime, and load average.](https://flowfuse.com/blog/2025/02/images/combine-object.png){dataZoomable=""}&#x2A;Combined object containing system data such as CPU usage, memory usage, uptime, and load average.*

To share this data with other Node-RED instances, we use the **Project Out** node, which is available exclusively on FlowFuse. It works similarly to the Node-RED Link nodes, but allows for communication between multiple Instances, and uses MQTT in the background, so also beenfits with topic hierarchies for any communications.

In this Project node, we broadcast the message across all instances in the team using `${FF_DEVICE_NAME}` as the topic, an environment variable automatically created in all FlowFuse instances.

![Image showing the environment variables of Raspberry Pi devices with their values.](https://flowfuse.com/blog/2025/02/images/env.png){dataZoomable=""}&#x2A;Image showing the environment variables of Raspberry Pi devices with their values.*

Using environment variables as the topic enables the same flow to be used across multiple devices without modification, ensuring that each device utilizes its own environment variables (device name) and sends data under its respective topic.

### Visualizing Data with the FlowFuse Dashboard

Now that the data is being broadcasted, it can be used to build a simple dashboard that visualizes it with different types of charts.

![Dashboard monitoring device CPU usage, memory uptime, and load average](https://flowfuse.com/blog/2025/02/images/dashboard-monitoring-device.png){dataZoomable=""}*Dashboard monitoring device CPU usage, memory uptime, and load average*

Ensure that a separate **Hosted Instance** has been created in the same Team where the hardware is registered. This instance will be used to deploy the dashboard.

#### Setting Up the Data Source

1. Drag the **Project In** node onto the canvas.
2. Double-click on it and select "Listen for broadcast messages from".
3. Choose "All instances and devices" from the "Source" dropdown menu.
4. Enter the device name in the topic field, ensuring it matches exactly with the `${FF_DEVICE_NAME}` device environment variable.
5. Click **Done**.

#### Memory Usage Visualization

1. Drag two **Change** nodes onto the canvas.
2. Double-click on the first **Change** node. Set `msg.payload`to:
   ```json
   payload.MEMORY_USAGE.totalmem - payload.MEMORY_USAGE.freemem
   ```
3. Set `msg.topic` to "USED MEMORY" and click **Done**.
4. Double-click on the second **Change** node, Set `msg.payload`to:
   ```json
   msg.payload.MEMORY_USAGE.freemem
   ```
5. Set `msg.topic` to "Free Memory" and click **Done**.
6. Drag a **ui-chart** widget onto the canvas.
7. Double-click on the widget and create a new Group.
8. Set the chart type to "Pie" and action to "Append".
9. Set X to `msg.topic` and leave Y empty.
10. Click **Done**.
11. Connect the nodes as follows:

Project In node → Change nodes → ui-chart widget

#### CPU Usage Visualization

1. Drag a Change node onto the canvas.
2. Double-click on the node. Set `msg.payload`to:
   ```json
   $round(payload.CPU_USAGE, 2)
   ```
3. Click Done.
4. Drag a ui-gauge widget onto the canvas.
5. Double-click on the widget and create a new group.
6. Set the height and size.
7. Select "3/4 gauge" with a rounded style.
8. Set the range from 0 to 100.
9. Add three segments with colors: 0 (Green), 50 (Yellow), 80 (Red).
10. Set the label to "CPU" and unit to %.
11. Click Done.
12. Connect the nodes as follows:

Project In node → Change node → ui-gauge widget

#### System Uptime Visualization

1. Drag the Humanizer node onto the canvas.
2. Double-click on the node and enter "UPTIME" in the input variable field.
3. Click Done.
4. Drag a Change node onto the canvas.
5. Double-click on the node. Set `msg.payload`to:
   ```json
   msg.payload.humanized
   ```
6. Click Done.
7. Drag a ui-text widget onto the canvas.
8. Double-click on it and create a new group.
9. Select the correct layout.
10. Check the "Apply Styles" option and select the color, font, and size that best suits your needs.
11. Click Done.
12. Connect the nodes as follows:

Project In node → Humanizer node → Change node → ui-text widget

Below is the complete dashboard flow, which visualizes the system data we collected.

::render-flow
```json
[{"id":"018657fd6a7e4237","type":"project link in","z":"797e084100cec864","name":"project in 1","project":"all","broadcast":true,"topic":"MacOS","x":80,"y":260,"wires":[["1335f4283b6bac10","acd675febbdadc6f","f875ddcc0de1c40f","95e3d356bd589be7","7cde186dd1601efb","6448cab78573bf39","d0e232ec780650fa"]]},{"id":"1335f4283b6bac10","type":"change","z":"797e084100cec864","name":"Free Memory","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.MEMORY_USAGE.freemem","tot":"msg"},{"t":"set","p":"topic","pt":"msg","to":"Free Memory","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":270,"y":160,"wires":[["eed0837fccf2639d"]]},{"id":"eed0837fccf2639d","type":"ui-chart","z":"797e084100cec864","group":"a54eed4c7110dfb5","name":"Memory Usage","label":"X - msg.topic, Series - msg.series","order":1,"chartType":"pie","category":"Pie","categoryType":"str","xAxisLabel":"","xAxisProperty":"topic","xAxisPropertyType":"msg","xAxisType":"radial","xAxisFormat":"","xAxisFormatType":"auto","xmin":"","xmax":"","yAxisLabel":"","yAxisProperty":"","yAxisPropertyType":"property","ymin":"","ymax":"","bins":"","action":"append","stackSeries":false,"pointShape":"circle","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"3600","removeOlderPoints":"","colors":["#0095ff","#ff0000","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"textColor":["#666666"],"textColorDefault":true,"gridColor":["#e5e5e5"],"gridColorDefault":true,"width":"3","height":"3","className":"","interpolation":"linear","x":520,"y":140,"wires":[[]]},{"id":"acd675febbdadc6f","type":"change","z":"797e084100cec864","name":"Used Memory","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.MEMORY_USAGE.totalmem - payload.MEMORY_USAGE.freemem","tot":"jsonata"},{"t":"set","p":"topic","pt":"msg","to":"Used Memory","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":280,"y":120,"wires":[["eed0837fccf2639d"]]},{"id":"f875ddcc0de1c40f","type":"change","z":"797e084100cec864","name":"CPU Overall Usage","rules":[{"t":"set","p":"payload","pt":"msg","to":"$round(payload.CPU_USAGE, 2)","tot":"jsonata"},{"t":"set","p":"topic","pt":"msg","to":"CPU Overall Usage","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":290,"y":260,"wires":[["a777eb57611ddd60"]]},{"id":"a777eb57611ddd60","type":"ui-gauge","z":"797e084100cec864","name":"","group":"0d1f7e47031c74c1","order":1,"width":"4","height":"5","gtype":"gauge-34","gstyle":"rounded","title":"CPU ","units":"units","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#5cd65c"},{"from":"4","color":"#ffc800"},{"from":"7","color":"#ea5353"}],"min":0,"max":10,"sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":490,"y":260,"wires":[]},{"id":"95e3d356bd589be7","type":"humanizer","z":"797e084100cec864","name":"","input":"UPTIME","x":290,"y":340,"wires":[["9d237ff676ad6083"]]},{"id":"79e5bdfa309d27ea","type":"ui-text","z":"797e084100cec864","group":"3827fa7650fa2fa1","order":1,"width":"4","height":"5","name":"Uptime","label":"","format":"{{msg.payload}}","layout":"col-center","style":true,"font":"","fontSize":"99","color":"#0056d6","wrapText":false,"className":"","x":680,"y":340,"wires":[]},{"id":"9d237ff676ad6083","type":"change","z":"797e084100cec864","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.humanized","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":480,"y":340,"wires":[["79e5bdfa309d27ea"]]},{"id":"7cde186dd1601efb","type":"change","z":"797e084100cec864","name":"One Minute (LOAD_AVERAGE)","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.LOAD_AVERAGE.ONE_MIN","tot":"jsonata"},{"t":"set","p":"topic","pt":"msg","to":"One Minute","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":330,"y":400,"wires":[["b5bf2c8c93abb5a9"]]},{"id":"6448cab78573bf39","type":"change","z":"797e084100cec864","name":"Five Minute (LOAD_AVERAGE)","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.LOAD_AVERAGE.FIVE_MIN","tot":"jsonata"},{"t":"set","p":"topic","pt":"msg","to":"Five Minute","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":330,"y":440,"wires":[["b5bf2c8c93abb5a9"]]},{"id":"d0e232ec780650fa","type":"change","z":"797e084100cec864","name":"Fifteen Minute (LOAD_AVERAGE)","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.LOAD_AVERAGE.FIFTEEN_MIN","tot":"jsonata"},{"t":"set","p":"topic","pt":"msg","to":"Fifteen Minute","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":340,"y":480,"wires":[["b5bf2c8c93abb5a9"]]},{"id":"b5bf2c8c93abb5a9","type":"ui-chart","z":"797e084100cec864","group":"0c78dcb3aefb38a8","name":"LOAD AVERAGE","label":"chart","order":1,"chartType":"line","category":"topic","categoryType":"msg","xAxisLabel":"","xAxisProperty":"","xAxisPropertyType":"timestamp","xAxisType":"time","xAxisFormat":"","xAxisFormatType":"auto","xmin":"","xmax":"","yAxisLabel":"","yAxisProperty":"payload","yAxisPropertyType":"msg","ymin":"","ymax":"","bins":10,"action":"append","stackSeries":false,"pointShape":"dash","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"3600","removeOlderPoints":"","colors":["#0095ff","#ff0000","#ff7f0e","#2ca02c","#a347e1","#d62728","#ff9896","#9467bd","#c5b0d5"],"textColor":["#666666"],"textColorDefault":true,"gridColor":["#e5e5e5"],"gridColorDefault":true,"width":"12","height":"6","className":"","interpolation":"linear","x":610,"y":440,"wires":[[]]},{"id":"a54eed4c7110dfb5","type":"ui-group","name":"Memory Usage","page":"d0621b8f20aee671","width":"3","height":"3","order":3,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"0d1f7e47031c74c1","type":"ui-group","name":"CPU Usage","page":"d0621b8f20aee671","width":"4","height":"5","order":2,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"3827fa7650fa2fa1","type":"ui-group","name":"SYSTEM UPTIME","page":"d0621b8f20aee671","width":"5","height":"5","order":1,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"0c78dcb3aefb38a8","type":"ui-group","name":"Load Average","page":"d0621b8f20aee671","width":"12","height":1,"order":4,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"d0621b8f20aee671","type":"ui-page","name":"Mac OS","ui":"6c8450c52cafa145","path":"/macos","icon":"home","layout":"grid","theme":"5075a7d8e4947586","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"6c8450c52cafa145","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true},{"id":"5075a7d8e4947586","type":"ui-theme","name":"Default Theme","colors":{"surface":"#ffffff","primary":"#0094CE","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
```
::

### Scaling Device Monitoring with FlowFuse

Now that we have learned how to monitor a single device, built a flow to gather system data, and created a dashboard to visualize those metrics, the real challenge arises when scaling up to thousands or even tens of thousands of devices. Manually creating a system data-gathering flow for each device would be impractical. However, FlowFuse can automate this process in less than five minutes. Let's see how.

#### Creating Device Group

1. Navigate to the FlowFuse platform and go to the Application where your devices are and where you want to create a group. Ensure that all the devices you want to monitor are part of this application.

![Showing the option to switch to "Device Groups" and the "Add Device Group" button.](https://flowfuse.com/blog/2025/02/images/option-add-device-group.png){dataZoomable=""}:br&#x2A;Showing the option to switch to "Device Groups" and the "Add Device Group" button.*

1. Click on "Device Groups" from the top menu. Next, click on the "Add Device Group" button. In the newly opened window, enter a group name and description, then click "Create".

![Form to Create a Device Group: Enter the group name and description ](https://flowfuse.com/blog/2025/02/images/device-group-form-create.png){dataZoomable=""}:br*Form to Create a Device Group: Enter the group name and description*

2. Click on the newly created group and then click the "Edit" button at the top-right.

![Image showing the edit button to be clicked on.](https://flowfuse.com/blog/2025/02/images/edit-device-group.png){dataZoomable=""}:br&#x2A;Image showing the edit button to be clicked on.*

3. Next, in the left-side container, you will see a list of all available devices in your application. Select the devices you want to add to the group (make sure to add only the devices that require the deployment of the flow built to gather system metrics). Click the "Add Devices" button at the top-right of that container, and then click "Save Changes". Once done, you will see all added devices in the right-side container, confirming that they have been successfully added to the group.

![Interface to select the devices that need to be added to the group, along with the 'Add Devices' button.](https://flowfuse.com/blog/2025/02/images/device-group-device-adding.png){dataZoomable=""}:br&#x2A;Interface to select the devices that must be added to the group, along with the 'Add Devices' button.*

![Showing the selected devices we chose to add, along with the 'Save Changes' button.](https://flowfuse.com/blog/2025/02/images/save-changes-to-add-devices.png){dataZoomable=""}:br&#x2A;Showing the selected devices we chose to add, along with the 'Save Changes' button.*

#### Creating Snapshot

1. Navigate to the Remote Instance on which we developed the flow to monitor performance. Switch to "Version History" by clicking on "Version History" from the top.
2. Go to the Snapshots tab and create a new snapshot by clicking the "Create Snapshot" button. Enter details such as the name and description. While making the snapshot, ensure the "Set as Target" option is checked before clicking "Create". Enabling this option sets the created snapshot as the device’s active snapshot. Later, this snapshot will be used for deployment on devices within the device group via the DevOps pipeline.

![Showing the option to switch to "Version history" and the "Create Snapshot" button.](https://flowfuse.com/blog/2025/02/images/create-snapshot.png){dataZoomable=""}:br&#x2A;Showing the option to switch to "Version history" and the "Create Snapshot" button.*

!["Showing the form to create a snapshot and the "Set as Target" option."](https://flowfuse.com/blog/2025/02/images/set-active-snapshot.png){dataZoomable=""}:br&#x2A;Showing the form to create a snapshot and the "Set as Target" option.*

If you want to learn more about snapshots, you can read our article [Using Snapshots for Version Control in Node-RED with FlowFuse](https://flowfuse.com/blog/2024/09/node-red-version-control-with-snapshots/).

#### Creating a DevOps Pipeline

1. Navigate to the application where the devices were added and the device group was created. Switch to the "Pipelines" tab at the top, then click "Add Pipeline". In the newly opened window, enter a pipeline name.

![Image showing the 'Add Pipeline' button.](https://flowfuse.com/blog/2025/02/images/add-pipeline-button.png){dataZoomable=""}:br&#x2A;Image showing the 'Add Pipeline' button.*

![Image showing the form to create a pipeline by entering a name.](https://flowfuse.com/blog/2025/02/images/pipeline-creation-form.png){dataZoomable=""}:br&#x2A;Image showing the form to create a pipeline by entering a name.*

2. In the newly added pipeline, click "Add Stage".

![Image showing the button to add a stage.](https://flowfuse.com/blog/2025/02/images/adding-stage-button.png){dataZoomable=""}:br&#x2A;Image showing the button to add a stage.*

3. In the newly opened window, select "Remote Instance" as the stage type, enter a stage name, and select the device where the flow was previously built for a single device. Under "Action," select "Use active snapshot" and click "Add Stage".

![Image showing the form to add a stage, where a stage is being added for a Raspberry Pi remote instance.](https://flowfuse.com/blog/2025/02/images/rpi-stage.png){dataZoomable=""}:br&#x2A;Image showing the form to add a stage, where a stage is being added for a Raspberry Pi remote instance.*

4. To add another stage, select "Device Group" as the stage type, enter a stage name, choose the previously created device group, and click "Add Stage."

![Image showing the form to add a stage, where a stage is being added for a Device Group.](https://flowfuse.com/blog/2025/02/images/production-with-deviec-group.png){dataZoomable=""}:br&#x2A;Image showing the form to add a stage, where a stage is being added for a Device Group.*

5. Before moving further, ensure all devices are in fleet mode.

![Image showing the fleet mode status of the device (disabling the developer mode option will set the device to fleet mode).](https://flowfuse.com/blog/2025/02/images/fleet-mode.png){dataZoomable=""}:br&#x2A;Image showing the fleet mode status of the device (disabling the developer mode option will set the device to fleet mode).*

6. Once both stages are added, click the 'Run Pipeline' button for the first stage. Running the pipeline will deploy the active snapshot to the devices in the device group, including all settings, environment variables, and flows of that instance. Whether the device group has two devices or thousands, the deployment will be completed efficiently and quickly.

To learn more about DevOps pipelines, read the article: [Creating and Automating DevOps Pipelines for Node-RED in Industrial Environments](https://flowfuse.com/blog/2024/10/how-to-build-automate-devops-pipelines-node-red-deployments/).

Now, you have the system data of all devices broadcasted on the topic and the device name. To monitor each device, go to the dashboard instance, copy the flow, and create copies for each device. Ensure that you replace the topic with the corresponding device name. Additionally, create a separate page for each device, assign them to separate groups, and correctly move all copied widgets into the appropriate groups. Alternatively, follow [these steps](https://flowfuse.com/#visualizing-data-with-the-flowfuse-dashboard) again for each device, and you will have a centralized dashboard monitoring thousands of devices live.

::lite-youtube
---
params: rel=0
style: "width: 704px; height: 100%;"
title: YouTube video player
videoid: 43te5aD1RRw
---
::

## Conclusion

Building a monitoring flow in Node-RED is simple. It allows you to track key system metrics like CPU usage, memory, and uptime with minimal effort. Its low-code Interface makes it easy to create and deploy monitoring solutions quickly.

[One large US manufacturing company relies on this same approach to monitor thousands of Node-RED instances deployed across its factories](https://flowfuse.com/customer-stories/manufacturing-digital-transformation/), maintaining multiple versions of instances across its device fleet.

However, manually deploying this monitoring flow across 10,000 or even 100,000 devices can be a complex and time-consuming task. This is where FlowFuse makes a difference. With features like Device Groups and DevOps pipelines, you can deploy your application from a single device or hosted Node-RED instance to thousands of devices with just a single click. FlowFuse also provides powerful tools for scaling, managing, and monitoring industrial operations, making large-scale deployments more efficient and hassle-free.


# Announcing Node-RED Academy!

The [Node-RED Academy](https://node-red-academy.learnworlds.com/){rel="&#x22;nofollow&#x22;"} provides Node-RED courses both for experts, who want to grow their knowledge, and for beginners, who are just learning the ropes. Get formal certification in Node-RED by completing courses and share certificates on LinkedIn to demonstrate your Node-RED learning accomplishments.

## What is Node-RED Academy?

Node-RED Academy is a brand new learning portal for Node-RED. Whether you're a complete beginner to Node-RED or have been building applications for years, Node-RED Academy courses will take your expertise to the next level, and provide you with formal certification that are evidence of your Node-RED knowledge and skills.

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

## Can I Earn a Credential?

All courses completed through Node-RED Academy provide a formal certification upon successful course completion. You can share this certificate on LinkedIn, add it to your CV or show it off anywhere else you like.

The credential will be evidence of your Node-RED knowledge and abilities, and will be a great way to demonstrate your expertise to potential employers or clients.

## What Courses are Included?

Our first course, The [Node-RED Fundamentals](https://node-red-academy.learnworlds.com/){rel="&#x22;nofollow&#x22;"}, takes about 90 minutes to complete, is free and available now. [Check it out!](https://node-red-academy.learnworlds.com/){rel="&#x22;nofollow&#x22;"}.

![Screenshot of the Node-RED Fundamentals course in progress](https://flowfuse.com/blog/2025/02/images/academy-screenshot.png){dataZoomable=""}*Screenshot of the Node-RED Fundamentals course in progress*

We also have plans for the following courses to follow in the future:

- Node-RED Advanced
- Building Applications with Node-RED
- Node-RED for Industry
- Node-RED for Teams
- FlowFuse Fundamentals
- FlowFuse for Teams
- FlowFuse Advanced

This list will likely grow beyond this too. We will be evolving our courses based on feedback and ideas from the community too!

## Who's behind the Node-RED Academy?

There are many great resources for Node-RED education out there, but the Node-RED Academy has been curated by the authors and developers behind Node-RED and covers everything you'll need to know from building your first flow to integrating with industrial hardware.

FlowFuse is an enterprise-grade industrial data platform that enables engineers to build, manage, scale, and secure their Node-RED solutions for digitalizing processes and operations. You can sign up for free [here](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} to give it a go.

## How Do I Get Started?

Head to [Node-RED Academy](https://node-red-academy.learnworlds.com/){rel="&#x22;nofollow&#x22;"} and sign up for free.

![Screenshot of the Node-RED Academy home page](https://flowfuse.com/blog/2025/02/images/academy-home-page.png){dataZoomable=""}*Screenshot of the Node-RED Academy home page*


# FlowFuse 2.15: Personal Node Collections, Smart Schema Suggestions and more control in DevOps Pipelines!

Our three focal points for the latest release of FlowFuse have been:

- **Collaborative Development:** Our new **Custom Node Catalogues** provides a place for you to centralise your own private nodes and Javascript libraries for Node-RED.
- **Full Stack Applications:*&#x2A; We've added our new &#x2A;*"Smart Schema Suggestions"** feature for automatically generating documentation for your MQTT Brokers.
- **DevOps:** We've improved Pipelines now to let you deploy to Device Groups in the middle of a Pipeline, this is just the first step in a wider set of improvements to come for DevOps Pipelines.

:product-update-note

## Custom Node Catalogues

![Screenshot of the new "Custom Nodes" view in Team Library"](https://flowfuse.com/blog/2025/03/images/screenshot-custon-catalog.png){dataZoomable=""}*Screenshot of the new "Custom Nodes" view in Team Library*

### Pain Point

Many of our customers have very mature Node-RED setups, including large collections of their own, custom node packages that they have built. These packages range significantly in purpose, from small utility functions, to custom hardware integrations.

Until now, to utilise these packages within FlowFuse, you would either need to publish to the [public Node-RED Community Catalogue](https://flows.nodered.org/search?type=node){rel="&#x22;nofollow&#x22;"}, meaning all of your nodes are available to anyone in the world using Node-RED, or you had to setup and manage your own private NPM registry, which is very time consuming and requires deeper technical knowledge.

### Now in FlowFuse

With our new update, every Team- and Enterprise-Tier Library in FlowFuse has an in-built private Node collection, ready for you to go. This means that you can push your custom node packages directly to that registry, and make it available to all of your Instances running in FlowFuse within seconds. This comes built in with full version control and all of the great update mechanisms that you already have in Node-RED.

This new feature also integrates seamlessly ith our [Bill of Materials](https://flowfuse.com/docs/user/bill-of-materials/) view, providing you the single source of truth to all of your Instance's dependencies in one-place, making it easier to audit and manage your Node-RED instances and their dependencies.

## MQTT Broker Integration

### Smart Schema Suggestions

::lite-youtube
---
params: rel=0
style: "margin-bottom: 12px; width: 100%; height: 400px;"
title: YouTube video player
videoid: bNeTDJUZ1So
---
::

We are very pleased to announce our new "Smart Suggestions" feature. When working with an MQTT Broker for live data, it can be difficult to understand the structure of the data and topics that are being used. We recently released the new "Hierarchy" view, showing the topic structure present on a Broker, and we've now evolved that even further.

With Smart Suggestions, you will be presented with proposals as to what FlowFuse *thinks* your payload schema is, based on the data that is being published to your Broker. If you approve these suggestions, then FlowFuse wll start constructing a schema to represent the traffic on your Broker, and make that available in our new "Schema Documentation" view.

This will save you days of effort in documenting your Broker, and provide a single source of truth for your schema to ensure your team is always on the same page when working with your MQTT data.

### Searching for Topics

A very nice, small, improvement we've made to the Broker view too is the ability to search for topics to quickly find the topics of interest. This is a small but very useful feature, especially for those with large numbers of topics on their Broker, enabling you to find the topics of interest much faster.

## DevOps Pipelines Improvements

Last year, we announced the introduction of Device Groups. For those that are not familiar with Device Groups, this feature enables users to logically group their Remote Instances so that they can be targeted in a DevOps Pipeline, facilitating streamlined and efficient deployments across your fleet of devices, rolling out a single flow to thousands of Remote Instances within seconds.

Previously, you could only use a Group as the *last* stage in a Pipeline. With this update, you can now have Groups at other stages in a pipeline. For example, you may have a group of test Remote Instances that you want to push updates to, before pushing them out to your larger group of production Instances.

This improvement not only saves time but also enhances the consistency and reliability of Remote Instance management across your fleet.

## Removing Credit Card Requirement for Free Tier

When we recently introduced the new Free Tier for FlowFuse Cloud, we had some legacy architecture in place that meant that, whilst it was entirely free, the Free Tier still require you to put in credit card details.

This is something we've completely overhauled in the new version of FlowFuse, so now, you can just sign up and get started with building your own Remote Instances without the need for any credit card details. It was deployed to FlowFuse Cloud a week ago, and is already proving popular with new users. We can't wait to see what everyone builds on the free tier.

## FlowFuse Dashboard Authentication Now Includes User's Role

An enhancement to FlowFuse's underlying Node-RED launcher is the inclusion of the FlowFuse user's role in the `user` object return by the FlowFuse User Addon. This means you can start building your own RBAC (Role Based Access Control) into your own Node-RED/Dashboard applications, without the need to define roles and access levels directly within your Node-RED flows.

![Screenshot showing the inclusion of the user's role within Dashboard's "user" object](https://flowfuse.com/blog/2025/03/images/screenshot-user-role.png){width="300px"}{style="margin: auto"}
*Screenshot showing the inclusion of the user's role within Dashboard's "user" object*

## What Else Is New?

For a full list of everything that went into our 2.15 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.15.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try FlowFuse

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.


# Managing MQTT Connections at Scale in FlowFuse

FlowFuse makes it easy to deploy Node-RED flows at scale using DevOps pipelines and device groups. However, different stages in a pipeline may need different MQTT brokers, for example, one for development and another for production. Manually configuring each stage can be time-consuming, especially when a stage has multiple remote instances (devices).

This article shows how to continue using FlowFuse’s one-click deployment while ensuring that remote instances in each stage of your pipeline connect to the desired MQTT broker without manual configuration.

## Goal and Prerequisites

This article explains how to deploy Node-RED flows across different pipeline stages while ensuring each stage connects to its appropriate MQTT broker.

To proceed, ensure that the DevOps pipeline is created with the correct stages. If a stage includes remote instances, verify that all instances are running the FlowFuse Device Agent and are connected to your team.

For more information on how to create a DevOps pipeline, refer to [How to Build and Automate DevOps Pipelines for Node-RED Deployments](https://flowfuse.com/blog/2024/10/how-to-build-automate-devops-pipelines-node-red-deployments/). For instructions on how to create a device group, refer to the [Device Groups Documentation](https://flowfuse.com/docs/user/device-groups/).

## Setting Environment Variables for Development Instance

For this guide, environment variables will be the key tool to ensure each pipeline stage connects to the correct MQTT broker without manual intervention, allowing for a smooth deployment process.

Since the development remote instance is where the flow will be built and tested, start by adding the necessary environment variables for its MQTT configuration. Setting these up first ensures the flow runs as expected before deploying it to other pipeline stages.

1. Go to the remote/hosted instance settings in the FlowFuse platform.
2. Switch to the **Environment** settings.
3. Add the following environment variables with the appropriate values for that specific device:
   - `HOST` – The MQTT broker's hostname or IP address.
   - `PORT` – The port number the broker is listening on.
   - `USERNAME` – The authentication username for the MQTT broker.
   - `PASSWORD` – The authentication password for the MQTT broker.
   - `CLIENT_ID` – A unique identifier for the device connecting to the broker.
   - `CLIENT_ID_SUFFIX` – A suffix shared among client IDs within the broker.
   - `TOPIC` – The MQTT topic used for message communication.
4. Click **Save Settings** to apply the changes and restart the device.

## Configuring MQTT in Node-RED with Environment Variables

Now, let's explore how these environment variables can be used within Node-RED to configure the MQTT broker. Node-RED offers multiple ways to reference environment variables. Here are two primary methods to configure MQTT nodes using environment variables:

### 1. Using the Configuration Dialog:

Environment variables can be directly referenced in the MQTT node properties using the `${ENV_NAME}` syntax as shown in the following images.

![Setting up MQTT connection using environment variables.](https://flowfuse.com/blog/2025/03/images/mqtt-config-with-env.png){dataZoomable=""}&#x2A;Setting up MQTT connection using environment variables.*

![Configuring MQTT node security settings using environment variables in Node-RED.](https://flowfuse.com/blog/2025/03/images/mqtt-node-security-config.png){dataZoomable=""}&#x2A;Configuring MQTT node security settings using environment variables in Node-RED.*

![Configuring the MQTT topic in Node-RED using environment variables.](https://flowfuse.com/blog/2025/03/images/mqtt-broker-out-config.png){dataZoomable=""}&#x2A;Configuring the MQTT topic in Node-RED using environment variables.*

### 2. Setting Values Dynamically via the `msg` Object

In this approach, a **Change node** is used to retrieve environment variables and set the necessary MQTT configuration properties in the `msg` object. These properties include:

- `msg.broker.broker` – The MQTT broker’s URL or IP address.
- `msg.action` – Must be set to `"connect"` when establishing a connection.
- `msg.broker.force` – Must be set to `true` to enforce the connection.
- `msg.broker.port` – The port number for the MQTT connection.
- `msg.broker.clientid` – The unique client identifier for the device.
- `msg.broker.username` – The MQTT username for authentication.
- `msg.broker.password` – The MQTT password for authentication.
- `msg.topic` – The MQTT topic to which the device will publish or subscribe.

While the first method (direct reference in the MQTT node) is simpler and does not require additional nodes, it has limitations. It works well when there is only a single instance in the pipeline stage. However, when multiple instances exist within the same stage, the client ID, username, password, and topics often vary from device to device. The second method provides greater flexibility by dynamically adjusting these values, ensuring each device connects with the correct credentials and configurations. This approach makes the setup scalable and adaptable, eliminating the need for manual updates during deployment.

Unlike the first approach, which restricts direct combinations (e.g., string + environment variables or environment variables + environment variables), the second method enables dynamic modifications.

#### Ensuring Unique MQTT Credentials and Topics

As we mentioned in the multi-device deployment scenario, each device needs to establish its own connection to the MQTT broker while maintaining unique credentials and topics. If multiple devices in the same stage use identical configurations, connection conflicts, such as client ID duplication, may occur. To avoid these issues, each device must be assigned a unique client ID, username, password for security, and topic.

To ensure uniqueness, we can use the default environment variables available for each remote instance, such as:

- `FF_DEVICE_NAME`
- `FF_DEVICE_ID`

When generating the client ID for the MQTT broker, the device name (`FF_DEVICE_NAME`) can be used as the username. Since all client IDs share the same suffix, this suffix can be stored as a device-level environment variable (`CLIENT_ID_SUFFIX`). By combining both values, we can get the client ID of the device without manual intervention.

For the password, you can use the device ID (`FF_DEVICE_ID`), which is assigned when creating the client. Alternatively, you can set a common password for all clients by defining it as a device group-level environment variable.

![Using a Change node to dynamically set MQTT broker connection properties.](https://flowfuse.com/blog/2025/03/images/CHANGE-NODE-1.png){dataZoomable=""}&#x2A;Using a Change node to dynamically set MQTT broker connection properties.*

For topics, a combination of a string and `FF_DEVICE_NAME` can be used to ensure uniqueness.

![Configuring MQTT topics dynamically using a Change node in Node-RED.](https://flowfuse.com/blog/2025/03/images/CHANGE-NODE-TOPIC-1.png){dataZoomable=""}&#x2A;Configuring MQTT topics dynamically using a Change node in Node-RED.*

*Note: Ensure that the topic configuration is set dynamically when sending the payload, not when establishing the connection.*

Once you have built your flow to connect to the intended MQTT broker using environment variables, deploy it and verify that it works as expected.

Also, if you need an example flow to test and explore in more detail, the following flow is provided. It demonstrates how to configure the MQTT connection dynamically using environment variables and, where needed, generate some settings by combining strings with environment variables.

::render-flow
```json
[{"id":"0301bbe611a22e6d","type":"cpu","z":"aeaff62b91a987d4","name":"","msgCore":false,"msgOverall":true,"msgArray":false,"msgTemp":false,"x":450,"y":380,"wires":[["0c0ee596549272d4"]]},{"id":"4b8f4fec3983d558","type":"inject","z":"aeaff62b91a987d4","name":"Trigger every 5-second interval.","props":[],"repeat":"5","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":190,"y":440,"wires":[["0301bbe611a22e6d","e12765d187a7b502","43e83b87e202428b","552b49b55fbf8071"]]},{"id":"e12765d187a7b502","type":"Memory","z":"aeaff62b91a987d4","name":"","scale":"Gigabyte","x":440,"y":420,"wires":[["fe3d07cd9f4f1b20"]]},{"id":"43e83b87e202428b","type":"Uptime","z":"aeaff62b91a987d4","name":"","x":440,"y":460,"wires":[["29541f3dafd85db9"]]},{"id":"552b49b55fbf8071","type":"Loadavg","z":"aeaff62b91a987d4","name":"","x":440,"y":500,"wires":[["7b09b1eae14fac16"]]},{"id":"0c0ee596549272d4","type":"change","z":"aeaff62b91a987d4","name":"CPU USAGE","rules":[{"t":"set","p":"data","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"data.CPU_USAGE","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":650,"y":380,"wires":[["75445a62bac2e0c7"]]},{"id":"fe3d07cd9f4f1b20","type":"change","z":"aeaff62b91a987d4","name":"MEMORY USAGE","rules":[{"t":"set","p":"data","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"data.MEMORY_USAGE","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":670,"y":420,"wires":[["75445a62bac2e0c7"]]},{"id":"29541f3dafd85db9","type":"change","z":"aeaff62b91a987d4","name":"SYSTEM UPTIME","rules":[{"t":"set","p":"data","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"data.UPTIME","pt":"msg","to":"payload.uptime","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":670,"y":460,"wires":[["75445a62bac2e0c7"]]},{"id":"7b09b1eae14fac16","type":"change","z":"aeaff62b91a987d4","name":"LOAD AVERAGE","rules":[{"t":"set","p":"data","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"data.LOAD_AVERAGE.ONE_MIN","pt":"msg","to":"payload.loadavg[0]","tot":"msg"},{"t":"set","p":"data.LOAD_AVERAGE.FIVE_MIN","pt":"msg","to":"payload.loadavg[1]","tot":"msg"},{"t":"set","p":"data.LOAD_AVERAGE.FIFTEEN_MIN","pt":"msg","to":"payload.loadavg[2]","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":670,"y":500,"wires":[["75445a62bac2e0c7"]]},{"id":"75445a62bac2e0c7","type":"join","z":"aeaff62b91a987d4","name":"","mode":"custom","build":"merged","property":"data","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","useparts":false,"accumulate":false,"timeout":"","count":"4","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":870,"y":440,"wires":[["acf3b791d682a13d"]]},{"id":"272ec74227a151db","type":"change","z":"aeaff62b91a987d4","name":"Dynamically Configure MQTT Connection Using Environment Variables","rules":[{"t":"set","p":"action","pt":"msg","to":"connect","tot":"str"},{"t":"set","p":"broker.broker","pt":"msg","to":"HOST","tot":"env"},{"t":"set","p":"broker.port","pt":"msg","to":"PORT","tot":"env"},{"t":"set","p":"broker.clientid","pt":"msg","to":"${FF_DEVICE_NAME}${Client_ID_SUFFIX}","tot":"env"},{"t":"set","p":"broker.username","pt":"msg","to":"broker.clientid","tot":"msg"},{"t":"set","p":"broker.password","pt":"msg","to":"FF_DEVICE_ID","tot":"env"},{"t":"set","p":"broker.force","pt":"msg","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":820,"y":580,"wires":[["4860cc23dfca9720"]]},{"id":"4860cc23dfca9720","type":"mqtt out","z":"aeaff62b91a987d4","name":"","topic":"","qos":"0","retain":"","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"f484702903e298e7","x":1270,"y":580,"wires":[]},{"id":"acf3b791d682a13d","type":"change","z":"aeaff62b91a987d4","name":"Set payload and topic","rules":[{"t":"set","p":"payload","pt":"msg","to":"data","tot":"msg"},{"t":"set","p":"topic","pt":"msg","to":"factory/line2/${FF_DEVICE_NAME}","tot":"env"}],"action":"","property":"","from":"","to":"","reg":false,"x":1080,"y":440,"wires":[["4860cc23dfca9720"]]},{"id":"79dfc62b4b21d20b","type":"inject","z":"aeaff62b91a987d4","name":"Trigger on deploy","props":[],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":210,"y":580,"wires":[["272ec74227a151db"]]},{"id":"f484702903e298e7","type":"mqtt-broker","name":"","broker":"localhost","port":1883,"clientid":"","autoConnect":false,"usetls":false,"protocolVersion":4,"keepalive":60,"cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closeRetain":"false","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willRetain":"false","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":""}]
```
::

## Setting Environment Variables for a Device Group

After confirming that your flow in the development stage remote instance works as expected and connects to the broker correctly, the next step is to add environment variables.

If your target stage has only a single instance, you can set the environment variables at the instance level, as shown in the image below, and use the first method discussed earlier. This approach is straightforward and efficient for configuring a single instance using environment variables.

![Setting environment variables at the instance level in FlowFuse.](https://flowfuse.com/blog/2025/03/images/env-vars-blur.png){dataZoomable=""}&#x2A;Setting environment variables at the instance level in FlowFuse.*

However, when multiple remote instances exist within the same stage, such as in a device group, configuring them individually can be impractical, especially when most settings remain the same. To simplify this process, FlowFuse allows you to set environment variables at the device group level, and you can use the second method to make the configuration quick and easy while using remote instance default environment variables.

To add the device group level environment variables follow the steps:

1. Go to your **device group’s settings** in the FlowFuse platform.
2. Add the following environment variables with the appropriate values:
   - `HOST`
   - `PORT`
   - `CLIENT_ID_SUFFIX`
3. Click **Save Settings** to apply the changes.

![Configuring environment variables at the device group level.](https://flowfuse.com/blog/2025/03/images/env-settings.png){dataZoomable=""}&#x2A;Configuring environment variables at the device group level.*

With this approach, you do not need to set environment variables separately for each instance. Instead, the environment variables defined at the device group level will apply to all remote instances within the group, ensuring a consistent and efficient configuration.

## Deploying Flow with Stage-Specific Configurations via DevOps Pipeline

Now that everything is set up, trigger the deployment pipeline for the development stage. This will push the flow and settings to the next-stage instances while preserving the existing environment variables. Before applying the new configuration, all remote instances in the target stage will restart automatically.

![Deploying Node-RED flows using FlowFuse's DevOps pipeline.](https://flowfuse.com/blog/2025/03/images/devops-pipeline.png){dataZoomable=""}&#x2A;Deploying Node-RED flows using FlowFuse's DevOps pipeline.*

If everything is configured correctly, the MQTT nodes in each remote Node-RED instance will connect to the appropriate broker configured at the device group level.

## Monitoring MQTT Topic Hierarchy with FlowFuse

Once the Node-RED flow is deployed on all remote instances in the device group and the MQTT nodes in each instance are connected to the broker, you can monitor and manage all topics across all brokers directly in FlowFuse.

![Monitoring MQTT topics in FlowFuse across multiple brokers.](https://flowfuse.com/blog/2025/03/images/mqtt-broker-monitoring.png){dataZoomable=""}&#x2A;Monitoring MQTT topics in FlowFuse across multiple brokers.*

Watch this short video to learn how to bring your own brokers for topic monitoring in FlowFuse: <https://youtube.com/shorts/-8TPXb0h0vA?si=wi3wghi4vUWlXJTZ>{rel="&#x22;nofollow&#x22;"}

## Conclusion

FlowFuse makes it easy to deploy Node-RED flows while ensuring each stage connects to the right MQTT broker. By using environment variables at both the instance and device group levels, you can automate MQTT configurations, reducing manual setup and ensuring consistency.

[Get Started Now](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}


# How to Build a Manufacturing OEE Dashboard with FlowFuse

In [Part 1](https://flowfuse.com/blog/2025/04/what-is-an-oee-dashboard/), we explored the fundamentals of OEE, outlined a basic design of the dashboard, and identified the key elements to include in the OEE dashboard.
In this second part, we will focus on building the OEE dashboard interface using [FlowFuse Dashboard](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"} (Node-RED Dashboard 2.0) and FlowFuse, utilizing simulated production and downtime data, the same kind of data you'd track for torque, weld cycle time, or paint throughput on an [automotive](https://flowfuse.com/industries/automotive/) line.

## Getting Started

To simplify the development process, we will divide development into five key parts:

1. Collecting and configuring data
2. Preparing data for calculations
3. Calculating OEE and key metrics
4. Detailed breakdown of OEE data
5. Building the dashboard

Before we start, it is recommended to have a basic knowledge of Node-RED. For that, I recommend this free [Node-RED Fundamental Course](https://node-red-academy.learnworlds.com/course/node-red-getting-started){rel="&#x22;nofollow&#x22;"}.

Additionally, ensure that you organize flows into well-structured groups. To match my group organization, I have provided images of the flow for each section. Also, if a Link In node is present at the start, create the group starting from the Link In node and ending at the Link Out node.

### Prerequisites

Before you begin building the OEE Dashboard with FlowFuse, make sure you have the following:

- **Running FlowFuse Instance:** Make sure you have a FlowFuse instance set up and running. If you don't have an account, check out our [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and learn how to create an instance in FlowFuse.
- **FlowFuse Dashboard:** Ensure you have [FlowFuse Dashboard](https://flows.nodered.org/node/@flowfuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"} (also known as Node-RED Dashboard 2.0 in the community) installed and properly configured on your instance.
- **SQLite Contrib Node:** Ensure you have [node-red-contrib-sqlite](https://flows.nodered.org/node/node-red-node-sqlite){rel="&#x22;nofollow&#x22;"} installed. We use SQLite here because it needs no setup, but the flow works against any database - [FlowFuse Tables](https://flowfuse.com/docs/user/ff-tables/) gives you managed PostgreSQL if you want something production-grade from the start, and our [Database](https://flowfuse.com/node-red/database/) guides cover MongoDB, InfluxDB, TimescaleDB, and DynamoDB.

### Preparing Simulated Data

Before building the dashboard, we need a data source for production and downtime metrics. This data will serve as input for OEE calculations. [Part 3 covers connecting a real source](https://flowfuse.com/blog/2025/04/design-and-scale-oee-dashboard/), including how to remap the queries when your database field names differ. For now, let's generate simulated data.

::render-flow{:height='300'}
```json
[{"id":"fa7147e04d4d5ec3","type":"tab","label":"Simulated Data Generation","disabled":false,"info":"","env":[]},{"id":"3f2126c3c00b9e0d","type":"group","z":"fa7147e04d4d5ec3","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["853fb3a395d833bb","a96ffd171bf11823","3d30995a4329eb71","0f466ba2a885e22a","f8229c651706b162","2ceebc93d54adba4","0c927abd3b139e97","8222855bc32e9240"],"x":24,"y":99,"w":1142,"h":182},{"id":"07a3d5b9075ff846","type":"group","z":"fa7147e04d4d5ec3","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["aa7bd867fa7daca5","234aef8a999cb8d9","d7641c9327f295f8","c3e96b73cd6ec586","13f2e851e3f28ec6","9a444655c076d5a7","e1fe1b1a4f1ef2e5","2beb68abc5da93bc","b83d517fae3c7bbf","50ebbbfb159a3cbe","8873774ad339b67e","77e22b20d1862c7e"],"x":-6,"y":299,"w":2092,"h":162},{"id":"c0550db87d6fb947","type":"group","z":"fa7147e04d4d5ec3","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["b1f773f4cc2266c6","cce91928076adb23","d853a554ecd152b1","45628fb0ca0a4672","36ae627ad694fc09","69afd49e2ceb191b","808db5612ba1aedc","6dcd69acd5990793"],"x":34,"y":479,"w":1202,"h":142},{"id":"a96ffd171bf11823","type":"template","z":"fa7147e04d4d5ec3","g":"3f2126c3c00b9e0d","name":"Create ProductionData table","field":"topic","fieldType":"msg","format":"sql","syntax":"mustache","template":"CREATE TABLE IF NOT EXISTS ProductionData (\n    id INTEGER PRIMARY KEY AUTOINCREMENT,\n    timestamp DATETIME NOT NULL,\n    area VARCHAR(255) NOT NULL,\n    line VARCHAR(100) NOT NULL,  \n    machine_name VARCHAR(255) NOT NULL,\n    shift VARCHAR(50) NOT NULL,\n    shift_duration DECIMAL(5,2) NOT NULL,\n    good_units INT NOT NULL,\n    defect_units INT NOT NULL,\n    total_produced_units INT NOT NULL,\n    cycle_time DECIMAL(5,2) NOT NULL,\n    ideal_cycle_time DECIMAL(5,2) NOT NULL,\n    target_output INT NOT NULL DEFAULT 0,\n    operating_time INT NOT NULL\n);\n","output":"str","x":500,"y":140,"wires":[["853fb3a395d833bb"]]},{"id":"3d30995a4329eb71","type":"inject","z":"fa7147e04d4d5ec3","g":"3f2126c3c00b9e0d","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":150,"y":140,"wires":[["a96ffd171bf11823"]]},{"id":"0f466ba2a885e22a","type":"debug","z":"fa7147e04d4d5ec3","g":"3f2126c3c00b9e0d","name":"debug 1","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1050,"y":140,"wires":[]},{"id":"2ceebc93d54adba4","type":"template","z":"fa7147e04d4d5ec3","g":"3f2126c3c00b9e0d","name":"Create Downtime table","field":"topic","fieldType":"msg","format":"sql","syntax":"mustache","template":"CREATE TABLE IF NOT EXISTS DowntimeData (\n    id INTEGER PRIMARY KEY AUTOINCREMENT,\n    timestamp DATETIME NOT NULL,\n    area VARCHAR(255) NOT NULL,\n    line VARCHAR(100) NOT NULL,  \n    machine_name VARCHAR(255) NOT NULL,\n    shift VARCHAR(50) NOT NULL,\n    downtime_start DATETIME NOT NULL,\n    downtime_end DATETIME NOT NULL,\n    downtime_duration_minutes INTEGER NOT NULL,\n    downtime_type VARCHAR(50) NOT NULL CHECK (downtime_type IN ('Planned', 'Unplanned')),\n    downtime_reason TEXT NOT NULL\n);\n","output":"str","x":440,"y":240,"wires":[["f8229c651706b162"]]},{"id":"0c927abd3b139e97","type":"inject","z":"fa7147e04d4d5ec3","g":"3f2126c3c00b9e0d","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":150,"y":240,"wires":[["2ceebc93d54adba4"]]},{"id":"8222855bc32e9240","type":"debug","z":"fa7147e04d4d5ec3","g":"3f2126c3c00b9e0d","name":"debug 2","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1050,"y":240,"wires":[]},{"id":"234aef8a999cb8d9","type":"template","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","name":"Insert production data record","field":"topic","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"INSERT INTO ProductionData (\n    timestamp, \n    area, \n    line, \n    machine_name, \n    shift, \n    shift_duration, \n    good_units, \n    defect_units, \n    total_produced_units, \n    cycle_time, \n    ideal_cycle_time,  \n    target_output,\n    operating_time  \n) \nVALUES (\n    '{{payload.timestamp}}', \n    '{{payload.area}}', \n    '{{payload.line}}', \n    '{{payload.machine_name}}', \n    '{{payload.shift}}', \n    '{{payload.shift_duration}}',  \n    '{{payload.good_units}}',  \n    '{{payload.defect_units}}',  \n    '{{payload.total_produced_units}}',  \n    '{{payload.cycle_time}}',  \n    '{{payload.ideal_cycle_time}}',  \n    '{{payload.target_output}}',  \n    '{{payload.operating_time}}'  \n);\n","output":"str","x":1550,"y":340,"wires":[["aa7bd867fa7daca5"]]},{"id":"d7641c9327f295f8","type":"debug","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","name":"debug 3","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1970,"y":340,"wires":[]},{"id":"cce91928076adb23","type":"template","z":"fa7147e04d4d5ec3","g":"c0550db87d6fb947","name":"Drop demo downtime data","field":"topic","fieldType":"msg","format":"sql","syntax":"mustache","template":"Drop table DowntimeData;","output":"str","x":480,"y":580,"wires":[["b1f773f4cc2266c6"]]},{"id":"d853a554ecd152b1","type":"inject","z":"fa7147e04d4d5ec3","g":"c0550db87d6fb947","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":150,"y":580,"wires":[["cce91928076adb23"]]},{"id":"45628fb0ca0a4672","type":"debug","z":"fa7147e04d4d5ec3","g":"c0550db87d6fb947","name":"debug 5","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1120,"y":580,"wires":[]},{"id":"c3e96b73cd6ec586","type":"inject","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","name":"Click to generate and insert demo data.","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":"0.5","topic":"","payload":"","payloadType":"date","x":230,"y":380,"wires":[["13f2e851e3f28ec6"]]},{"id":"13f2e851e3f28ec6","type":"function","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","name":"Generate simulated production and downtime data","func":"function generateProductionData() {\n    const areas = {\n        \"Pressing\": [\"Hydraulic Press\", \"CNC Press Brake\", \"Stamping Press\", \"Power Press\"],\n        \"Assembly\": [\"Robotic Arm\", \"Screw Insertion Machine\", \"Pick-and-Place Machine\"],\n        \"Packaging\": [\"Carton Sealing Machine\", \"Shrink Wrapping Machine\", \"Bottle Filling and Capping Machine\", \"Flow Wrapper\"]\n    };\n\n    const shifts = [\"Shift 1\", \"Shift 2\", \"Shift 3\"];\n    const shiftStartTimes = {\n        \"Shift 1\": \"00:00:00\",\n        \"Shift 2\": \"08:00:00\",\n        \"Shift 3\": \"16:00:00\"\n    };\n\n    const uniqueShortCodes = {\n        \"Pressing\": [\"HP\", \"PB\", \"SP\", \"PP\"],\n        \"Assembly\": [\"RA\", \"SIM\", \"P and P\"],\n        \"Packaging\": [\"CSM\", \"SWM\", \"BFCM\", \"FW\"]\n    };\n\n    const downtimeTypes = [\"Planned\", \"Unplanned\"];\n    const plannedDowntimeReasons = [\n        \"Scheduled Maintenance\", \"Equipment Upgrades\", \"Shift Changeover\",\n        \"Tool Changeover\", \"Calibration and Quality Checks\", \"Cleaning and Sanitation\", \"Planned Power Outage\"\n    ];\n    const unplannedDowntimeReasons = [\n        \"Power Failure\", \"Material Shortage\", \"Technical Fault\", \"Operator Unavailable\"\n    ];\n\n    const data = [];\n    const downtimeData = [];\n    const now = new Date();\n\n    const normalizeTimestamp = (timestamp) => timestamp.toISOString().split(\"T\").join(\" \").slice(0, 19);\n\n    for (let i = 0; i < 30; i++) {\n        const date = new Date();\n        date.setDate(now.getDate() - i);\n        const formattedDate = date.toISOString().split(\"T\")[0];\n\n        shifts.forEach(shift => {\n            const shiftStart = shiftStartTimes[shift];\n            const shiftTimestamp = new Date(`${formattedDate}T${shiftStart}`);\n\n            Object.entries(areas).forEach(([area, machines]) => {\n                machines.forEach((_, index) => {\n                    const randomCode = uniqueShortCodes[area][Math.floor(Math.random() * uniqueShortCodes[area].length)];\n                    const uniqueID = Math.floor(10000 + Math.random() * 90000);\n                    const shortMachineName = `${randomCode}-${uniqueID}`;\n\n                    const shiftDuration = 8;\n                    let totalDowntimeMinutes = 0;\n                    let downtimeEvents = [];\n\n                    // Increase downtime frequency (up to 4 events per shift)\n                    const numDowntimes = Math.floor(Math.random() * 4) + 1;\n\n                    for (let d = 0; d < numDowntimes; d++) {\n                        if (Math.random() < 0.75) {  // Increase probability of downtime\n                            let downtimeMinutes = Math.floor(5 + Math.random() * 10); // Shorter downtimes (5-15 mins)\n                            totalDowntimeMinutes += downtimeMinutes;\n\n                            const downtimeStartMinutes = Math.floor(Math.random() * (shiftDuration * 60 - downtimeMinutes));\n                            const downtimeStart = new Date(shiftTimestamp);\n                            downtimeStart.setMinutes(downtimeStart.getMinutes() + downtimeStartMinutes);\n\n                            const downtimeEnd = new Date(downtimeStart);\n                            downtimeEnd.setMinutes(downtimeEnd.getMinutes() + downtimeMinutes);\n\n                            const downtimeType = downtimeTypes[Math.floor(Math.random() * downtimeTypes.length)];\n                            const downtimeReason = downtimeType === \"Planned\"\n                                ? plannedDowntimeReasons[Math.floor(Math.random() * plannedDowntimeReasons.length)]\n                                : unplannedDowntimeReasons[Math.floor(Math.random() * unplannedDowntimeReasons.length)];\n\n                            downtimeEvents.push({\n                                timestamp: normalizeTimestamp(shiftTimestamp),\n                                area,\n                                machine_name: shortMachineName,\n                                shift,\n                                downtime_start: normalizeTimestamp(downtimeStart),\n                                downtime_end: normalizeTimestamp(downtimeEnd),\n                                downtime_duration_minutes: downtimeMinutes,\n                                downtime_reason: downtimeReason,\n                                downtime_type: downtimeType,\n                                line: `Line-${index + 1}`\n                            });\n                        }\n                    }\n\n                    const operatingTime = (shiftDuration * 60 - totalDowntimeMinutes) * 60;\n                    let efficiency = Math.random() * 0.2 + 0.75;\n                    let targetOutput = Math.floor(operatingTime / 3) || 1;\n                    let totalProduced = Math.floor(targetOutput * efficiency);\n                    totalProduced = Math.min(totalProduced, targetOutput);\n\n                    const defectRate = Math.random() * 0.02 + 0.01;\n                    const defectUnits = Math.floor(totalProduced * defectRate);\n                    const goodUnits = totalProduced - defectUnits;\n\n                    data.push({\n                        timestamp: normalizeTimestamp(shiftTimestamp),\n                        area,\n                        machine_name: shortMachineName,\n                        shift,\n                        shift_duration: shiftDuration,\n                        operating_time: operatingTime - totalDowntimeMinutes * 60,\n                        good_units: goodUnits,\n                        defect_units: defectUnits,\n                        total_produced_units: totalProduced,\n                        target_output: targetOutput,\n                        line: `Line-${index + 1}`\n                    });\n\n                    downtimeData.push(...downtimeEvents);\n                });\n            });\n        });\n    }\n\n    return [\n        { payload: data },\n        { payload: downtimeData }\n    ];\n}\n\nconst productionDataSet = generateProductionData();\n\nreturn [\n    { payload: productionDataSet[0].payload },\n    { payload: productionDataSet[1].payload }\n];\n","outputs":2,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":690,"y":380,"wires":[["9a444655c076d5a7"],["8873774ad339b67e"]]},{"id":"9a444655c076d5a7","type":"split","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","name":"","splt":"\\n","spltType":"str","arraySplt":1,"arraySpltType":"len","stream":false,"addname":"","x":1060,"y":340,"wires":[["e1fe1b1a4f1ef2e5"]]},{"id":"e1fe1b1a4f1ef2e5","type":"delay","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","name":"10 msg/s","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"10","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":1280,"y":340,"wires":[["234aef8a999cb8d9"]]},{"id":"b83d517fae3c7bbf","type":"template","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","name":"Insert downtime data record","field":"topic","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"INSERT INTO DowntimeData ( timestamp, area, line, machine_name, shift, \n    downtime_start, downtime_end, downtime_duration_minutes, \n    downtime_type, downtime_reason\n)  \nVALUES (\n    '{{payload.timestamp}}',  \n    '{{payload.area}}', \n    '{{payload.line}}', \n    '{{payload.machine_name}}', \n    '{{payload.shift}}', \n    '{{payload.downtime_start}}',\n    '{{payload.downtime_end}}',  \n    {{payload.downtime_duration_minutes}},  \n    '{{payload.downtime_type}}',  \n    '{{payload.downtime_reason}}'  \n);\n","output":"str","x":1550,"y":420,"wires":[["2beb68abc5da93bc"]]},{"id":"50ebbbfb159a3cbe","type":"debug","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","name":"debug 8","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1970,"y":420,"wires":[]},{"id":"8873774ad339b67e","type":"split","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","name":"","splt":"\\n","spltType":"str","arraySplt":1,"arraySpltType":"len","stream":false,"addname":"","x":1060,"y":420,"wires":[["77e22b20d1862c7e"]]},{"id":"77e22b20d1862c7e","type":"delay","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","name":"10 msg/s","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"10","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":1280,"y":420,"wires":[["b83d517fae3c7bbf"]]},{"id":"69afd49e2ceb191b","type":"template","z":"fa7147e04d4d5ec3","g":"c0550db87d6fb947","name":"Drop demo production data","field":"topic","fieldType":"msg","format":"sql","syntax":"mustache","template":"Drop table ProductionData;","output":"str","x":480,"y":520,"wires":[["36ae627ad694fc09"]]},{"id":"808db5612ba1aedc","type":"inject","z":"fa7147e04d4d5ec3","g":"c0550db87d6fb947","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":150,"y":520,"wires":[["69afd49e2ceb191b"]]},{"id":"6dcd69acd5990793","type":"debug","z":"fa7147e04d4d5ec3","g":"c0550db87d6fb947","name":"debug 4","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1120,"y":520,"wires":[]},{"id":"853fb3a395d833bb","type":"sqlite","z":"fa7147e04d4d5ec3","g":"3f2126c3c00b9e0d","mydb":"1ae6d7f7fdb60191","sqlquery":"msg.topic","sql":"","name":"","x":720,"y":140,"wires":[["0f466ba2a885e22a"]]},{"id":"f8229c651706b162","type":"sqlite","z":"fa7147e04d4d5ec3","g":"3f2126c3c00b9e0d","mydb":"1ae6d7f7fdb60191","sqlquery":"msg.topic","sql":"","name":"","x":720,"y":240,"wires":[["8222855bc32e9240"]]},{"id":"aa7bd867fa7daca5","type":"sqlite","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","mydb":"1ae6d7f7fdb60191","sqlquery":"msg.topic","sql":"","name":"","x":1780,"y":340,"wires":[["d7641c9327f295f8"]]},{"id":"b1f773f4cc2266c6","type":"sqlite","z":"fa7147e04d4d5ec3","g":"c0550db87d6fb947","mydb":"1ae6d7f7fdb60191","sqlquery":"msg.topic","sql":"","name":"","x":730,"y":580,"wires":[["45628fb0ca0a4672"]]},{"id":"2beb68abc5da93bc","type":"sqlite","z":"fa7147e04d4d5ec3","g":"07a3d5b9075ff846","mydb":"1ae6d7f7fdb60191","sqlquery":"msg.topic","sql":"","name":"","x":1780,"y":420,"wires":[["50ebbbfb159a3cbe"]]},{"id":"36ae627ad694fc09","type":"sqlite","z":"fa7147e04d4d5ec3","g":"c0550db87d6fb947","mydb":"1ae6d7f7fdb60191","sqlquery":"msg.topic","sql":"","name":"","x":730,"y":520,"wires":[["6dcd69acd5990793"]]},{"id":"1ae6d7f7fdb60191","type":"sqlitedb","db":"sqllite","mode":"RWC"}]
```
::

1. Import the provided flow for data generation.
2. Click the **Deploy** button to activate the flow.
3. On deployment, it will create two SQLite tables: `ProductionData` and `DowntimeData`.
4. Find the **Inject node** labeled *Click to generate and insert demo data*.
5. Click the inject node to trigger data generation.

The flow will generate data with the following fields:

![Demo Production and Downtime data object](https://flowfuse.com/blog/2025/04/images/demo-data-props.png){dataZoomable=""}*Demo Production and Downtime data object*

### Collecting and Configuring Data

Once the simulated data is generated and stored in SQLite, the next step is to create a flow for configuration settings. These settings will be used across the entire flow, allowing the flow to be reused by simply modifying the settings. The configured data will then be collected for use in the OEE dashboard.

#### Adding flow to configure settings:

1. Click on the &#x2A;*"+"** to create a new flow.
2. Name the newly created flow to **OEE Dashboard for Line-1**.
3. Drag a **Change node** onto the canvas, double-click it, and add the following elements:
   - Set `flow.line` to `"Line-1"`
   - Set `flow.shift_duration` to `12`
   - Set `flow.shiftDuration24h` to `24`
4. Drag an **Inject node**, set it to trigger on deploy by enabling **Inject once after X seconds** (set delay to `0.1` seconds).
5. Click **Deploy** to apply changes.

In this flow, we are configuring the production line based on the demo data, specifically for **Line-1**, as we are building the OEE dashboard for this line. The settings define the shift duration for the last **X** hours used in OEE calculations and the total shift duration within a **24-hour** period.

![Flow to set basic configuration settings that will be used across the OEE dashboard flow for calculations.](https://flowfuse.com/blog/2025/04/images/configuration-flow.png){dataZoomable=""}&#x2A;Flow to set basic configuration settings that will be used across the OEE dashboard flow for calculations.*

#### Retrieving Data from SQLite:

1. Drag an **Inject node** and configure it to trigger at regular intervals.
2. Drag a **Change node** and add following elements:
   - Set `msg.params` to `{}`
   - Set `msg.params.$startTime` to `$moment($millis() - ($number($flowContext('shift_duration')) * 60 * 60 * 1000)).format('YYYY-MM-DD HH:mm:ss')`
   - Set `msg.params.$endTime` to `$moment($millis()).format('YYYY-MM-DD HH:mm:ss')`
   - Set `msg.params.$line` to `flow.line`
3. Drag an **SQLite node** and insert the following query:
   ```sql
   SELECT timestamp, machine_name, area, line, total_produced_units, good_units, defect_units, target_output
   FROM ProductionData
   WHERE timestamp BETWEEN $startTime AND $endTime AND line = $line;
   ```
4. Drag a Change node onto the canvas and set the following element to store the retrived production data result as new property:
   - Set `msg.payload` to `msg.productionData`
5. Connect the Inject node’s output to the input of the Change node that sets parameters. Then, connect the Change node’s output to the input of the SQLite node that retrieves production data. Finally, connect the SQLite node’s output to the input of last change node we added.
6. Drag another **SQLite node** and insert the following query:
   ```sql
   SELECT timestamp, machine_name, downtime_start, downtime_duration_minutes, downtime_reason
   FROM DowntimeData
   WHERE timestamp BETWEEN $startTime AND $endTime AND line = $line;
   ```
7. Drag a Change node onto the canvas and set the following element to store the retrived production data result as new property:
   - Set `msg.payload` to `msg.downtimeData`
8. Connect the SQLite node’s output to the input of last change node we added.
9. Now, drag the Link Out node onto the canvas and connect it to the last Change node.

![Flow that retrives the data from the sqlite table](https://flowfuse.com/blog/2025/04/images/sqlite-flow.png){dataZoomable=""}*Flow that retrives the data from the sqlite table*

### Preparing Data for OEE Calculations

Now that we have a flow to retrieve production and downtime data, we can calculate key OEE metrics. The total number of good units, defective units, total produced units, target output, and downtime duration are summed across all production lines. Using these values, we can calculate availability, performance, and quality for the entire production system, which can then be used to calculate OEE.

1. Drag the **link in node** onto the canvas and connect it to the **link out node**.
2. Drag two **Change nodes** onto the canvas and connect them to the **Link In** node.
   - In the first Change node, set `msg.payload` to `production_data`.
   - In the second Change node, set `msg.payload` to `downtime_data`.
3. Drag a **Split node** onto the canvas and connect it to the first **Change node**, the one setting `production_data`. Configure the **Split node** so that `msg.payload` is assigned to `production_data`.
4. Drag three **Join nodes** onto the canvas and connect them to the **Split node** to sum individual data points. Configure each **Join node** with the following settings:
   - Mode: Reduce Sequence
   - Initial Value: 0
   - Fix-up Expression: `$A`
5. Set the reduce expressions as follows:
   - First Join Node: `$A + msg.payload.total_produced_units`
   - Second Join Node: `$A + msg.payload.good_units`
   - Third Join Node: `$A + msg.payload.target_output`
6. Drag three **Change nodes** onto the canvas and connect each to a **Join node**.
7. Configure these **Change nodes** to store the summed values using the following variables to flow context:
   - `total_produced_units`
   - `total_good_units`
   - `total_target_output`
8. Drag a **Switch node** onto the canvas and connect it to the **Change node** that sets the retrieved downtime data to `msg.payload`, for switch node set the Property to `msg.payload` and add the following conditions:
   - is not empty.
   - Otherwise.
9. Drag a **Split node** onto the canvas and connect it to the first output of the **Switch node**.
10. Drag a **Join node** onto the canvas and connect it to the **Split node**.
11. Configure the **Join node** with the following settings:
    - Mode: Reduce Sequence
    - Initial Value: 0
    - Fix-up Expression: `$A`
    - Reduce Expression: `$A + payload.downtime_duration_minutes`
12. Drag a **Change node** onto the canvas and connect it to the **Join node**, Configure this **Change node** to store the total downtime duration in the flow context with following element:
    - Set `flow.total_downtime` to `msg.payload`
13. Drag another Change node onto the canvas and connect it to the second output of the Switch node, Set this Change node to store 0 in the flow context for total\_downtime with following element:

- Set `flow.total_downtime` to 0

14. Drag a **Link Out** node onto the canvas and connect it to any of the Change nodes that store the summed metrics in the flow context.

![Flow to prepare the data necessary to calculate OEE and all its three components.](https://flowfuse.com/blog/2025/04/images/preparing-data-flow.png){dataZoomable=""}&#x2A;Flow to prepare the data necessary to calculate OEE and all its three components.*

### Calculating OEE and Key Metrics

Now that we have all the necessary pieces, we can calculate the key metrics for OEE: Availability, Performance, and Quality and later OEE.

1. Drag a **Link In node**.
2. Drag a **Change node** and add element as following:
   - Set `msg.quality` to `($flowContext('total_good_units') / $flowContext('total_produced_units')) * 100` as JSONata expression.
   - Set `msg.availability` to `(($flowContext('shift_duration') - $flowContext('total_downtime')) / $flowContext('shift_duration')) * 100` as JSONata expression.
   - Set `msg.performance` to `($flowContext('total_produced_units') / $flowContext('target_output')) * 100` as JSONata expression.
   - Set `msg.oee` to `$round(((msg.availability / 100) * (msg.performance / 100) * (msg.quality / 100)) * 100, 2)` as JSONata expression.
   - Set `msg.quality`to `$round(msg.quality, 2)`
   - Set `msg.availability` to `$round(msg.availability, 2)`
   - Set `msg.performance` to `$round(msg.performance, 2)`
   - Set `msg.productionData` to JSONata expression:
   ```json
   [
   {
       "reason": "Total Good Units Produced",
       "units": $flowContext("total_good_units")
     },
     {
       "series": "Total Defective Units Produced",
       "units": $number($flowContext("total_produced_units")) - $number($flowContext("total_good_units"))
     }
   ]
   ```
3. Drag a **Link Out node** and connect it to the **Change node**.
4. Drag a separate **Link In** node for visualization and keep it in a separate flow. This will be the **Link In** node where all the calculated final data for visualization will be stored.
5. Connect **link out** node to this **link in** node.

![Flow that calculates availability, quality, performance, and OEE, and also prepares production data for visualization.](https://flowfuse.com/blog/2025/04/images/calculate-oee-and-key-metrics.png){dataZoomable=""}&#x2A;Flow that calculates availability, quality, performance, and OEE, and also prepares production data for visualization.*

### Detailed Breakdown of OEE Data

We have calculated the OEE and other key metrics. However, as discussed in the planning section of our previous article, we will also visualize recent downtime events, a downtime summary, the top underperforming machines (OEE-wise), and the OEE trend over the last 30 days on the dashboard.

Let’s do that.

1. Drag the **link in node** onto the canvas and connect it to the **link out node** that is part of the SQLite flow, which is also connected to the change node that sets the retrieved downtime result to `msg.payload`.
2. Drag a **change node** onto the canvas and set the following element: `Set msg.downtime_data to msg.payload`.

#### Downtime Summary

1. Drag a **function node** onto the canvas and add the following JavaScript to calculate the downtime summary:

```javascript
function calculateDowntimeByReason(downtimeData) {
   if (!Array.isArray(downtimeData) || downtimeData.length === 0) {
       return []; f
   }
   const summary = {};
   downtimeData.forEach(({ downtime_reason, downtime_duration_minutes }) => {
       summary[downtime_reason] = (summary[downtime_reason] || 0) + downtime_duration_minutes;
   });
   return Object.entries(summary).map(([reason, duration]) => ({
       downtime_reason: reason,
       downtime_duration_minutes: duration
   }));
}
msg.payload = calculateDowntimeByReason(msg.payload) || [];
return msg;
```

2. Drag a **change node** onto the canvas and set:
   - Set `msg.payload` to `msg.downtimeSummary`.
3. Drag a **link out** node and connect it to the change node that sets `msg.downtime_data` to `msg.payload`.
4. Connect this **link out node** to the **link in node** that we added earlier to receive all the calculated metrics for visualization.

#### Recent Downtime

1. Drag a **Switch** node onto the canvas and set the property to **msg.payload**. Add the following condition:
   - **is not empty**
   - **otherwise**
2. Drag a **Split** node onto the canvas and connect it to the **first output** of the **Switch** node.
3. Drag a **Sort** node onto the canvas and connect it to the **Split*&#x2A; node. Set the sort to &#x2A;*"message sequence"*&#x2A;, key to &#x2A;*`msg.payload.downtime_start`*&#x2A;, and order to &#x2A;*"descending."** This will sort the downtime data from **most recent to oldest** based on its start time.
4. Drag a **Join** node onto the canvas and set the mode to **automatic**, then connect it to the **Sort** node.
5. Drag a **Change** node onto the canvas and set the following element:
   - **Set `msg.recentDowntime` to `payload^(10)` as a JSONata expression.**
6. Connect the **Change** node to the **Link Out** node that was added before.

#### Top Underperforming Machines

1. Drag a **Function** node onto the canvas and connect it to the **Link In** node that is receiving the **SQLite result**.
2. Add the following **JavaScript** code to the **Function** node:

```javascript
const productionData = msg.production_data;
const downtimeEvents = msg.downtime_data;
const shiftDuration = (flow.get('shift_duration') || 1) * 60; // Convert hours to minutes

// Group production data by machine (including area)
let machineData = {};
productionData.forEach(data => {
    if (!machineData[data.machine_name]) {
        machineData[data.machine_name] = {
            total_produced_units: 0,
            good_units: 0,
            target_output: 0,
            count: 0,
            area: data.area // Store area
        };
    }
    machineData[data.machine_name].total_produced_units += data.total_produced_units;
    machineData[data.machine_name].good_units += data.good_units;
    machineData[data.machine_name].target_output += data.target_output;
    machineData[data.machine_name].count += 1;
});

let oeeResults = Object.keys(machineData).map(machineName => {
    let data = machineData[machineName];

    let machineDowntime = downtimeEvents.filter(event => event.machine_name === machineName);

    function calculateOEE(data, downtime) {
        if (data.target_output === 0) {
            return { availability: 0, performance: 0, quality: 0, oee: 0 };
        }

        let totalDowntime = downtime.reduce((acc, event) =>
            typeof event.downtime_duration_minutes === 'number' ? acc + event.downtime_duration_minutes : acc
            , 0);

        let availability = (shiftDuration - totalDowntime) / shiftDuration;
        availability = Math.max(0, Math.min(1, availability));

        let performance = data.target_output > 0 ? data.total_produced_units / data.target_output : 0;
        let quality = data.total_produced_units > 0 ? data.good_units / data.total_produced_units : 0;

        let oee = availability * performance * quality;

        return {
            availability: parseFloat((availability * 100).toFixed(2)),
            performance: parseFloat((performance * 100).toFixed(2)),
            quality: parseFloat((quality * 100).toFixed(2)),
            oee: parseFloat((oee * 100).toFixed(2))
        };
    }

    let metrics = calculateOEE(data, machineDowntime);

    return {
        machine_name: machineName,
        area: data.area,
        oee: metrics.oee
    };
});

// Filter only machines with OEE < 85
msg.payload = oeeResults.filter(machine => machine.oee < 85);

return msg;
```

![Flow that prepares the Recent Downtime, Downtime Summary, and Top Underperforming Machines (OEE-wise)
](https://flowfuse.com/blog/2025/04/images/downtime-events-summery-oee-machine-wise.png){dataZoomable=""}&#x2A;Flow that prepares the Recent Downtime, Downtime Summary, and Top Underperforming Machines (OEE-wise)*

#### OEE Trend for the Last 30 Days

Now, to calculate the OEE for the last 30 days, we need the complete production and downtime data for that period. However, the current SQLite flow retrieves only the last 12 hours. Therefore, we need another SQLite flow to retrieve data from the last 30 days.

##### Retrieving Production and Downtime Data for the Last 30 Days

1. Copy the existing **SQLite flow** from the **Inject node** to the **Change node** that sets the retrieved downtime result to `msg.payload`.
2. Click on the **Change node** that sets the parameters for the SQL query, keep only the element setting the line parameter, and remove the rest.
3. Modify the first SQLite node's SQL query to the following:

```sql
SELECT
    timestamp AS timestamp,
    machine_name AS machine_name,
    area AS area,
    line AS line,
    total_produced_units AS total_produced_units,
    good_units AS good_units,
    defect_units AS defect_units,
    target_output AS target_output
FROM ProductionData
WHERE line = $line
  AND timestamp >= datetime('now', '-30 days');
```

4. Modify the second SQLite node's SQL query to the following:

```sql
SELECT
    timestamp AS timestamp,
    machine_name AS machine_name,
    downtime_start AS downtime_start,
    downtime_duration_minutes AS downtime_duration_minutes,
    downtime_reason AS downtime_reason
FROM DowntimeData
WHERE
    timestamp BETWEEN $startTime AND $endTime
    AND line = $line;
```

##### Calculating last 30d days OEE

1. Drag the **Link Out node** onto the canvas and connect it to the last **Change node** of the SQLite flow.
2. Drag the **Link In node** onto the canvas and connect it to the last **Link Out node**.
3. Drag the **Function node** onto the canvas, add the following JavaScript, and connect the Function node to the **Link In node**:

```javascript
let productionData = msg.production_data;
let downtimeData = msg.downtime_data;
let line = flow.get('line');
let shiftDuration = flow.get('shiftDuration24h') * 3600;

let groupedData = {};

productionData.forEach(entry => {
    if (entry.line === line) {
        let date = entry.timestamp.split(" ")[0];

        if (!groupedData[date]) {
            groupedData[date] = {
                totalShiftDuration: shiftDuration,
                totalGoodUnits: 0,
                totalProducedUnits: 0,
                totalDowntimeSeconds: 0,
                totalCycleTime: 0,
                cycleCount: 0,
                totalTargetOutput: 0,
                timestamp: entry.timestamp
            };
        }

        groupedData[date].totalGoodUnits += entry.good_units;
        groupedData[date].totalProducedUnits += entry.total_produced_units;
        groupedData[date].totalCycleTime += entry.cycle_time;
        groupedData[date].cycleCount++;
        groupedData[date].totalTargetOutput += entry.target_output;
    }
});

downtimeData.forEach(downtime => {
    if (downtime.line === line) {
        let date = downtime.timestamp.split(" ")[0];
        if (groupedData[date]) {
            groupedData[date].totalDowntimeSeconds += downtime.downtime_duration_minutes * 60;
        }
    }
});

let oeeResults = Object.entries(groupedData).map(([date, data]) => {
    let avgCycleTime = data.cycleCount > 0 ? data.totalCycleTime / data.cycleCount : 0;
    let availableTime = data.totalShiftDuration - data.totalDowntimeSeconds;
    let availability = availableTime / data.totalShiftDuration;
    let performance = data.totalTargetOutput > 0 ? data.totalProducedUnits / data.totalTargetOutput : 0;
    let quality = data.totalProducedUnits > 0 ? data.totalGoodUnits / data.totalProducedUnits : 0;
    let oee = (availability * performance * quality * 100).toFixed(2);

    return { date, availability, performance, quality, oee, timestamp: data.timestamp };
});

// Sort data by timestamp (oldest to most recent)
oeeResults.sort((a, b) => new Date(a.timestamp).valueOf() - new Date(b.timestamp).valueOf());
msg.payload = oeeResults;
return msg;
```

4. Drag the **Change node** onto the canvas and set `msg.payload` to `msg.oeeTrend`.
5. Drag the **Link Out node** onto the canvas and connect it to the **Change node**.
6. Connect this **Link Out node** to the **Link In node** that was added earlier to receive all the calculated metrics for visualization.

![Flows that calculate the OEE for each day over the last 30 days](https://flowfuse.com/blog/2025/04/images/oee-trend.png){dataZoomable=""}&#x2A;Flows that calculate the OEE for each day over the last 30 days.*

### Building the OEE Dashboard

Now that the key OEE metrics have been calculated and detailed insights into production performance have been gathered, it is time to bring everything together in a visually intuitive and interactive dashboard. The OEE dashboard will provide real-time visibility into availability, performance, and quality while also displaying recent downtime events, downtime summaries, underperforming machines, and historical OEE trends.

Using FlowFuse Dashboard (Node-RED Dashboard 2.0), a clean and efficient interface will be designed, allowing operators and decision-makers to monitor production efficiency at a glance. If you have not built a dashboard with it before, [Getting Started with Dashboard 2.0](https://flowfuse.com/blog/2024/03/dashboard-getting-started/) covers the basics, and the [comprehensive guide to layout, sidebar, and styling](https://flowfuse.com/blog/2024/05/node-red-dashboard-2-layout-navigation-styling/) explains the grouping and page concepts used throughout this section.

1. Drag a Switch node onto the canvas, set the property to `msg.oee`, and add the condition:
   - "Is not null".
2. Connect it to the Link-In node that receives calculated metrics.
3. Drag a Change node, set `msg.oee` to `msg.payload`, and connect it to a Gauge widget.
   - Create a new Group on a new page named **Line-1**.
   - Set the page layout to **Grid**, adjust the range from **0 to 100**, and label the gauge **OEE**.
   - Choose **Half Gauge** as the type, set the style to **Rounded**, and adjust the width and height to **6** and **3** for both the group and the widget.
4. Repeat these steps for `msg.quality`, `msg.availability`, and `msg.performance`, ensuring each has a separate Group with the correct label.
5. Drag a Switch node for `msg.productionData` and connect it to a Change node setting `msg.productionData` to `msg.payload`:
   - "Is not null".
6. Repeat this step for `msg.downtimeSummary`, `msg.recentDowntime`, `msg.topUnderPerformingMachines`, and `msg.oeeTrend`, ensuring each has a separate Switch node and Change node.
7. Drag a Bar Chart widget, create a new Group, set the width to **6** and height to **8** for both the group and widget, label it **Production Data**, group data by **Stacks**, and map **X to series** and **Y to units**. Connect it to the node setting `msg.productionData`.
8. Duplicate the chart for **Downtime Summary**, mapping **X to downtime\_reason** and **Y to downtime\_duration\_minutes**, and connect it to the node setting `msg.downtimeSummary` to `msg.payload`.
9. Drag a Table widget, create a new Group, set width **6** and height **2** for both the group and widget, label it **Recent Downtime Events**, set max rows to **5**, and add columns with keys:
   - `machine_name`
   - `downtime_start`
   - `downtime_duration_minutes`
   - `downtime_reason`
10. Connect it to the node setting `msg.recent_downtime` to `msg.payload`.
11. Duplicate the table for **Top Underperforming Machines**, adding columns with keys:
    - `machine_name`
    - `area`
    - `oee`
12. Connect it to `msg.topUnderPerformingMachines`.
13. Drag a Line Chart widget, create a new Group, set width **12** and height **5** for both the group and widget, label it **Daily OEE Trend Over 24 Hours**, set X-axis to **Timescale**, format **Y-l-d**, and map &#x2A;*X to `date`** and &#x2A;*Y to `oee`**. Connect it to the Change node setting `msg.oeeTrend` to `msg.payload`.
14. Click **Deploy**.
15. Open the dashboard by clicking the Dashboard 2.0 button located at the top-right corner of the Dashboard 2.0 sidebar.

![OEE Dashboard UI flow](https://flowfuse.com/blog/2025/04/images/oee-dashboard.png){dataZoomable=""}*OEE Dashboard UI flow*

Your OEE dashboard is now set up and ready to use. It will visualize key metrics, including OEE, quality, availability, performance, production data, downtime events, and machine performance trends.

![OEE Dashboard results without proper theming and styling](https://flowfuse.com/blog/2025/04/images/oee-dashboard-without-style.png){dataZoomable=""}&#x2A;OEE Dashboard results without proper theming and styling.*

![OEE Dashboard results without proper theming and styling](https://flowfuse.com/blog/2025/04/images/oee-dashboard-without-style-2.png){dataZoomable=""}*OEE Dashboard results without proper theming and styling*

However, the dashboard may not yet look exactly as it did in the previous design or intended layout. Some components may not align correctly with adjacent components in terms of width and height. Additionally, on different screens, you may notice layout inconsistencies, and the top header elements, such as the OEE Dashboard title and logo is missing.

Do not worry, in the next part of this series, we will style the dashboard to match the original design. Later, we will demonstrate how to connect it to a real data source, scale it across your production lines, and explain how you can use this dashboard to improve production efficiency.

## What Next?

In [Part 3, we design and scale the dashboard for factory screens](https://flowfuse.com/blog/2025/04/design-and-scale-oee-dashboard/): theming it for the shop floor, making the layout responsive, connecting it to a real data source, and scaling it across production lines. In the meantime, if you’re excited to quickly launch your OEE dashboard in your factory environment, don’t delay! [Register for a FlowFuse account](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now and initiate your journey with our new effective, ready-made [OEE Dashboard Blueprint](https://flowfuse.com/blueprints/manufacturing/oee-dashboard/).

Missed the start? [Part 1 explains what an OEE dashboard is and how to plan one](https://flowfuse.com/blog/2025/04/what-is-an-oee-dashboard/). And for the other views that belong on the shop floor alongside OEE, see our [manufacturing dashboard examples](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/).


# How to Design and Scale an OEE Dashboard for Factory Screens

In [Part 2 of this series](https://flowfuse.com/blog/2025/04/build-manufacturing-oee-dashboard/), we built the flow that calculates OEE for a production line from simulated production and downtime data, and put a dashboard interface on top of it. What we did not do was make it look like something you would hang on a factory wall.

This final part closes that gap. We will theme the dashboard, fix the layout so it holds up on tablets and smaller monitors, add branding to the header, scale it across multiple production lines with subflows, and finally swap the simulated data for your real database. We will finish with how to actually act on what the dashboard tells you.

If you have not worked through [Part 1](https://flowfuse.com/blog/2025/04/what-is-an-oee-dashboard/) and [Part 2](https://flowfuse.com/blog/2025/04/build-manufacturing-oee-dashboard/), start there - this article assumes you already have the flow from Part 2 deployed.

Let's get started!

## Enhancing the Dashboard Theme and Design

In the planning section of [Part 1](https://flowfuse.com/blog/2025/04/what-is-an-oee-dashboard/), we introduced a mockup of the dashboard with a modern dark theme. The theme was built around a sleek, professional aesthetic, using high-contrast colors for readability and a visually appealing layout.

The primary colors in the theme include:

- **Black (#000000)**, used for the page background to create contrast and reduce eye strain.
- **Charcoal Blue (#1A1C24)**, a deep, muted tone that adds depth while maintaining a clean and modern look, used for the groups.
- **White (#FFFFFF)**, used for text elements to ensure maximum readability against the dark background.
- **Accent Colors**, vibrant colors such as teal, orange, green, yellow, and blue are used across widget elements, including chart bars, line graphs, and indicators. These accents help differentiate data types and bring attention to key metrics.

But how do you come up with a dashboard design like this on your own? It starts with understanding why the theme matters. The design should reflect the context it is used in, the people interacting with it, and the mood it should convey. A dashboard on a factory floor may need to feel bold and focused, while one used by executives might aim for minimal and polished. A hospital system would need a tone that is calm, clean, and highly legible.

If you have a brand palette, that’s a great starting point. If not, choose colors that support the usability and tone of your dashboard. Our OEE dashboard, for instance, was designed for manufacturing teams who need to quickly read live data. The layout needed to be sharp, high-contrast, and low on visual noise, ideal for control rooms with limited lighting. The dark theme helps key data stand out while reducing eye strain over long periods of use.

### What to Consider When Designing a Factory Dashboard

A dashboard destined for the shop floor is not the same design problem as one viewed on a laptop, and a few constraints should shape every decision you make:

- **Design for the viewing distance.** A wall-mounted screen is read from three to ten meters away, often by someone walking past. The OEE number needs to be legible at that distance, which usually means it is far larger than feels comfortable in the editor. Size the type for the furthest reader, not for your monitor.
- **Give the screen one job.** Someone glancing up for two seconds should learn one thing: are we on target or not. Put the overall OEE score in the strongest visual position and let availability, performance, and quality sit a level below it. Everything else - machine breakdowns, downtime tables, trends - is for the person who has already stopped to investigate.
- **Use color to encode state, not to decorate.** Reserve green, amber, and red for whether a value is good, marginal, or bad, and use neutral tones for everything else. If every widget is colorful, nothing reads as urgent. Also check your palette against red-green color blindness, which affects roughly one in twelve men - pair color with position, shape, or a label so it is never the only signal.
- **Match the lighting.** A dark theme works well in a dim control room but can wash out under bright shop-floor lighting or direct sunlight, where a light, high-contrast theme reads better. Whichever you pick, hold a strong contrast ratio between text and background and avoid mid-grey on mid-grey.
- **Never make a wall display scroll or ask for input.** Nobody will scroll a screen mounted six feet up. If the content does not fit, split it across pages that rotate, or cut it. Same for anything requiring a click - an unattended display must be complete standing still.
- **Show the reader when the data is stale.** A frozen dashboard looks identical to a healthy one. A visible last-updated timestamp, or a status indicator that turns amber when data stops arriving, prevents decisions being made on yesterday's numbers.
- **Design for the person, not the metric.** An operator needs to know what to do right now; a supervisor needs the shift trend; a plant manager wants to compare lines. Trying to serve all three on one screen serves none of them. Build separate pages and route each audience to their own.

For a fuller tour of the theming and layout options available to you beyond what we use here, see our [comprehensive guide to FlowFuse Dashboard layout, sidebar, and styling](https://flowfuse.com/blog/2024/05/node-red-dashboard-2-layout-navigation-styling/).

### Modifying Theme

1. Open the Dashboard 2.0 sidebar from the Node-RED editor.
2. Switch to the Theme tab.
3. In the list of themes (you will likely see only the default one), click the settings (gear) icon next to it.
4. In the theme settings, click any colored rectangle to open the color picker. You can use the wheel or the dropper tool at the bottom to pick exact colors:

![Color tool for selecting colors for the theme](https://flowfuse.com/blog/2025/04/images/color-picking.png){dataZoomable=""}*Color tool for selecting colors for the theme*

- Set Charcoal Blue (#1A1C24) as the color for the header background, group background, and group outline.
- Set Black (#000000) as the page background.

5. Click **Update** and **Deploy Changes**.

Your dashboard should display the updated dark theme with a clean, modern appearance and improved visual contrast.

However, additional adjustments are needed to fully align the visuals, specifically the chart grid lines and label text colors.

### To update these:

1. Double-click on a chart widget to open its configuration panel.
2. Scroll to the bottom of the chart config UI.
3. Uncheck the following options:
   - Use ChartJs Default Text Colors
   - Use ChartJs Default Grid Colors
4. Set the text color to `#FFFFFF` (white) and the grid line color to `#606060`.
5. Click **Done**, then **Deploy the changes**.

These tweaks will ensure the charts match the dark theme and maintain good readability.

## Improving Layout Consistency Across Screen Sizes

When you open the same dashboard on different screen sizes, such as a mobile phone, tablet, or smaller desktop monitor, you might find the layout inconsistent or cramped. For example, widgets may overlap or appear too small.

![OEE Dashboard broken layout on smaller screen](https://flowfuse.com/blog/2025/04/images/oee-dashboard-breaked-layout.png){dataZoomable=""}*OEE Dashboard broken layout on smaller screen*

### To make the dashboard truly responsive:

1. Open the **Page Settings** in the Node-RED Dashboard editor.
2. Scroll down to locate the **Breakpoint Settings Table** for different device sizes.
3. Identify the **Tablet** row in the table.
4. Notice that the current Tablet column count is set to `9`.

Our OEE dashboard has:

- Four KPI widgets (OEE, Performance, Availability, Quality), each set to 3 columns wide.
- A total of 3 × 4 = 12 columns, which does not fit in the 9-column grid, so the layout breaks, and one widget drops to the next row.
- Other widgets like Production Summary and Downtime Events are each 6 columns wide, which leaves 3 columns of unused space in a 9-column layout.

5. To correct this, set the Tablet column count to `6` in the breakpoint table.

This change ensures:

- Two KPI widgets fit perfectly per row (3 + 3 = 6).
- Summary widgets span the full row (6/6), making the layout cleaner and more consistent on tablet devices.

6. Click Deploy the changes.

Even after adjusting the breakpoint settings, one more issue may appear: inconsistent heights between the *Top Underperforming Machines* and *Recent Downtime Events* sections, especially when one of the tables has fewer rows than the other.

![Inconsistent height of the widgets on OEE Dashboard](https://flowfuse.com/blog/2025/04/images/table-incosistency.png){dataZoomable=""}*Inconsistent height of the widgets on the OEE Dashboard*

This can make the dashboard layout uneven, with one card appearing much shorter.

To fix this visual imbalance, apply custom CSS:

1. Drag a **Template** widget onto your canvas.
2. Set its type to `CSS (all pages)`.
3. Paste the following CSS into the template:

```css
.nrdb-ui-group > .v-card {
    height: 100% !important;
}
```

4. Deploy the changes.

## Adding Header Elements: Logo and Dashboard Title

To give your OEE Dashboard a professional look, add branding elements such as a company logo and a clear dashboard title. These additions improve usability and help users instantly recognize the dashboard's purpose.

1. Drag **Template** widget onto the canvas.
2. Double click on it and add the following Vue code to it:

```html
<template>
   <!-- Teleport the title and logo to the #app-bar-actions area -->
   <Teleport to="#app-bar-title">
       <h3 style="color: white; margin-left: auto; margin-right: auto;">OEE Dashboard</h3>
   </Teleport>
   <Teleport to="#app-bar-actions">
       <div style="display: flex; align-items: center;">
           <img
               height="30px"
               src="/handbook/images/logos/ff-logo--wordmark--white.png"
               style="margin-right: 25px;"
           />
       </div>
   </Teleport>
</template>

<script>
   export default {
   data() {
       return {
           mounted: false
       };
   },
   mounted() {
       this.mounted = true;
   }
};
</script>
```

3. Update the `src` attribute in the `<img>` tag to your logo's path. If you are using FlowFuse, you can host your logo using the [static asset service](https://flowfuse.com/docs/user/static-asset-service/), which serves files directly from your instance so you do not have to depend on an external image host.
4. Click Deploy the changes.

We are using Vue’s Teleport feature to insert a custom dashboard title and logo into the top bar of the Dashboard 2.0 layout. For more information, please read our article: [Customise theming in your FlowFuse Dashboard](https://flowfuse.com/blog/2024/08/customise-theming-in-your-dashboards/).

The dashboard now looks clean, adapts well to all screen sizes, and maintains visual consistency across different UI elements. The header elements have also been enhanced to align with the overall design.

![OEE Dashboard with proper styling, theme](https://flowfuse.com/blog/2025/04/images/oee-dashboard-with-proper-styling.png){dataZoomable=""}*OEE Dashboard with proper styling, theme*

![OEE Dashboard with proper styling, theme](https://flowfuse.com/blog/2025/04/images/oee-dashboard-with-styling-2.png){dataZoomable=""}*OEE Dashboard with proper styling, theme*

![OEE Dashboard with proper styling, theme on smaller screen](https://flowfuse.com/blog/2025/04/images/oee-tablet.png){dataZoomable=""}*OEE Dashboard with proper styling, theme on smaller screen*

![OEE Dashboard with proper styling, theme on smaller screen](https://flowfuse.com/blog/2025/04/images/oee-dashboard-tablet.png){dataZoomable=""}*OEE Dashboard with proper styling, theme on smaller screen*

## Scaling the Dashboard for Multiple Production Lines

Currently, the dashboard is configured for a single production line. To support multiple lines, you must adjust your flows and dashboard structure to handle each line separately while keeping a consistent layout and theme.

The tool that makes this manageable is the subflow: one reusable definition, many instances, each configured through environment variables. If subflows are new to you, our guide on [how to create and use subflows](https://flowfuse.com/blog/2024/09/how-to-use-subflow-in-node-red/) covers the basics before you apply them here.

### Follow these steps:

1. Select the dashboard flow that handles your current production line. Include all relevant change nodes that set values like `msg.quality`, `msg.performance`, etc., to `msg.payload`.
2. From the main menu, hover over **Subflows** and click **Create Subflow**.
3. Inside the subflow:
   - Add an **Input** node, and connect it to all the change nodes you included from the original flow.
   - Reconnect any **Link In** node (that was previously wired to the change nodes) to the input of the newly created subflow.
4. Open the **subflow properties**, and define environment variables to represent widget groups. In the dashboard widgets inside the subflow, reference these variables instead of hardcoding group names.
5. Click **Deploy** to apply the changes.

This modular approach simplifies scaling and reduces manual work when adding new production lines to the dashboard.

### To reuse it for another production line:

1. Copy the entire OEE dashboard flow.
2. Create a new tab.
3. Paste the copied flow into the new tab.
4. Rename the tab to match the new production line.
5. Create a new dashboard page with the same configuration but a different name and path.
6. Open the subflow by double-clicking on it and add a new group for dashboard widgets.
7. Go to the configuration flow, and update the line's name to match the new production line.
8. Adjust both shift duration values to reflect the new line’s schedule.
9. Click **Deploy**.

Once deployed, you will have a separate page ready for your new production line. You can create as many pages as needed to monitor multiple production lines.

## Connecting Your Real Data Source

Now that you have built a complete OEE dashboard using simulated factory data and learned how to reuse it for all your production lines, the next step is to connect it to your real factory environment.

To make the dashboard truly useful in a live setting, you must understand how to integrate it with your data sources. Most commonly, the OEE dashboard relies on static or retained data, such as values stored in a database. First, determine whether your factory uses a relational database like MySQL or PostgreSQL, a NoSQL database like MongoDB, or a time-series database like InfluxDB.

### Then:

1. Use the **Palette Manager** in Node-RED to install the corresponding contrib node for your selected database.
2. Replace the existing `sqlite` nodes in your flow with the nodes for the database you are using.
3. If using SQL based database, queries may remain unchanged. For NoSQL or time-series DBs, rewrite the queries as needed.

For help, refer to our [Database](https://flowfuse.com/node-red/database/) section, which includes guides for MongoDB, PostgreSQL, InfluxDB, TimescaleDB, and DynamoDB. If you do not already have a database to point at, [FlowFuse Tables](https://flowfuse.com/docs/user/ff-tables/) gives you a managed PostgreSQL instance inside the platform - we walk through that pattern end to end in [Building a historical data dashboard with FlowFuse Tables](https://flowfuse.com/blog/2025/08/time-series-dashboard-flowfuse-postgresql/).

When connecting to your real data source, you may notice that the field names used in your database differ from those used in the our oee dashboard sqlite node queries. While this seems like a lot of manual work, the dashboard is designed with flexibility in mind. You only need to make two changes to adapt the queries to your schema.

### To match your schema:

1. Open each database node and update the query to reflect your field names.
   - Do **not** change the alias names, they are used throughout the dashboard.
2. Replace table names with those used in your actual database.
3. Do **not** change the dynamic parameters like `$startTime`, `$endTime`, and `$line`.

Example query:

```sql
SELECT
   timestamp as timestamp,
   machine_name as machine_name,
   area as area,
   line as line,
   total_produced_units as total_produced_units,
   good_units as good_units,
   defect_units as defect_units,
   target_output as target_output
FROM ProductionData
WHERE
   timestamp BETWEEN $startTime AND $endTime AND line = $line;
```

Suppose your database uses different field names, such as time instead of timestamp, machine instead of machine\_name, section instead of area, production\_line instead of line, produced\_units instead of total\_produced\_units, quality\_units instead of good\_units, faulty\_units instead of defect\_units, or planned\_output instead of target\_output. In that case, you should update the query accordingly. After modification, it should look like this:

```sql
SELECT
    time AS timestamp,
    machine AS machine_name,
    section AS area,
    production_line AS line,
    produced_units AS total_produced_units,
    quality_units AS good_units,
    faulty_units AS defect_units,
    planned_output AS target_output
FROM YourTableName 
WHERE 
    time BETWEEN $startTime AND $endTime AND production_line = $line;
```

## How to Use Your OEE Dashboard

Your OEE dashboard is live. It updates in real-time and shows key metrics. But what should you do with the information?

The dashboard is not just for display, it is there to help you take action. When OEE drops, do not stop at the number. Dig into the cause by checking the three main metrics: availability, performance, and quality.

- If availability is low, check for unplanned stops, long changeovers, or idle machines. A [machine downtime tracking application](https://flowfuse.com/blog/2026/07/build-downtime-logger/) is the natural next build, and [automating downtime detection and escalation](https://flowfuse.com/blog/2026/06/event-driven-downtime-escalation-workflow/) stops those stops from going unlogged in the first place.
- If performance is down, the line may run slower than expected.
- If quality has dropped, you may produce more rejects or rework. A [defect tracking and quality monitoring dashboard](https://flowfuse.com/blog/2026/07/defect-and-quality-monitoring/) gives you the detail this view cannot.

One caution before you start making decisions from this screen: OEE is easy to compute in a way that flatters the plant. [OEE is misleading your factory: here's how to fix it](https://flowfuse.com/blog/2026/05/fixing-oee-measurement-in-manufacturing/) walks through the measurement mistakes that inflate the number, and [TEEP](https://flowfuse.com/blog/2025/12/what-is-teep/) is the companion metric that exposes capacity your OEE score hides.

Say your OEE drops from 82% to 65%, and performance is the problem. Start by checking how many good parts were produced. Look at reject counts, more bad parts affect both quality and output. Then, check downtime logs and machine performance. One or two machines are often behind the drop, maybe they had repeated issues or ran slowly after a setup.

Use the 30-day trend graph to spot patterns over time. A sudden drop might show a specific issue, while a slow decline could signal a more significant process problem. Trends can also help you confirm if recent changes are making a real difference.
Finally, share what you find. Use the dashboard during team reviews or shift handovers to keep everyone focused on what needs fixing. An OEE dashboard's real value is how you respond to it.

## Conclusion

This final part completes our series on building a real-time OEE dashboard with FlowFuse. You now have a fully functional, visually refined, and scalable dashboard that connects to live production data, adapts to multiple lines, and reflects your plant’s branding and layout requirements.

By the end of this journey, you have built a dashboard and created a foundation for continuous improvement in your manufacturing environment using open-source, low-code tools.
We hope this series helped you understand how FlowFuse and Node-RED can quickly prototype and deploy powerful industrial applications. Thank you for following along!

If you have not built your OEE dashboard yet, or you got stuck somewhere along the way, you can skip ahead: [sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and start from our ready-made [OEE Dashboard Blueprint](https://flowfuse.com/blueprints/manufacturing/oee-dashboard/) instead of building the flow from scratch.

And if you are working out what else belongs on the floor alongside OEE, our [manufacturing dashboard examples](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/) cover production, downtime, quality, and calibration views built the same way.

If you landed here first, [Part 1 explains what an OEE dashboard is and how to plan one](https://flowfuse.com/blog/2025/04/what-is-an-oee-dashboard/) and [Part 2 builds the flow behind it](https://flowfuse.com/blog/2025/04/build-manufacturing-oee-dashboard/).


# FlowFuse 2.16: Git Integration, improved log retention and more

Another release from the FlowFuse team to keep [realising our mission](https://flowfuse.com/handbook/company/strategy/) to empower you to fuse the digital realm and physical reality.

## Git Integration

![Screenshot of a Git Pipeline Stage](https://flowfuse.com/blog/2025/04/images/git-pipeline-stage.png){dataZoomable=""}*Screenshot of a Git Pipeline Stage*

This has been one of those features that has come up a number of times with our users; we knew we wanted to have Git integration in the platform, but we also wanted it to fit in a natural way with the developer workflows we provide.

With this release, you can now add a Git Repository stage to your deployment pipelines. When the pipeline is triggered, the latest snapshot will get pushed to the configured repository.

This is very much a "first-iteration" of the feature that will allow us to get feedback early and continue to iterate.

With this release, the following restrictions apply:

- Only GitHub.com hosted repostories are supported
- Users must create a GitHub Personal Access Token and add to their Team Settings
- We currently only support pushing snapshots to a Git repository

This last point is important; this release lets you backup your flows to git, but we haven't yet enabled the return journey of pulling a snapshot from a Git repository back to your Node-RED instance. That'll come in the near future and will unlock a full git-based review workflow within the pipelines.

We'll also look at enabling other Git hosting providers - let us know which you'd like to see on the list.

This feature is available to Enterprise teams on FlowFuse Cloud and self-hosted customers.

## Better Node-RED log handling

We've improved the log handling within our Hosted Node-RED instances. Previously we were using a fix sized buffer in memory; meaning the noisier your Node-RED instance was, the less history you'd have. The UI for browsing the logs was also awkward when you wanted to jump back to an earlier section of the logs.

With this release, once you update your instances to the latest version, we will
now store the last 7 days worth of logs for each hosted Node-RED instance.

To go along side this, we've added the ability to jump to a specific time/date in the logs without having to endlessly scroll.

To start benefiting from the extended logs, make sure you update the latest version via your Instance Settings page.

![Screenshot of browsing Node-RED logs by timestamp](https://flowfuse.com/blog/2025/04/images/browse-logs.png){dataZoomable=""}*Screenshot of browsing Node-RED logs by timestamp*

## Remote Instance Provisioning

We've updated the provisioning token support to allow you to automatically assign your remote instances to an application within your team.

The option to assign to a hosted instance is still there, but being able to assign to the appilcation is more generally useful for most workflows on the platform.

Details available in the [changelog](https://flowfuse.com/changelog/2025/04/device-provisioning/).

## Local Login for Remote Instances

One of the great features of our Remote Instance management is that we enable secure remote access to the Node-RED editor through the platform. To date, this approach has meant we disable direct local access to the editor.

With the most recent Device Agent release, we've added the ability to configure a local user login for the editor. This can be used when the remote instance is not able to reach the FlowFuse platform.

We're keen for feedback on this and will continue to explore otherwise to provide secure local access to the remote instance.

## Resource Alerts

We expanded the notficiations we send to help you track the health of your Node-RED instances. We will now send notifications if the CPU and/or memory usages exceeds 75% of the available capacity for a prolonged time.

You can further opt-in or out of these notifications via the instance settings.

Details available in the [changelog](https://flowfuse.com/changelog/2025/03/resource-notifications/)

## Changes to tags for `flowfuse/node-red` containers

For kubernetes and docker environments, we've updated the base container our `latest` tag points at to ensure
it defaults to the latest Node.js and Node-RED versions.

Check the [changelog](https://flowfuse.com/changelog/2025/03/container-tags/) entry for full details

## What Else Is New?

For a full list of everything that went into our 2.16 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.16.0){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try FlowFuse

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is on our own hosted instance, FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.


# What Is an OEE Dashboard? KPIs, Metrics, and How to Plan One

OEE (Overall Equipment Effectiveness) is a KPI used in manufacturing to measure equipment performance based on availability, efficiency, and quality.

To effectively track this KPI, an OEE dashboard is built, but creating one can be complex, especially when consolidating data from various sources, with limited flexibility to integrate data across different systems. Additionally, building a customizable dashboard to suit specific needs adds another layer of complexity.

With FlowFuse, it's possible to build a customized, OEE Dashboard, without writing any code, that can provide real-time production data based on your needs.

In this first part of a three-part series on building an OEE dashboard with FlowFuse, we explain the concept of OEE, how it is calculated, and outline the basic plan for the dashboard. In that plan, we cover the scope of OEE calculation, key metrics, visualization strategies, and the expected design of the dashboard.

Let’s get started!

## What is OEE?

Overall Equipment Effectiveness (OEE) is a crucial metric in manufacturing that assesses the productivity of equipment through three key components. These components evaluate the efficiency of equipment during the production process:

- **Availability:** How often does the equipment perform when needed?
- **Performance:** How much product does the equipment produce?
- **Production Quality:** How many high-quality products does the equipment produce?

The concept of OEE was introduced by Seiichi Nakajima in the 1960s as part of the [Total Productive Maintenance (TPM)](https://en.wikipedia.org/wiki/Total_productive_maintenance){rel="&#x22;nofollow&#x22;"} initiative in Japan. Nakajima, an engineer at the Japan Institute of Plant Maintenance (JIPM), developed OEE to measure and enhance manufacturing productivity by identifying inefficiencies. This metric has since become widely adopted across the manufacturing industry. Today, OEE remains one of the most critical KPIs, with a really huge number of manufacturers considering it either important or very important for improving production efficiency and minimizing waste.

Measuring and improving OEE allows you to improve the utilization of existing machinery and improves operational efficiency. In many cases, improving OEE is the most strategic and cost-effective approach to increasing output.

Two caveats worth knowing before you build a dashboard around this number. First, OEE is easy to calculate in a way that flatters the plant - [OEE is misleading your factory: here's how to fix it](https://flowfuse.com/blog/2026/05/fixing-oee-measurement-in-manufacturing/) covers the common measurement mistakes. Second, OEE only judges equipment during *scheduled* production time; [TEEP](https://flowfuse.com/blog/2025/12/what-is-teep/) is the companion metric that accounts for the hours your assets sit idle by choice.

For a launch or capacity-approval event, a [run at rate](https://flowfuse.com/blog/2026/08/run-at-rate/) is the separate test that verifies the line can hold its required output with production tooling and staffing.

## How is OEE calculated?

OEE is calculated using the formula:

***OEE (%) = Availability × Performance × Quality***

Where:

- ***Availability (%) = (Operating Time ÷ Planned Production Time) × 100***
- ***Performance (%) = (Actual Output ÷ Maximum Possible Output) × 100***
- ***Quality (%) = (Good Products ÷ Total Products) × 100***

For example, if a machine is available 90% of the time, runs at 95% of its ideal speed, and 98% of products are defect-free, your OEE would be: 0.90 × 0.95 × 0.98 = 83.7%

## Planning Your OEE Dashboard

Now that we’ve covered what OEE is, let's focus on designing a basic plan that details what are the things that we should display on our dashboard. This should consist of three parts:

- **Scope of the Calculation:** How much data will be collected and analyzed?
- **Key Metrics:** Which metrics are the most important to track?
- **Layout & Visualisation:** What visual elements will be used to present the data?

### Defining the Scope of OEE Calculation

The first and most important step before creating the dashboard is defining the scope of the OEE calculation. The tracking level can vary based on the focus on area. Scope can vary between:

- **Machine-level OEE:** Concentrates on individual machines, aiding in the identification of specific inefficiencies that impact performance.
- **Line-level OEE:** Assesses the entire production line, offering insights into the collaboration of multiple machines and pinpointing where bottlenecks arise.
- **Factory-level OEE:** Compiles data from various production lines to provide a comprehensive overview of overall efficiency and trends.

For those building dashboards from scratch, it’s advisable to start at the machine level. This approach allows for faster time to value, as data collection can typically begin from a single point, reducing initial complexity. Once you’ve established the machine-level tracking and identified the inefficiencies, you can scale up to line-level and eventually factory-level OEE. Starting with machine-level data ensures that you can quickly uncover key insights and iteratively improve the scope and detail of your dashboard.

For this series, we will be building the dashboard at the line-level. In this case, we will collect data specific to a production line and perform the OEE calculation based on that data.

### Key Metrics and Insights

As mentioned earlier, the dashboard will calculate OEE for a production line, presenting key metrics such as availability, performance, quality, and the overall OEE score. While the overall OEE score provides a quick snapshot of performance, it does not offer enough detail to pinpoint specific areas that need improvement.

To address this, the dashboard will break down the OEE calculation at the machine level as well, enabling managers to identify underperforming machines that affect overall efficiency. Additionally, it will display recent downtime incidents, summarizing this data to uncover trends and identify potential root causes. This breakdown will provide a clearer understanding of where inefficiencies are occurring and allow for targeted corrective actions. The dashboard only displays downtime events, so something has to record them first. If you do not already capture stoppages with a reason attached, our [machine downtime logger](https://flowfuse.com/blog/2026/07/build-downtime-logger/) covers building that: catching stop and start signals over MQTT and letting operators log why the line stopped.

The dashboard will also track production quality, displaying the number of acceptable versus defective parts to ensure a continued focus on quality control. Additionally, last 30-days OEE trend analysis will be included, offering insights into performance changes over time. This will help managers identify patterns, monitor improvements, and highlight areas requiring attention.

### Dashboard Visualization & UI Design

To ensure that insights are easy to understand and act upon, the dashboard will feature a well-structured visual layout that presents complex data in a clear and intuitive manner. After analyzing various OEE dashboards, I designed this one with a focus on clarity, usability, and actionable insights. It will include gauges for a quick OEE overview, bar charts to track downtime and production trends, tables to highlight underperforming machines and recent downtime events, and line charts to monitor efficiency patterns over time. This setup ensures managers can quickly spot problems, understand their causes, and take the necessary steps to optimize production.

The following dashboard image illustrates the intended design and key objectives of our OEE dashboard. Based on the plan outlined in this part, we will build the dashboard interface in the next part of the series using simulated production and downtime data.

Later, we will show how to connect real factory data, scale the dashboard across multiple production lines, and use it to enhance OEE effectively.

![OEE Dashboard](https://flowfuse.com/blog/2025/04/images/oee-dashboard-1.png){dataZoomable=""}*OEE Dashboard*

![OEE Dashboard](https://flowfuse.com/blog/2025/04/images/oee-dashboard-2.png){dataZoomable=""}*OEE Dashboard*

## What Next

With the plan settled, [Part 2 builds the manufacturing OEE dashboard](https://flowfuse.com/blog/2025/04/build-manufacturing-oee-dashboard/): collecting the data, running the calculations, and assembling the widgets. [Part 3 then designs and scales it for factory screens](https://flowfuse.com/blog/2025/04/design-and-scale-oee-dashboard/) - theming, responsive layout, multiple production lines, and your real database.

If you would rather skip the tutorials and dive straight in, [register for a FlowFuse account](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and start from our ready-made [OEE Dashboard Blueprint](https://flowfuse.com/blueprints/manufacturing/oee-dashboard/).

For a wider view of what else belongs on the shop floor, see our [manufacturing dashboard examples](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/).


# Part 1: Building an Andon Task Manager with FlowFuse

In modern manufacturing and service environments, speed and transparency are critical for addressing issues as they arise. An Andon system helps achieve this by enabling frontline workers to signal problems in real time, triggering quick responses from support teams.

However, many manufacturers struggle to find a solution that truly fits their needs. Some tools lack essential features, while others are overloaded with unnecessary ones that add complexity.

This blog series introduces a practical approach to building a real-time Andon Task Manager using FlowFuse and Node-RED. In this first part, the focus is on understanding the concept of an Andon system and laying the foundation for the solution.

## What is the Andon Task Manager?

The Andon Task Manager is a digital system designed to streamline real-time issue reporting, escalation, and resolution tracking. Inspired by the traditional Andon systems used in lean manufacturing, it brings these concepts into a modern, cloud-enabled environment.

At its core, it’s a communication and response tool designed to improve transparency and speed on the factory floor or within service teams. Frontline workers can quickly raise issues, like equipment breakdowns, material shortages, or support needs, which are immediately sent to the right person or team. Once the issue is resolved, the responder updates the status so everyone stays informed and the task is properly closed.

## What Problem It Solves?

In a typical manufacturing environment, multiple processes run simultaneously across large factory floors. Each area, or line, has specific machinery, workflows, and potential points of failure. When something goes wrong, quick and clear communication is essential. However, factories are often spread out, and support teams are divided across different departments (e.g., maintenance, quality control, safety, etc.).

In many cases, workers rely on informal or manual systems, such as radio calls, phone messages, or shouting across the floor, to report issues. These methods are inefficient, error-prone, and often delay response times. The lack of a structured, real-time communication system leads to:

- Delayed responses because support staff are unaware of new issues
- Lack of visibility into the status of reported issues
  \= No accountability for weather the issue is acknowledged/resolved or not
- Unstructured logging that makes follow-up or audits difficult

The Andon Task Manager solves this by acting as a centralized system where any frontline worker can quickly raise an issue. Once submitted, the request is instantly visible to the relevant department, without needing someone to manually assign it. This enables self-routing and real-time visibility, ensuring the right people take action quickly and efficiently, even when the requester and responder are in completely different parts of the factory.

## Planning the Andon Task Manager

At the core of the system is the concept of a request. Every request represents a task or issue raised by an operator. To ensure traceability and clarity, each request should include key details. This structured format makes it easier for departments to manage and resolve issues efficiently.

Each request must include the following:

- `id`: A unique identifier for the request.
- `line`: The line or machine where the issue was raised.
- `department`: The department responsible for resolving the issue.
- `created`: The timestamp when the request was created.
- `acknowledged`: Timestamp indicating when the request was acknowledged.
- `resolved`: Timestamp indicating when the issue was resolved.
- `note`: Text added by users for context or follow-up.
  Only predefined values for line and department should be allowed. These values will be managed through admin settings to ensure consistency across the system.

### Defining Key Features

The system needs to support core operations that reflect how issues are reported and resolved in real-life factory environments. These features help ensure that tasks are handled efficiently and that everyone involved knows the current status.

The essential features include:

- Request creation: Users select the line and department, enter a note, and submit a request.
- Acknowledge requests: A responder can mark a request as acknowledged once they start working on it.
- Resolve requests: After resolving the issue, the responder marks it as resolved.
- View filtering: Requests can be filtered by line or department.
- Admin tools: Admins can add and manage the list of departments and lines.
- Status display: Requests display their current state, pending, acknowledged, or resolved.
- Alerts: Visual or sound alerts for unacknowledged requests after a time threshold.

Each of these actions will be timestamped to provide a clear history of who did what and when.

### Dashboard Visualization & UI Design

The next step after defining the core features is to design an intuitive and efficient dashboard for both frontline workers and admin users. A well-organized interface ensures quick interactions and smooth navigation, especially in settings where timely responses are crucial.

The system will support two user roles: admins and regular users. Regular users will have access to features such as submitting requests, viewing requests by department or line, and managing tasks within their area (e.g., acknowledging and resolving requests). Admins will have additional capabilities, including creating and managing departments and lines, and accessing all request data.

The regular user's view will be a single-page interface with dynamic content updates. Rather than traditional page navigation, content will update based on the user’s selection of a department or line. For example, when a user selects a production line, the request list and relevant controls will automatically update to display only the requests related to that line.

The admin view will have a dedicated view, including a form for creating new lines or departments and a table displaying all requests. This view will also feature a menu for quickly switching between specific department or line section, improving system management efficiency.

This design keeps the interface focused and responsive. It avoids unnecessary complexity while providing all necessary tools for users to perform their tasks efficiently, whether they are reporting an issue or managing overall operations.

![The following dashboard image illustrates the intended design and key objectives of our Andon Task Manager.](https://flowfuse.com/blog/2025/05/images/dashboard-admin-veiw.png){dataZoomable=""}&#x2A;The following dashboard image illustrates the intended design and key objectives of our Andon Task Manager.*

![The following dashboard image illustrates the intended design and key objectives of our Andon Task Manager.](https://flowfuse.com/blog/2025/05/images/line-menu.png){dataZoomable=""}&#x2A;The following dashboard image illustrates the intended design and key objectives of our Andon Task Manager.*

![The following dashboard image illustrates the intended design and key objectives of our Andon Task Manager.](https://flowfuse.com/blog/2025/05/images/line-page.png){dataZoomable=""}&#x2A;The following dashboard image illustrates the intended design and key objectives of our Andon Task Manager.*

![The following dashboard image illustrates the intended design and key objectives of our Andon Task Manager.](https://flowfuse.com/blog/2025/05/images/department-menu.png){dataZoomable=""}&#x2A;The following dashboard image illustrates the intended design and key objectives of our Andon Task Manager.*

![The following dashboard image illustrates the intended design and key objectives of our Andon Task Manager.](https://flowfuse.com/blog/2025/05/images/department-wise.png){dataZoomable=""}&#x2A;The following dashboard image illustrates the intended design and key objectives of our Andon Task Manager.*

### Storage Mechanism

To ensure a simple and efficient data management system for the Andon Task Manager, we will use SQLite to store user requests. SQLite is a lightweight, easy-to-manage database that is well-supported in Node-RED through the `node-red-contrib-sqlite node`. This makes it an ideal choice for local deployments or scenarios where a lightweight database is needed.

For dynamic runtime data, such as the user's selected line or department, as well as the full list of available lines and departments, FlowFuse’s built-in [context storage](https://flowfuse.com/docs/user/persistent-context/) will be utilized. This solution allows for fast access to real-time data while maintaining persistent state across sessions, without introducing unnecessary database complexity or overhead.

By using both SQLite for structured request data and context storage for dynamic, session-based information, the system remains efficient and easy to maintain.

## Up Next

In the next part of this series, we will focus on developing the Lines view for regular users, along with the navigation menu for switching between different line sections. Later, we will cover the development of the lines view and Admin interface.

But if you can't wait to get started right away, don’t worry! You can [register](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} for FlowFuse and get started with our ready-made [Andon Task Manager blueprint](https://flowfuse.com/blueprints/manufacturing/andon-system/), which is pre-configured for easy deployment. Stay tuned for the next installment to continue your journey toward building a comprehensive, real-time Andon Task Manager solution.


# Building a Flexible Node-RED Scheduler with Cron-Plus

Automation isn’t just about reacting to events, sometimes it’s about doing things at the right time. In Node-RED, the Inject node is great for triggering flows at set intervals, but it’s limited when you need more control. Cron jobs offer precise scheduling, letting you set up custom times for your tasks. In this guide, we'll show you how to create flexible cron schedules in FlowFuse with Node-RED, so your flows run exactly when needed.

## What is a Cron Job?

Let’s kick things off by demystifying what a cron job actually is. You’ve probably heard the term before, and while it might sound complex, it’s really just a way of setting up tasks to run at specific times, automatically.

Think of it this way: with Node-RED’s Inject node, you can trigger tasks at intervals like every 5 seconds, every minute, or even on specific weekdays at set times (for example, every Monday, Tuesday, or Sunday). But when you use cron jobs, you gain much more control over the timing.

For example, you can trigger a task every two hours, only on weekdays, but skip holidays or run a job every 5 minutes during business hours, but only in the first week of each quarter. You can even schedule flows to run at 6:45 AM on the last Friday of every month, or at 11:59 PM on the last day of the year, these kinds of patterns are either extremely complex or completely unachievable using just the Inject node.

The magic of cron lies in its ability to express complex time logic in a simple, compact format, perfect for orchestrating automation schedules that go well beyond what the basic Inject node can offer.

## Prerequisites

Before we start building flexible cron schedules in FlowFuse, make sure you have the following in place:

- **Running FlowFuse Instance:** Make sure you have a FlowFuse instance set up and running. If you don't have an account, check out our [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and learn how to create an instance in FlowFuse.
- **node-red-contrib-cron-plus:** Ensure you have [node-red-contrib-cron-plus](https://flows.nodered.org/node/node-red-contrib-cron-plus){rel="&#x22;nofollow&#x22;"} installed, It’s developed by Steve, a software engineer here at FlowFuse and one of the core maintainers of Node-RED.

## Building Scheduled Automations with cron-plus

Now that you understand what cron jobs are and why they’re useful, let’s dive into building them inside Node-RED using the cron-plus node. When working with cron-plus, you’ll encounter different types of schedules, each suited for different needs, and varying levels of complexity depending on what you're trying to automate.

At the most basic level, you can define static schedules using familiar cron expressions (like "every 5 minutes" or "at 8:00 AM daily"). As you progress, you’ll learn to use solar event triggers (like sunrise or sunset), create date-specific schedules, and even manage schedules dynamically at runtime, adding, removing, or modifying them based on incoming data or user interactions.

In this section, we’ll walk through each of these layers step by step, starting with the simplest use cases and gradually moving into more powerful and flexible scheduling techniques, giving you full control over when and how your flows run.

> Tip: This article draws information from the node’s [README](https://flows.nodered.org/node/node-red-contrib-cron-plus){rel="&#x22;nofollow&#x22;"}, which is highly informative. I recommend going through it as well for more details.

### Static Schedules

The most straightforward way to use cron-plus is to define static schedules using cron expressions. These are pre-configured inside the node and run on a fixed pattern, perfect for predictable, repetitive tasks. For example we need to Trigger a flow every day at 8:00 AM.

1. Drag and drop the cron-plus node onto your Node-RED workspace.
2. Double-click on the cron-plus node to open its configuration panel.
3. If no schedules are configured yet, click the +add button to add a new schedule. Enter the following:
   - Schedule Name: e.g., "Daily 8 AM"
   - Topic: Enter a topic to send with the message when triggered, such as "daily-trigger".
   - Payload: Choose what payload you want to send when the cron job triggers, such as "Triggering Flow at 8 AM".
4. Select Cron from the Schedule Type dropdown.
5. In the Schedule field, enter the following cron expression to run the task at 8:00 AM every day:

```text
   0 8 * * *
```

A cron expression is composed of five fields (sometimes six or seven, depending on the system) that determine the schedule for executing tasks.
Below is a breakdown of each field that node-red-contrib-cron-plus supports:

| Field             | Possible Values     | Special Symbols |
| ----------------- | ------------------- | --------------- |
| Second (optional) | `0-59`              | `* / , -`       |
| Minute            | `0-59`              | `* / , -`       |
| Hour              | `0-23`              | `* / , -`       |
| Day of Month      | `1-31`              | `* / , - ? L W` |
| Month             | `1-12` or `JAN-DEC` | `* / , -`       |
| Day of Week       | `0-6` or `SUN-SAT`  | `* / , - ? L #` |
| Year (optional)   | `1970-2099`         | `* / , -`       |

Here are some examples of how you can use the special symbols and shorthand's:

| Symbol | Meaning                  | Example             | Explanation                                                 |
| ------ | ------------------------ | ------------------- | ----------------------------------------------------------- |
| `*`    | All possible values      | `* * * * *`         | Every minute of every hour, day, month, and weekday         |
| `?`    | No specific value        | `0 0 12 ? * MON`    | At 12 PM Only on Mondays (no specific day of the month)     |
| `-`    | Range                    | `0 10-12 * * * *`   | Minutes 10, 11, and 12 of every hour                        |
| `,`    | List of values           | `0 0 12 * 1,3,5 *`  | At 12 PM only in January, March, and May                    |
| `/`    | Step values              | `*/15 * * * *`      | Every 15 minutes (00, 15, 30, 45)                           |
| `L`    | Last                     | `0 0 12 L * *`      | 12 PM on the last day of the month                          |
| `W`    | Nearest weekday          | `0 0 0 15W * * *`   | At midnight on the nearest weekday to the 15th of the month |
| `#`    | nth weekday of the month | `0 0 0 * * MON#1 *` | At midnight on the first Monday of the month                |

6. Connect the cron-plus node to other nodes (e.g., a debug node or an action node) to specify the actions when the flow is triggered.
7. Click Deploy to save and activate your flow. The cron-plus node will now trigger your flow every day at 8:00 AM.

::render-flow
```json
[{"id":"cba15bd32c5434a5","type":"group","z":"b37428694e90b2c5","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["2af2e9274fe1321a","458c9533a1437ee1"],"x":94,"y":179,"w":392,"h":82},{"id":"2af2e9274fe1321a","type":"debug","z":"b37428694e90b2c5","g":"cba15bd32c5434a5","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":380,"y":220,"wires":[]},{"id":"458c9533a1437ee1","type":"cronplus","z":"b37428694e90b2c5","g":"cba15bd32c5434a5","name":"Cron Plus","outputField":"payload","timeZone":"","storeName":"","commandResponseMsgOutput":"output1","defaultLocation":"","defaultLocationType":"default","outputs":1,"options":[{"name":"Daily 8 AM","topic":"daily-trigger","payloadType":"default","payload":"","expressionType":"cron","expression":" 0 8 * * *","location":"","offset":"0","solarType":"all","solarEvents":"sunrise,sunset"}],"x":200,"y":220,"wires":[["2af2e9274fe1321a"]]}]
```
::

Here are some advance patterns:

**Every weekday at 9:30 AM**

```text
30 9 * * 1-5
```

**Every hour**

```text
0 * * * *
```

**Every 15 min during work hours (Mon–Fri, 9–5)**

```text
*/15 9-16 * * 1-5
```

**First Monday of the month at 10:00 AM**

```text
0 10 * * MON#1
```

**Last Friday of the month at 6:45 AM**

```text
45 6 ? * FRIL
```

#### Easy Builder Feature

To make it even easier to create and customize cron patterns, the cron-plus node includes a feature called Easy Builder. This feature provides a user-friendly interface that lets you quickly generate and adjust cron expressions without needing to write them manually. You can select options like time intervals, days of the week, and more, and the Easy Builder will generate the correct cron syntax for you.

:video{ariaLabel="Video showing the easy builder feature" autoPlay="true" height="795" loop="true" muted="true" playsInline="true" preload="none" width="800"}*Video showing the easy builder feature*

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

### Solar Event Schedules

Solar event-based triggers are a great feature in cron-plus for automating tasks based on sunlight events like sunrise, sunset, dawn, and dusk. You can fine-tune your triggers with offsets, like triggering an action 30 minutes after sunset.

Here are the solar events you can use:

- **nightEnd**: End of night, start of twilight.
- **nauticalDawn**: Horizon becomes faintly visible, used by sailors.
- **civilDawn**: Light enough for outdoor activities without lights.
- **sunrise**: Sun first visible on the horizon.
- **sunriseEnd**: Full sun above the horizon.
- **morningGoldenHourEnd**: End of the morning golden hour.
- **solarNoon**: Sun is at its highest point in the sky.
- **eveningGoldenHourStart**: Start of the evening golden hour.
- **sunsetStart**: Sun starts to set.
- **sunset**: Sun is fully below the horizon.
- **civilDusk**: Last light before it gets dark.
- **nauticalDusk**: Horizon is no longer visible, dark sky.
- **nightStart**: Full darkness after twilight.
- **nadir**: Darkest point of the night.

Let's start and learn how to use it. Suppose we need to trigger the flow 30 minutes after sunset. Here's how you do it:

Let’s start by setting up a flow that triggers 30 minutes after sunset. Here’s how:

1. Drag a new `cron-plus` node onto your Node-RED canvas.
2. Set the location, solar events depend on your geographic location. You can configure this at the node level or per schedule. In the Location field, either:
   - Enter your latitude and longitude manually, or
   - Click the three-dot icon to open a map and select your location.
3. Add a new schedule. Enter the following Schedule Name, Topic, Payload
4. Choose the solar event, set the Schedule Type to `solar`. :br
   You can choose "All Solar Events" or "Selected Solar Events" to pick specific ones. :br
   For this example, choose "sunset".
5. Set the offset, this defines how much earlier or later the trigger should happen compared to the solar event. :br
   For 30 minutes after sunset, enter:
   ```text
   30
   ```
   :brYou can also use negative numbers (like `-10` for 10 minutes before sunset) or larger values like `60` for 1 hour after.
6. Click Done, connect the node to the rest of your flow, and Deploy.

::render-flow
```json
[{"id":"cba15bd32c5434a5","type":"group","z":"b37428694e90b2c5","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["2af2e9274fe1321a","458c9533a1437ee1"],"x":94,"y":179,"w":392,"h":82},{"id":"2af2e9274fe1321a","type":"debug","z":"b37428694e90b2c5","g":"cba15bd32c5434a5","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":380,"y":220,"wires":[]},{"id":"458c9533a1437ee1","type":"cronplus","z":"b37428694e90b2c5","g":"cba15bd32c5434a5","name":"Cron Plus","outputField":"payload","timeZone":"","storeName":"","commandResponseMsgOutput":"output1","defaultLocation":"","defaultLocationType":"default","outputs":1,"options":[{"name":"et","topic":"30min After Sunset","payloadType":"default","payload":"","expressionType":"solar","expression":" 0 8 * * *","location":"20.70816594524601 75.673828125","offset":"30","solarType":"selected","solarEvents":"sunset"}],"x":200,"y":220,"wires":[["2af2e9274fe1321a"]]}]
```
::

Your flow will now trigger 30 minutes after sunset every day, automatically adjusting for seasonal changes based on your location.

### Date Sequence Schedules

While cron expressions and solar events are great for recurring patterns, sometimes you need to schedule flows to run at very specific, one-time moments, like a product launch, system maintenance window, or a holiday-specific action. This is where the Date Sequence schedule type in cron-plus comes in.

With this method, you can define exact dates and times (including timezone support), and the node will trigger your flow at those precise moments, once or multiple times, depending on the list you define.

The sequence field supports:

- UNIX timestamps (in milliseconds)

```text
1767225600000 
```

- Date and time (in plain text)

```text
2026-04-03 00:00
```

- Date and time with timezone

```text
2026-04-06 12:00 GMT+0
```

You can list multiple times, separated by commas:

```text
1767225600000, 2026-04-03 00:00, 2026-04-06 12:00 GMT+0
```

Let’s learn how to set this up:

1. Drag a new cron-plus node onto the canvas.
2. Double-click the node to open its settings.
3. Click +add to create a new schedule.
4. Give the schedule a name and configure the topic, this is the value that will be sent with the message when the schedule triggers.
5. Set the payload to whatever message or data you want to send when triggered.
6. Choose Date Sequence from the Schedule Type dropdown.
7. In the Expression field, enter one or more dates using any of the 8. supported formats we discussed above (UNIX timestamp, plain date/time, or date/time with timezone). You can separate multiple values with commas.
8. Click Done, then connect the cron-plus node to the rest of your flow (e.g., a debug node to see it trigger, or an action node to perform something).
9. Finally, click Deploy to save and start your schedule.

::render-flow
```json
[{"id":"2ff341cec3114c53","type":"cronplus","z":"b37428694e90b2c5","g":"2aa2d59a36bf0fa7","name":"Date Sequence","outputField":"payload","timeZone":"","storeName":"","commandResponseMsgOutput":"output1","defaultLocation":"","defaultLocationType":"default","outputs":1,"options":[{"name":"schedule1","topic":"fixed dates","payloadType":"str","payload":"fixed","expressionType":"dates","expression":"1767225600000, 2026-04-03 00:00, 2026-04-06 12:00 GMT+0","location":"","offset":"0","solarType":"all","solarEvents":"sunrise,sunset"}],"x":300,"y":780,"wires":[["b66ebe91df84b4ce"]]},{"id":"b66ebe91df84b4ce","type":"debug","z":"b37428694e90b2c5","g":"2aa2d59a36bf0fa7","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":560,"y":780,"wires":[]}]
```
::

The flow will now trigger exactly at each date and time you've specified.

### Handling Time Zones and Daylight Saving Time (DST)

When dealing with scheduled tasks, managing time zones and Daylight Saving Time (DST) is crucial to ensure your cron jobs trigger at the correct local time. With cron-plus in Node-RED, this is made easy. Cron-plus provides global time zone support, allowing you to specify the time zone for all schedules within a particular cron-plus node. When configuring the cron-plus node, you'll see an input field labeled "Timezone", where you can start typing your desired time zone and select from suggested options.

![Screenshot showing the Timezone input field in the cron-plus node configuration with auto-suggestions while typing](https://flowfuse.com/blog/2025/05/images/timezone-selection.png){dataZoomable=""}*Screenshot showing the Timezone input field in the cron-plus node configuration with auto-suggestions while typing*

For example, if your tasks need to run in the Eastern Time Zone, you would enter "America/New\_York" in the Timezone field. Similarly, for the UK time zone, you would enter "Europe/London".

When scheduling tasks in a time zone that observes Daylight Saving Time (DST), cron-plus will automatically adjust your task’s execution times to account for the DST changes. If you set a schedule for 8:00 AM daily, cron-plus will ensure that the task triggers at 8:00 AM local time, whether it's during Standard Time (e.g., EST) or Daylight Saving Time (e.g., EDT).

When DST begins (e.g., in spring), cron-plus will shift the scheduled task forward by one hour. Similarly, when DST ends (e.g., in fall), the task will shift back by one hour. This automatic adjustment is handled based on the time zone you enter.

### Understanding Node Status Symbols and Their Descriptions

The cron-plus node visually indicates its state using status markers in the flow editor:

- **● (Dot):** Indicates a static schedule configured directly in the node.
- **○ (Ring):** Indicates a dynamic schedule added via input messages.

Also, the node indicates the next event, along with the type of schedule. For example, node in the following image specifies that the next event is on May 26, 2025, at 12:00 AM GMT +5:30. It is a static schedule, and its name is 'Schedule1'

![A node showing the next event scheduled for May 26, 2025, at 12:00 AM GMT +5:30 with a static schedule named 'Schedule1'.](https://flowfuse.com/blog/2025/05/images/node-status-event.png){dataZoomable=""}&#x2A;A node showing the next event scheduled for May 26, 2025, at 12:00 AM GMT +5:30 with a static schedule named 'Schedule1'.*

### Dynamic Schedule Control via Input Messages

In some cases, you might not know your schedule ahead of time, or you may want it to change based on user actions or incoming data. The cron-plus node supports this with dynamic control using input messages. This means you can add, update, or remove schedules while your flow is running, without opening the editor. It’s a powerful way to make your automations more responsive and adaptable.

Each control message is sent to the `cron-plus` node using a specially formatted `msg.payload` with a command and associated configuration.

Below are some examples of dynamic commands. Please refer to the built-in help of the cron-plus node for more details:

| Command    | Description                                                          | Example                                                                                                                                                   |
| ---------- | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `trigger`  | Triggers a schedule by name.                                         | `{ "command": "trigger", "name": "dynamic-1" }`                                                                                                           |
| `add`      | Add (or update) a dynamic schedule.                                  | `{ "command": "add", "name": "dynamic-1", "topic": "dynamic-schedule", "payloadType": "default", "expressionType": "cron", "expression": "*/2 * * * *" }` |
| `remove`   | Removes a specific schedule by name.                                 | `{ "command": "remove", "name": "dynamic-1" }`                                                                                                            |
| `start`    | Starts a specific schedule by name.                                  | `{ "command": "start", "name": "dynamic-1" }`                                                                                                             |
| `stop`     | Stops a specific schedule by name.                                   | `{ "command": "stop", "name": "dynamic-1" }`                                                                                                              |
| `pause`    | Pauses a specific schedule by name.                                  | `{ "command": "pause", "name": "dynamic-1" }`                                                                                                             |
| `export`   | Exports a schedule by name.                                          | `{ "command": "export", "name": "dynamic-1" }`                                                                                                            |
| `status`   | Provides the status of a specific schedule by name.                  | `{ "command": "status", "name": "dynamic-1" }`                                                                                                            |
| `describe` | Provides a human-readable description of a cron or solar expression. | `{ "command": "describe", "expression": "0 8 * * 1-5", "expressionType": "cron" }`                                                                        |

Commands can also include a `filter` to operate on multiple schedules at once. Below are a few examples. Please refer to the built-in help of the cron-plus node for more details:

| Filter                  | Description                                          | Example                                        |
| ----------------------- | ---------------------------------------------------- | ---------------------------------------------- |
| `-all`                  | Operate a command on all schedules.                  | `{ "command": "start-all" }`                   |
| `-all-dynamic`          | Operate a command on all dynamic schedules.          | `{ "command": "export-all-dynamic" }`          |
| `-all-static`           | Operate a command on all static schedules.           | `{ "command": "pause-all-static" }`            |
| `-all-active`           | Operate a command on all active schedules.           | `{ "command": "stop-all-active" }`             |
| `-all-inactive`         | Operate a command on all inactive schedules.         | `{ "command": "start-all-inactive" }`          |
| `-all-active-static`    | Operate a command on all active static schedules.    | `{ "command": "stop-all-active-static" }`      |
| `-all-active-dynamic`   | Operate a command on all active dynamic schedules.   | `{ "command": "stop-all-active-dynamic" }`     |
| `-all-inactive-static`  | Operate a command on all inactive static schedules.  | `{ "command": "start-all-inactive-static" }`   |
| `-all-inactive-dynamic` | Operate a command on all inactive dynamic schedules. | `{ "command": "remove-all-inactive-dynamic" }` |

#### Dynamic Demo 1

For example, we need to build a flow that triggers on UK public holidays to stop recording the OEE (Overall Equipment Efficiency) or lock the entry gates of the factory. To achieve this, we can integrate a UK public holiday API into our Node-RED flow, fetch the holiday data, and then trigger actions based on those holidays.

1. Drag the Inject node onto the canvas and set it to trigger on deploy after `0.1` seconds.
2. Next, drag the HTTP request node onto the canvas, set the method to GET, and use the URL `https://www.gov.uk/bank-holidays.json`. Set the return to "parsed JSON object".
3. Drag the Function node onto the canvas and add the following JavaScript code into it:

```javascript
// Retrieve public holidays for England and Wales from the API response
const engHols = msg.payload["england-and-wales"].events;

// Clear out any existing schedules before adding new ones
node.send({ topic: 'remove-all' });

// Create an array to hold the new holiday schedules
const newSchedules = [];

// Loop through all the holiday events
for (let index = 0; index < engHols.length; index++) {
    const hol = engHols[index]; // Get the current holiday
    const date = new Date(hol.date); // Convert the holiday date to a Date object

    // Skip holidays that are in the past (before the current date)
    if (date.valueOf() < Date.now()) {
        continue; // Skip to the next holiday
    }

    // Create a new schedule for upcoming holidays
    const newSchedule = {
        "command": "add", // Command to add a new schedule
        "name": hol.title + ` (${date.getFullYear()})`, // Holiday name with year
        "topic": hol.title, // Holiday title as topic
        "expression": hol.date, // Holiday date to use as an expression
        "expressionType": "dates", // Define the type as dates
        "payload": hol, // Send the holiday details as the payload
        "payloadType": "json" // Specify that the payload is in JSON format
    };

    // Add the new schedule to the list of new schedules
    newSchedules.push(newSchedule);    
}

// Set the topic as empty (not used for now)
msg.topic = '';
// Set the payload to the new schedules array created above
msg.payload = newSchedules;

// Return the updated message with new schedules
return msg;
```

4. Drag a cron-plus node onto the canvas. Connect the Inject node to the HTTP request node, the HTTP request node to the Function node, and the Function node to the cron-plus node.
5. Deploy the flow.

Now you can check the dynamic schedules list (see how at the end of this section).

::render-flow
```json
[{"id":"3608db0d1bd59aa5","type":"inject","z":"1791a7bd576b3a15","name":"Update bank holidays","props":[{"p":"topic","vt":"str"}],"repeat":"","crontab":"00 02 * * 1","once":false,"onceDelay":0.1,"topic":"","x":160,"y":60,"wires":[["252cb7c88de78e45"]]},{"id":"252cb7c88de78e45","type":"http request","z":"1791a7bd576b3a15","name":"","method":"GET","ret":"obj","paytoqs":"ignore","url":"https://www.gov.uk/bank-holidays.json","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":370,"y":60,"wires":[["cf71e6ad0a983d80"]]},{"id":"cf71e6ad0a983d80","type":"function","z":"1791a7bd576b3a15","name":"england bank holiday schedules","func":"const engHols = msg.payload[\"england-and-wales\"].events\n\n// clear out existing schedules\nnode.send({topic:'remove-all'})\n\nconst newSchedules = []\nfor(let index = 0; index < engHols.length; index++) {\n    const hol = engHols[index];\n    const date = new Date(hol.date)\n    if (date.valueOf() < Date.now()) {\n        continue\n    }\n    const newSchedule = {\n        \"command\": \"add\",\n        \"name\": hol.title + ` (${date.getFullYear()})`,\n        \"topic\": hol.title,\n        \"expression\": hol.date,\n        \"expressionType\": \"dates\",\n        \"payload\": hol,\n        \"payloadType\": \"json\"\n    }\n    newSchedules.push(newSchedule)    \n}\n\nmsg.topic = ''\nmsg.payload = newSchedules\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":430,"y":120,"wires":[["abea360f336bbf5c"]]},{"id":"abea360f336bbf5c","type":"cronplus","z":"1791a7bd576b3a15","name":"","outputField":"payload","timeZone":"","storeName":"","commandResponseMsgOutput":"output2","defaultLocation":"","defaultLocationType":"default","outputs":2,"options":[],"x":360,"y":200,"wires":[["dfff5dae3de9e7de"],["7834e47a1631346f"]]},{"id":"b5a53df2dedde1d2","type":"inject","z":"1791a7bd576b3a15","name":"","props":[{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"list-all","x":110,"y":180,"wires":[["abea360f336bbf5c"]]},{"id":"7834e47a1631346f","type":"debug","z":"1791a7bd576b3a15","name":"list","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":220,"wires":[]},{"id":"dfff5dae3de9e7de","type":"debug","z":"1791a7bd576b3a15","name":"action","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":180,"wires":[]},{"id":"041f7306088daf24","type":"inject","z":"1791a7bd576b3a15","name":"","props":[{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"remove-all","x":120,"y":220,"wires":[["abea360f336bbf5c"]]}]
```
::

#### Dynamic Demo 2

Additionally, I'd like to share another demo that Steve has prepared for the community, which demonstrates dynamic scheduling based on the best energy prices:

::render-flow
```json
[{"id":"0f969cd96da84b2e","type":"http request","z":"f559cf0eb4eca11c","name":"","method":"GET","ret":"obj","paytoqs":"ignore","url":"https://api.awattar.at/v1/marketdata","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":450,"y":220,"wires":[["32e08539d8339f74"]]},{"id":"2a7465d67deae278","type":"inject","z":"f559cf0eb4eca11c","name":"get liveData","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":290,"y":220,"wires":[["0f969cd96da84b2e"]]},{"id":"32e08539d8339f74","type":"function","z":"f559cf0eb4eca11c","name":"Billigsten 5 Stunden -> msg.liveData","func":"var timestamp = Date.now();\nvar maxLoadingDuration = 5;\n\nvar cheapestHours = msg.payload.data\n    .sort((a,b) => a.marketprice - b.marketprice)\n    .slice(0,maxLoadingDuration)\n    .sort((a,b) => a.start_timestamp - b.start_timestamp);\n    var currentHour = cheapestHours.filter(d => d.start_timestamp < timestamp\n                                        && d.end_timestamp > timestamp);\nmsg.liveData = {\n    soc:msg.payload,\n    cheapestHours: cheapestHours\n}\nreturn msg;\n","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":370,"y":280,"wires":[["5c56b3ca5ac4f7c2"]]},{"id":"89c2acf51e7fbc9c","type":"function","z":"f559cf0eb4eca11c","name":"merge active and new schedules","func":"\nconst inputData = msg.liveData.cheapestHours\nconst activeSchedules = msg.activeSchedules || []\n\n// Clear existing schedules\nnode.send({ topic: \"remove-all-dynamic\" });\n\n// helper function\nconst makeSchedule = (start, time, suffix) => {\n    const isStart = start == true || start === \"start\" || start === \"on\" || start == 1\n    const title = formatTime(time) + (isStart ? \"-on\" : \"-off\")\n    const name = suffix ? `${title} (${suffix}) ` : title\n    return {\n        \"command\": \"add\",\n        \"name\": name,\n        \"expression\": time,\n        \"expressionType\": \"dates\",\n        \"payloadType\": \"str\",\n        \"payload\": isStart ? \"start\" : \"stop\",\n    }\n}\n// helper function\nconst formatTime = (date) => {\n    const d = new Date(date)\n    const hh = (\"\" + d.getHours()).padStart(2, \"0\")\n    const mm = (\"\" + d.getMinutes()).padStart(2, \"0\")\n    return `${hh}:${mm}`\n}\n\n// vars\nconst newSchedules = []\nconst mergedSchedules = []\nconst keepSchedules = []\n\nfor (let index = 0; index < inputData.length; index++) {\n    const element = inputData[index];\n    let suffix = ''\n    suffix = element.marketprice + \" \" + element.unit\n    const startTime = new Date(element.start_timestamp)\n    const endTime = new Date(element.end_timestamp)\n    newSchedules.push(makeSchedule(\"start\", startTime.valueOf(), suffix))\n    newSchedules.push(makeSchedule(\"stop\", endTime.valueOf(), suffix))\n}\n\n\n// if there are any existing schedules not yet operated\n// and they are before the first in the new data, lets keep them\nif (newSchedules?.length) {\n    const firstNewSchedule = newSchedules[0]\n    const existingSchedulesBeforeFirstNew = activeSchedules?.filter(e => e.expression < firstNewSchedule.expression)\n    if (existingSchedulesBeforeFirstNew?.length) {\n        keepSchedules.push(...existingSchedulesBeforeFirstNew.map(e => {\n            const n = e.name\n            const k = makeSchedule (e.payload, e.expression) \n            k.name = n.replace(' (keep)', '') + \" (keep)\"\n            return k\n        }))\n    }\n} else {\n    // keep all existing active schedules (as there are no new ones)\n    keepSchedules.push(...activeSchedules)\n}\n\nmergedSchedules.push(...newSchedules, ...keepSchedules)\nmergedSchedules.sort((a, b) => a.expression - b.expression) // order by expression asc\n\n// deduplicate the schedules by seeing if there are consecutive on/off schedules\nlet deduplicatedSchedules = [];\nlet prevSchedule\nfor (let i = 0; i < mergedSchedules.length; i++) {\n    const currentSchedule = mergedSchedules[i]\n    if (i === 0) {\n        deduplicatedSchedules.push(currentSchedule);\n    } else {\n        if (currentSchedule.payload === prevSchedule.payload) {\n            // to scheules are the same (start/start or stop/stop)\n            if (currentSchedule.payload === \"start\") {\n                // ignore this one as the previous one was a \"start\" (and due to sorting, this one is superfluous)\n            } else if (currentSchedule.payload === \"stop\") {\n                // since the previous one was a \"stop\", we need to update the previous schedule to the new stop time\n                prevSchedule.expression = currentSchedule.expression\n            }\n        } else {\n            deduplicatedSchedules.push(currentSchedule); // push the current schedule\n        }\n    }\n    prevSchedule = currentSchedule\n}\n\n// node.warn({newSchedules, keepSchedules, mergedSchedules, deduplicatedSchedules}) // debug\nmsg.payload = deduplicatedSchedules\nmsg.topic = \"update schedules\"\n\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":740,"y":340,"wires":[["b6a5d42c7751fae2"]]},{"id":"827e16c3f02d1962","type":"inject","z":"f559cf0eb4eca11c","name":"Clear all scedules","props":[{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"remove-all-dynamic","x":310,"y":380,"wires":[["b6a5d42c7751fae2"]]},{"id":"32a88825fe3edf37","type":"switch","z":"f559cf0eb4eca11c","name":"start","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"start","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":1250,"y":280,"wires":[["e84ba501a1405907"]]},{"id":"5e5497cff754ef73","type":"switch","z":"f559cf0eb4eca11c","name":"stop","property":"topic","propertyType":"msg","rules":[{"t":"eq","v":"payload","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":1250,"y":320,"wires":[["b2e8c3606bd04897"]]},{"id":"e84ba501a1405907","type":"debug","z":"f559cf0eb4eca11c","name":"start something","active":true,"tosidebar":true,"console":false,"tostatus":true,"complete":"payload","targetType":"msg","statusVal":"payload","statusType":"auto","x":1460,"y":280,"wires":[]},{"id":"b2e8c3606bd04897","type":"debug","z":"f559cf0eb4eca11c","name":"stop something","active":true,"tosidebar":true,"console":false,"tostatus":true,"complete":"payload","targetType":"msg","statusVal":"payload","statusType":"auto","x":1460,"y":320,"wires":[]},{"id":"b6a5d42c7751fae2","type":"cronplus","z":"f559cf0eb4eca11c","name":"","outputField":"payload","timeZone":"","storeName":"","commandResponseMsgOutput":"output2","defaultLocation":"","defaultLocationType":"default","outputs":2,"options":[],"x":1020,"y":380,"wires":[["32a88825fe3edf37","5e5497cff754ef73"],["fe51aaba903612eb"]]},{"id":"5c56b3ca5ac4f7c2","type":"link call","z":"f559cf0eb4eca11c","name":"","links":["ee57d78d1c769d1b"],"linkType":"static","timeout":"30","x":730,"y":280,"wires":[["89c2acf51e7fbc9c"]]},{"id":"b4cf44f6c7bd1461","type":"link in","z":"f559cf0eb4eca11c","name":"link in 4","links":["29dcf0872d3f7ca4"],"x":505,"y":320,"wires":[["5c56b3ca5ac4f7c2"]]},{"id":"fe51aaba903612eb","type":"link out","z":"f559cf0eb4eca11c","name":"link out 17","mode":"link","links":["a1c12404f726b02f"],"x":1215,"y":380,"wires":[]},{"id":"51b3de02bcf463a3","type":"group","z":"f559cf0eb4eca11c","name":"test data","style":{"label":true},"nodes":["6b39e36054edcc22","32388c4b0af7a5b1","73a529bfd3742503","43aa8690b4167bcc","dae8031ee5f37eb5","29dcf0872d3f7ca4"],"x":214,"y":579,"w":522,"h":122},{"id":"6b39e36054edcc22","type":"inject","z":"f559cf0eb4eca11c","g":"51b3de02bcf463a3","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":320,"y":620,"wires":[["32388c4b0af7a5b1"]]},{"id":"32388c4b0af7a5b1","type":"template","z":"f559cf0eb4eca11c","g":"51b3de02bcf463a3","name":"cheapestHours sample","field":"liveData","fieldType":"msg","format":"json","syntax":"mustache","template":"{\n      \"soc\": {},\n      \"cheapestHours\": [\n        {\n          \"start_timestamp\": \"2025-05-07 07:00:00\",\n          \"end_timestamp\": \"2025-05-07 12:00:00\",\n          \"marketprice\": 66.02,\n          \"unit\": \"Eur/MWh\"\n        },\n        {\n          \"start_timestamp\": \"2025-05-07 20:00:00\",\n          \"end_timestamp\": \"2025-05-07 21:00:00\",\n          \"marketprice\": 62.48,\n          \"unit\": \"Eur/MWh\"\n        }\n      ]\n    }","output":"json","x":500,"y":620,"wires":[["dae8031ee5f37eb5"]]},{"id":"73a529bfd3742503","type":"inject","z":"f559cf0eb4eca11c","g":"51b3de02bcf463a3","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":320,"y":660,"wires":[["43aa8690b4167bcc"]]},{"id":"43aa8690b4167bcc","type":"template","z":"f559cf0eb4eca11c","g":"51b3de02bcf463a3","name":"cheapestHours overlap","field":"liveData","fieldType":"msg","format":"json","syntax":"mustache","template":"{\n      \"soc\": {},\n      \"cheapestHours\": [\n        {\n          \"start_timestamp\": \"2025-05-07 08:00:00\",\n          \"end_timestamp\": \"2025-05-07 11:00:00\",\n          \"marketprice\": 66.02,\n          \"unit\": \"Eur/MWh\"\n        },\n        {\n          \"start_timestamp\": \"2025-05-07 20:00:00\",\n          \"end_timestamp\": \"2025-05-07 21:00:00\",\n          \"marketprice\": 62.48,\n          \"unit\": \"Eur/MWh\"\n        }\n      ]\n    }","output":"json","x":510,"y":660,"wires":[["dae8031ee5f37eb5"]]},{"id":"dae8031ee5f37eb5","type":"junction","z":"f559cf0eb4eca11c","g":"51b3de02bcf463a3","x":660,"y":640,"wires":[["29dcf0872d3f7ca4"]]},{"id":"29dcf0872d3f7ca4","type":"link out","z":"f559cf0eb4eca11c","g":"51b3de02bcf463a3","name":"link out 16","mode":"link","links":["b4cf44f6c7bd1461"],"x":695,"y":640,"wires":[]},{"id":"f3ff5331698e1750","type":"group","z":"f559cf0eb4eca11c","name":"Subroutine for getting active schedules","style":{"label":true},"nodes":["ee57d78d1c769d1b","9956e352b1728160","aba3e0f7de7c6f54","cc753a34602daf70","e4b0cb5dbf1fcbcc","a1c12404f726b02f"],"x":594,"y":439,"w":712,"h":82},{"id":"ee57d78d1c769d1b","type":"link in","z":"f559cf0eb4eca11c","g":"f3ff5331698e1750","name":"get-active-dynamic schedules","links":[],"x":740,"y":480,"wires":[["9956e352b1728160"]],"l":true},{"id":"9956e352b1728160","type":"change","z":"f559cf0eb4eca11c","g":"f3ff5331698e1750","name":"","rules":[{"t":"set","p":"topic","pt":"msg","to":"export-active-dynamic","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":905,"y":480,"wires":[["b6a5d42c7751fae2"]],"l":false},{"id":"aba3e0f7de7c6f54","type":"change","z":"f559cf0eb4eca11c","g":"f3ff5331698e1750","name":"","rules":[{"t":"move","p":"payload.result","pt":"msg","to":"activeSchedules","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1215,"y":480,"wires":[["cc753a34602daf70"]],"l":false},{"id":"cc753a34602daf70","type":"link out","z":"f559cf0eb4eca11c","g":"f3ff5331698e1750","name":"link-return","mode":"return","links":[],"x":1265,"y":480,"wires":[]},{"id":"e4b0cb5dbf1fcbcc","type":"switch","z":"f559cf0eb4eca11c","g":"f3ff5331698e1750","name":"","property":"_linkSource","propertyType":"msg","rules":[{"t":"istype","v":"array","vt":"array"}],"checkall":"true","repair":false,"outputs":1,"x":1165,"y":480,"wires":[["aba3e0f7de7c6f54"]],"l":false},{"id":"a1c12404f726b02f","type":"link in","z":"f559cf0eb4eca11c","g":"f3ff5331698e1750","name":"link in 12","links":["fe51aaba903612eb"],"x":1105,"y":480,"wires":[["e4b0cb5dbf1fcbcc"]]}]
```
::

If you need to see the dynamic schedules of a specific node, double-click on it and click on the 'Dynamic Schedules' button from the configuration panel. This will show all of the dynamic schedules associated with that node.

:video{ariaLabel="Video showing the 'Dynamic Schedules' button and the list of all dynamically scheduled events." autoPlay="true" height="946" loop="true" muted="true" playsInline="true" preload="none" width="800"}&#x2A;Video showing the 'Dynamic Schedules' button and the list of all dynamically scheduled events.*

As you can see, creating flexible and dynamic cron schedules Node-RED can give you complete control over your automation tasks. Whether it's simple, recurring events, or complex, time-sensitive triggers, the combination of cron expressions and dynamic controls allows for smarter, more efficient workflows.

Take some time to explore these features and experiment with your own schedules. The more you play around with them, the better you'll understand how to tailor your flows to meet your exact needs.

Thanks for reading, and happy automating! If you run into any questions or need assistance along the way, don’t hesitate to reach out. We’re here to help!

If you’re using Node-RED in your production environment, it’s important to keep your instances organized, scalable, and secure. FlowFuse can help with that by making it easier to manage and maintain your Node-RED setup, while also supporting faster deployment, scaling, and improved security.

[Contact us](https://flowfuse.com/contact-us/) now to learn more.

## Wrapping Up

Designing flexible and intelligent schedules is a key part of building robust automation with Node-RED. Whether you’re triggering actions based on time, solar events, or dynamic runtime conditions, the cron-plus node gives you a powerful set of tools to fine-tune when your flows should run.

By combining these scheduling techniques with the management features of FlowFuse, you can confidently build and operate reliable automation systems at any scale.


# How to Embed Webpages on the FlowFuse Dashboard

When you build a dashboard, sometimes you need more than just internal data. Maybe it’s a live map, a report hosted elsewhere, or another dashboard, whatever it is, having to switch tabs breaks the flow. FlowFuse lets you embed external content like web pages, dashboards, PDFs, and widgets right into your dashboard. This guide shows you how to do exactly that, step by step, so your team has everything they need, all in one place.

## Why Embed Webpages in Your Dashboard?

Embedding external content directly into your FlowFuse dashboard can make your life a lot easier. Here’s why it’s worth considering:

- **Streamline Your Workflow:** No more hopping between tabs or switching apps. Everything you need can be in one place.
- **Save Time on Rework:** If you’ve already built a report, chart, or page somewhere else, just embed it into your dashboard. No need to start from scratch.
- **Quick Decisions:** Having all your key data together helps you see what’s important at a glance and act faster.
- **Cut Down on Clicks:** The fewer actions needed to get to your information, the more time you can spend on actually getting things done.

## How to Embed Webpages On your FlowFuse Dashboard

Embedding external content into your FlowFuse dashboard is straightforward and flexible. In this section, you'll learn two ways to do it: using a direct URL and using embed code. We’ll also cover common issues you might face and how to fix them. Lastly, you'll see how to embed one FlowFuse dashboard inside another, making it easier to centralize important views in one place.

### Prerequisites

Before you begin embedding webpages on FlowFuse Dashboard, make sure you have the following:

- **Running FlowFuse Instance:** Make sure you have a FlowFuse instance set up and running. If you don't have an account, check out our [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}.
- **FlowFuse Dashboard:** Ensure you have [FlowFuse Dashboard](https://flows.nodered.org/node/@flowfuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"} (also known as Node-RED Dashboard 2.0 in the community) installed and properly configured on your instance.
- **@flowfuse/node-red-dashboard-2-ui-iframe:** Ensure you have [node-red-dashboard-2-ui-iframe](https://flows.nodered.org/node/@flowfuse/node-red-dashboard-2-ui-iframe){rel="&#x22;nofollow&#x22;"} installed.

#### Step 1: Obtain the URL or Embed Code of the Webpage You Want to Embed

The first step is identifying and grabbing the URL of the webpage or external content you want to embed into your FlowFuse dashboard. This could be a live dashboard, report, Google Maps, video, or any other type of content.

When embedding content from third-party sources, make sure the following conditions the page or content you're embedding should be publicly accessible or have the proper permissions for embedding. For example, private reports or webpages require login credentials or an API key, which should be handled securely.

Some websites may restrict embedding through iframes due to [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS){rel="&#x22;nofollow&#x22;"} policies. Check whether the external site allows embedding if the content doesn’t load properly.

Many platforms, such as YouTube and Google Maps, provide a specific "embed code or URL" that is more suitable for embedding. Ensure you use the correct embed link or code these platforms offer to guarantee smooth integration.

Once the URL or embed code is ready, move on to the next step.

#### Step 2: Embedding the Webpage on FlowFuse Dashboard

Now that you’ve gathered the URL or embed code for the external content you want to embed, it’s time to add it to your FlowFuse dashboard. Below are two methods for embedding external content:

##### 2.1 Embed via URL

The easiest and most straightforward way to embed external content is by using the URL. FlowFuse's iframe node allows you to use an external URL directly. Here’s how to do it:

1. Drag the ui\_iframe widget onto the canvas.
2. Double-click the widget to open its configuration dialog.
   - Create a new group for it to render in.
   - Set the size (width and height).
   - Enter the URL you want to embed.

![ui\_iframe widget configuration](https://flowfuse.com/blog/2025/05/images/if_frame-config.png){dataZoomable=""}*iframe widget configuration*

3. Click Done and then Deploy.

For a quick hands-on practice, you can try embedding a weather widget, Google Maps, Google Calendar, or a hosted PDF on your dashboard.

![Weather widget embedded in FlowFuse Dashboard](https://flowfuse.com/blog/2025/05/images/weather-widget.png)*Weather widget embedded in FlowFuse Dashboard*

![Google Map embedded in FlowFuse Dashboard](https://flowfuse.com/blog/2025/05/images/google-map.png)*Google Map embedded in FlowFuse Dashboard*

![PDF embedded in FlowFuse Dashboard](https://flowfuse.com/blog/2025/05/images/pdf.png)*PDF embedded in FlowFuse Dashboard*

![Google Calendar embedded in FlowFuse Dashboard](https://flowfuse.com/blog/2025/05/images/google-calendar.png)*Google Calendar embedded in FlowFuse Dashboard*

##### 2.2 Embed via HTML Embed Code

If you have an embed code from third-party services, you can use this code to embed the content into your FlowFuse dashboard. Here’s how to do it:

1. Drag the **ui-template** widget onto the canvas.
2. Double-click on it to open its configuration dialog.
   - Create a new group for it to render in.
   - Set the size (width and height).
3. Paste your embed code into the template widget. Most embed codes include both HTML and JavaScript, so follow this structure:

```html
<template>
  <!-- Paste your HTML code here -->
</template>
<script>
  // Paste your JavaScript code here
</script>
```

Some services provide an **iframe** tag. In this case, you need only copy the URL and use the embedding via the URL method.

4. Click **Done** and **Deploy** to save your changes once you've added the code.

:video{ariaLabel="Animated weather widget on the Flowfuse dashboard, embedded with code." autoPlay="true" height="1007" loop="true" muted="true" playsInline="true" preload="none" width="800"}&#x2A;Animated weather widget on the Flowfuse dashboard, embedded with code.*

Now that you’ve learned how to embed external content into your FlowFuse dashboard, one day you may need to embed your FlowFuse dashboard elsewhere, either on another FlowFuse dashboard or an external site. If you’ve tried and found that it’s not working as expected.

This is a security feature designed to protect your data. FlowFuse dashboards, like many other web applications, implement security policies such as Cross-Origin Resource Sharing (CORS) and the X-Frame-Options header. These policies ensure that your dashboard is only viewed in trusted environments, preventing malicious sites from tampering with your data or exposing it to unauthorized users.

However, if you need to embed your FlowFuse dashboard into other websites or on another FlowFuse dashboard, it’s possible to do so with some configuration changes. Below is a section on how to enable embedding securely of FlowFuse Dashboard:

### Enabling Embedding of FlowFuse Dashboards

1. Go to your FlowFuse instance settings.
2. Switch to the **editor*&#x2A; settings and enable &#x2A;*"Allow Dashboard to be embedded in an iFrame"**

![FlowFuse instance settings showing the option to allow dashboard embedding in an iframe.](https://flowfuse.com/blog/2025/05/images/allow-dashboard-embedding.png){dataZoomable=""}&#x2A;FlowFuse instance settings showing the option to allow dashboard embedding in an iframe.*

3. Click **Save Settings and restart** your instance for the changes to take effect.

[![FlowFuse OEE Dashboard embedded in another FlowFuse dashboard.](https://flowfuse.com/blog/2025/05/images/embedding-flowfuse-oee-dashboard.png){dataZoomable=""}](https://flowfuse.com/blueprints/manufacturing/oee-dashboard/)*FlowFuse OEE Dashboard embedded in another FlowFuse dashboard.*

FlowFuse dashboards offer great flexibility, making it easy to embed external content like weather widgets, maps, and PDFs directly into your workspace. With a few simple steps, you can also embed FlowFuse dashboards into other websites, ensuring everything you need is in one place.

## Up Next

If you're interested in learning more about embedding webpages or enhancing your FlowFuse dashboards, check out the following blogs:

- [Mapping Location on Dashboard](https://flowfuse.com/blog/2024/05/mapping-location-on-dashboard-2/): In this article, we dive into how you can embed location maps into your FlowFuse dashboard. Learn how to map locations, track real-time data, and make your dashboards more interactive and informative.
- [Generating PDF Reports with Node-RED and FlowFuse](): This guide explains how to generate PDF reports directly with Node-RED and FlowFuse and how to preview these reports within your FlowFuse dashboards.


# FlowFuse 2.17: Easier remote instance onboarding, Dashboard blueprint, PDF generation, and more

This release is focused on improvements that help you get up and running with FlowFuse much more quickly. Our vision is that you can get started with FlowFuse and have a successful application up and running, from scratch, in hours, not days, weeks or months. This release gets us closer to that vision by focusing on improvements to the installation process for the Device Agent, and two new Blueprints.

## Device Agent onboarding

If you already had a Node-RED instance running on a device, it was a bit of a hassle to get it connected to FlowFuse as a remote instance. You had to install the Device Agent, find that it clashed with your existing instance, turn off that instance, run the Device Agent again, find that you can't import your existing instance...and so on, until finally getting copies of your flows and adding them to FlowFuse manually.

Lots of friction. We heard you.

Now, when you install the Device Agent, it will automatically scan for an existing Node-RED instance running locally and help you import its flows into FlowFuse.

This streamlines the whole process, saving you valuable time and effort. It ensures you can manage the Node-RED flows running on your edge device as quickly as possible.

## Blueprint: Getting Started with Dashboard

![Screenshot of Getting Started with Dashboard](https://flowfuse.com/blog/2025/05/images/dashboard.png)*Screenshot of Getting Started with Dashboard*

One of the most popular features of Node-RED is Dashboard 2.0. And starting now, getting started with Dashboard is as simple as one click.

Our new Getting Started with Dashboard Blueprint deploys to a new Node-RED instance in a single click and demonstrates several examples of how to use Dashboard. These include various ways of visualizing data, the data entry widget that allows direct entry to a table, and audit log creation.

New Dashboard nodes are added on a regular basis, and we will keep in mind which ones users would like help using as we iterate on this Blueprint.

To put this Blueprint to use, check out the Blueprint page for [Getting Started with Dashboard.](https://flowfuse.com/blueprints/getting-started/dashboard/)

## Blueprint: PDF Report Generator

![Screenshot of PDF Report Generator](https://flowfuse.com/blog/2025/05/images/pdf-flow.png)*Screenshot of PDF Report Generator*

Until now, creating a presentable report using data accessed in your Node-RED instance was a manual effort.

This new Blueprint makes it very easy to create PDF reports from your data. Using SQLite nodes and connecting to your database, this Blueprint enables drag-and-drop field selection.

To get you started using this Blueprint, we've included sample data that is generated automatically.

Instructions for using this Blueprint, including how to map fields from your database to our preconfigured fields, [check out the Blueprint page.](https://flowfuse.com/blueprints/manufacturing/pdf-report-generator/)

## Where are we headed?

We are focused on making it as easy as possible to get started with Node-RED, to manage Node-RED instances, and start building applications quickly. Some improvements on the way include [pulling from a Git repo](https://github.com/FlowFuse/flowfuse/issues/5415){rel="&#x22;nofollow&#x22;"} (we shipped Git push last release), including [Blueprints for self-hosted installations](https://github.com/FlowFuse/flowfuse/issues/5179){rel="&#x22;nofollow&#x22;"}, and [better information about resource usage](https://github.com/FlowFuse/flowfuse/issues/223){rel="&#x22;nofollow&#x22;"}. We're also busy at work on a number of core Node-RED items for the forthcoming 4.1.0 release.

With this work and more on the way, we are continuing to deliver our vision of FlowFuse being the best way to unlock your industrial data, integrate everything and optimize faster.

## What else is new?

For a full list of everything that went into our 2.17 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Together, we can make FlowFuse better with each release!

## Try FlowFuse

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.


# How to Generate PDF Reports Using Node-RED in FlowFuse (2026)

Generating PDF reports is a common need in many workflows, whether you're logging data, sharing results, or creating summaries. With Node-RED and FlowFuse, you can easily automate turning your data into well-structured PDF files. This guide will show you how to set up step-by-step PDF report generation using simple tools and flows.

Generating reports allows you to capture snapshots of critical data, summarize system activities, and distribute insights in an easy-to-read and stored format. PDF is one of the most universally accepted formats for sharing documents, making it ideal for delivering structured information from your Node-RED flows.

## Prerequisites

Before you begin, make sure the following requirements are met:

- You have an active [FlowFuse account](https://app.flowfuse.com){rel="&#x22;nofollow&#x22;"} and a running FlowFuse instance.
- You are familiar with creating and deploying basic flows in Node-RED. If not, consider taking the [Node-RED Fundamentals Course](https://node-red-academy.learnworlds.com/course/node-red-getting-started){rel="&#x22;nofollow&#x22;"} sponsored by FlowFuse.
- Ensure you have installed `flowfuse/node-red-dashboard` `@flowfuse/node-red-dashboard-2-ui-iframe` and `node-red-contrib-sqlite` (The SQLite node is required for the demo data generation flow we provided. If you're not using that flow, you can skip this.).

## Setting Up PDF Generation in Node-RED

Once the prerequisites are in place, the next step is setting up your Node-RED environment to generate PDF reports. In this section, we will go over how to install the necessary Node-RED node and configure a flow to generate PDF reports.

### Step 1: Install the @platmac/node-red-pdfbuilder

The [platmac/node-red-pdfbuilder](https://flows.nodered.org/node/@platmac/node-red-pdfbuilder){rel="&#x22;nofollow&#x22;"} node is the primary node for creating PDF reports in Node-RED. To install this node:

1. Open your Node-RED editor.
2. Navigate to the "Manage palette" section from the top-right menu.
3. Click on the "Install" tab and search for `@platmac/node-red-pdfbuilder`.
4. Click "Install" to add the node to your palette.

This node allows you to dynamically generate PDFs from various inputs, which is exactly what you will need to generate reports.

If you haven't installed the `@flowfuse/node-red-dashboard`, `@flowfuse/node-red-dashboard-2-ui-iframe` and `node-red-contrib-sqlite` nodes, you can install them similarly.

### Step 2: Understanding How to Use the Pdfbuilder Node

Now that the required node is installed, let's dive into how to use it and how to leverage the different attributes to customize your PDF reports. The pdfbuilder node in Node-RED simplifies generating PDFs by allowing you to define content, layout, and styling directly in your flow.

The key advantage of using pdfbuilder node is that it operates server-side, meaning PDFs can be generated automatically without a browser or manual interaction. This makes it ideal for automated workflows where consistent, programmatically created documents are needed.

When working with this node, you can use various attributes to customize the content and layout of the PDF, such as text, tables, images, page sizes, margins, headers, footers, and more. Below are the most commonly used attributes:

| **Attribute**  | **Description**                                                            | **Example**                                                   |
| -------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------- |
| `content`      | Defines the content of the PDF (text, tables, images, etc.).               | `{ "content": "Hello, World!" }`                              |
| `style`        | Specifies the style for content (font size, font family, etc.).            | `{ "style": "headerStyle" }`                                  |
| `layout`       | Defines the layout of a table (e.g., 'lightHorizontalLines', 'noBorders'). | `{ "layout": "lightHorizontalLines" }`                        |
| `pageSize`     | Defines the page size for the PDF.                                         | `{ "pageSize": "A4" }`                                        |
| `pageMargins`  | Sets the margins for the PDF (left, top, right, bottom).                   | `{ "pageMargins": [40, 60, 40, 60] }`                         |
| `header`       | Specifies a header for the PDF. Can be a static text or dynamic content.   | `{ "header": "My PDF Report" }`                               |
| `footer`       | Specifies a footer for the PDF. Can be a static text or dynamic content.   | `{ "footer": "Page {PAGE_NUM} of {PAGE_COUNT}" }`             |
| `defaultStyle` | Defines the default style for all content in the PDF.                      | `{ "defaultStyle": { "font": "Helvetica", "fontSize": 12 } }` |
| `background`   | Adds a background to the page or content area.                             | `{ "background": { "image": "imageData" } }`                  |
| `width`        | Sets the width of table cells or other elements.                           | `{ "width": 150 }`                                            |
| `height`       | Sets the height of table cells or other elements.                          | `{ "height": 50 }`                                            |
| `alignment`    | Specifies the text alignment (left, center, right).                        | `{ "alignment": "center" }`                                   |
| `border`       | Defines the border for tables or table cells (style, width, and color).    | `{ "border": [true, true, true, true] }`                      |

For additional attributes and information, refer to the [pdfmake documentation](https://pdfmake.github.io/docs/0.1/document-definition-object/){rel="&#x22;nofollow&#x22;"}, as pdfbuilder-node uses this library to generate PDFs.

Here’s a simple example of how you can use these attributes to create a basic PDF:

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

```json
{
  "content": [
    {
      "svg": "logoDataHere",
      "width": 150,
      "alignment": "center",
      "margin": [0, 0, 0, 20]
    },
    {
      "text": "Production Report - 2025",
      "style": "header"
    },
    {
      "text": "Daily Production Summary with Operator Performance",
      "style": "subheader",
      "alignment": "center",
      "margin": [0, 10, 0, 20]
    },
    {
      "layout": "lightHorizontalLines",
      "table": {
        "headerRows": 1,
        "widths": ["auto", "auto", "*", "auto", "auto", "*"],
        "body": [
          ["Date", "Shift", "Product", "Units Produced", "Defective Units", "Operator"],
          ["2025-01-01", "Morning", "Product A", "1000", "20", "John Doe"],
          ["2025-01-01", "Afternoon", "Product B", "950", "15", "Jane Smith"],
          ["2025-01-02", "Morning", "Product A", "1050", "10", "James Brown"],
          ["2025-01-02", "Afternoon", "Product C", "800", "30", "Emily Clark"],
          ["2025-01-03", "Morning", "Product B", "1100", "25", "Michael Green"],
          ["2025-01-03", "Afternoon", "Product A", "980", "18", "Sarah White"]
        ]
      }
    },
    {
      "text": "This table summarizes the daily production output across different shifts and operators. It includes total units produced and defective units recorded for quality analysis.",
      "fontSize": 12,
      "alignment": "justify",
      "margin": [0, 10, 0, 20]
    },
    {
      "text": "Internal Use Only - Manufacturing Co.",
      "style": "footer",
      "alignment": "center",
      "margin": [0, 20, 0, 0]
    }
  ],
  "styles": {
    "header": {
      "fontSize": 20,
      "bold": true,
      "alignment": "center",
      "margin": [0, 20, 0, 10]
    },
    "subheader": {
      "fontSize": 14,
      "italics": true,
      "color": "grey",
      "margin": [0, 10, 0, 20]
    },
    "footer": {
      "fontSize": 10,
      "color": "grey"
    }
  },
  "pageSize": "A4",
  "pageMargins": [40, 60, 40, 60]
}
```

This example creates a simple PDF featuring a centered logo, a title, a subtitle, a table with a light horizontal line layout, a paragraph of text, and a footer at the end. The following screenshot shows how it looks. You can customize it by adjusting the styles, layout, and content.

![Example pdf result](https://flowfuse.com/blog/2025/05/images/example-pdf.png){dataZoomable=""}*Example pdf result*

### Step 3: Creating a Flow to Generate a PDF

Let's learn how to generate a PDF using dynamic inputs. For this, we’ll use the same example PDF report shown earlier, but this time, we’ll replace the hardcoded values with dynamic input data.

1. For this guide's practical example, we will use the following SQLite flow that generates simulated production data. If you don't have the data source, you can import the flow below to follow along. After importing, deploy the flow and click the Inject node button to generate and insert the data.

When generating PDFs for your specific data, start by creating a flow to collect the information you want in the report. This data can come from sensors, databases, APIs, or even manual inputs.

::render-flow{:height='300'}
```json
[{"id":"1e73fef718bb4876","type":"group","z":"b37428694e90b2c5","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["5169b96ad66dcff6","b75fde37ea431d84","a571bbd7b0c0cb25"],"x":14,"y":59,"w":812,"h":82},{"id":"5169b96ad66dcff6","type":"inject","z":"b37428694e90b2c5","g":"1e73fef718bb4876","name":"Create Table","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":130,"y":100,"wires":[["b75fde37ea431d84"]]},{"id":"b75fde37ea431d84","type":"sqlite","z":"b37428694e90b2c5","g":"1e73fef718bb4876","mydb":"1ae6d7f7fdb60191","sqlquery":"fixed","sql":"CREATE TABLE IF NOT EXISTS production_report (\n    id INTEGER PRIMARY KEY AUTOINCREMENT,\n    date TEXT NOT NULL,\n    shift TEXT NOT NULL,\n    product TEXT NOT NULL,\n    units_produced INTEGER NOT NULL,\n    defective_units INTEGER NOT NULL,\n    operator TEXT NOT NULL\n);","name":"","x":440,"y":100,"wires":[["a571bbd7b0c0cb25"]]},{"id":"a571bbd7b0c0cb25","type":"debug","z":"b37428694e90b2c5","g":"1e73fef718bb4876","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":720,"y":100,"wires":[]},{"id":"1ae6d7f7fdb60191","type":"sqlitedb","db":"productiondata.sqlite","mode":"RWC"},{"id":"ccca7810c6b3db41","type":"group","z":"b37428694e90b2c5","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["19ad08d3015ef8f2","b706e4aa8a2d0740","f32cdc1dd16b56b7","3708b00ae17defa5","c4464e3454a8805e","2df338e18c9a60d5"],"x":14,"y":179,"w":1332,"h":82},{"id":"19ad08d3015ef8f2","type":"sqlite","z":"b37428694e90b2c5","g":"ccca7810c6b3db41","mydb":"1ae6d7f7fdb60191","sqlquery":"prepared","sql":"INSERT INTO production_report (\n    date,\n    shift,\n    product,\n    units_produced,\n    defective_units,\n    operator\n) VALUES (\n    $date,\n    $shift,\n    $product,\n    $units_produced,\n    $defective_units,\n    $operator\n);\n","name":"","x":1060,"y":220,"wires":[["2df338e18c9a60d5"]]},{"id":"b706e4aa8a2d0740","type":"inject","z":"b37428694e90b2c5","g":"ccca7810c6b3db41","name":"Click to generate and insert data","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":190,"y":220,"wires":[["f32cdc1dd16b56b7"]]},{"id":"f32cdc1dd16b56b7","type":"function","z":"b37428694e90b2c5","g":"ccca7810c6b3db41","name":"Generate Simulated Production Data","func":"const products = [\"Widget A\", \"Widget B\", \"Gadget X\", \"Component Z\"];\nconst operators = [\"John Matthews\", \"Sarah Lee\", \"Amit Kumar\", \"Rita Patel\"];\nconst shifts = [\"A\", \"B\", \"C\"];\n\nfunction getRandomInt(min, max) {\n    return Math.floor(Math.random() * (max - min + 1)) + min;\n}\n\nconst data = [];\n\nfor (let i = 0; i < 10; i++) {\n    const date = new Date();\n    date.setDate(date.getDate() - i); // Last 10 days\n\n    data.push({\n        date: date.toISOString().split('T')[0],\n        shift: shifts[getRandomInt(0, shifts.length - 1)],\n        product: products[getRandomInt(0, products.length - 1)],\n        units_produced: getRandomInt(400, 600),\n        defective_units: getRandomInt(0, 10),\n        operator: operators[getRandomInt(0, operators.length - 1)]\n    });\n}\n\nmsg.payload = data;\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":490,"y":220,"wires":[["3708b00ae17defa5"]]},{"id":"3708b00ae17defa5","type":"split","z":"b37428694e90b2c5","g":"ccca7810c6b3db41","name":"","splt":"\\n","spltType":"str","arraySplt":1,"arraySpltType":"len","stream":false,"addname":"","property":"payload","x":710,"y":220,"wires":[["c4464e3454a8805e"]]},{"id":"c4464e3454a8805e","type":"change","z":"b37428694e90b2c5","g":"ccca7810c6b3db41","name":"","rules":[{"t":"set","p":"params","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"params.$date","pt":"msg","to":"payload.date","tot":"msg"},{"t":"set","p":"params.$shift","pt":"msg","to":"payload.shift","tot":"msg"},{"t":"set","p":"params.$product","pt":"msg","to":"payload.product","tot":"msg"},{"t":"set","p":"params.$units_produced","pt":"msg","to":"payload.units_produced","tot":"msg"},{"t":"set","p":"params.$defective_units","pt":"msg","to":"payload.defective_units","tot":"msg"},{"t":"set","p":"params.$operator","pt":"msg","to":"payload.operator","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":860,"y":220,"wires":[["19ad08d3015ef8f2"]]},{"id":"2df338e18c9a60d5","type":"debug","z":"b37428694e90b2c5","g":"ccca7810c6b3db41","name":"debug 3","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1240,"y":220,"wires":[]}]
```
::

2. Drag an **Inject** node onto the canvas.
3. Drag an **SQLite** node and connect it to the Inject node. Configure the **SQLite** node with the same database to generate the simulated data. Set the SQL Query type to "fixed statement" and use the following query:

```sql
SELECT * FROM production_report;
```

4. Drag a **Function** node onto the canvas and paste the following JavaScript code. When generating PDFs for your specific data, make sure to adjust the code to match your data structure.

```javascript
// Initialize table body with headers
const tableBody = [
    ['Date', 'Shift', 'Product', 'Units Produced', 'Defective Units', 'Operator']
];

const logo = `<replace-this-your-logo-svg`

// Loop through data rows from SQLite (msg.payload)
for (const row of msg.payload) {
    tableBody.push([
        row.date,
        row.shift,
        row.product,
        row.units_produced.toString(),
        row.defective_units.toString(),
        row.operator
    ]);
}

const docDefinition = {
    content: [
        {
            svg: logo,
            width: 150, // Adjust the logo size as needed
            alignment: 'center',
            margin: [0, 0, 0, 20]
        },
        // Header
        {
            text: 'Production Report - 2025',
            style: 'header'
        },

        // Subheader
        {
            text: 'Daily Production Summary with Operator Performance',
            style: 'subheader',
            alignment: 'center',
            margin: [0, 10, 0, 20]
        },

        // Table
        {
            layout: 'lightHorizontalLines',
            table: {
                headerRows: 1,
                widths: ['auto', 'auto', '*', 'auto', 'auto', '*'],
                body: tableBody
            }
        },

        // Description
        {
            text: 'This table summarizes the daily production output across different shifts and operators. It includes total units produced and defective units recorded for quality analysis.',
            fontSize: 12,
            alignment: 'justify',
            margin: [0, 10, 0, 20]
        },

        // Footer
        {
            text: 'Internal Use Only - Manufacturing Co.',
            style: 'footer',
            alignment: 'center',
            margin: [0, 20, 0, 0]
        }
    ],

    styles: {
        header: {
            fontSize: 20,
            bold: true,
            alignment: 'center',
            margin: [0, 20, 0, 10]
        },
        subheader: {
            fontSize: 14,
            italics: true,
            color: 'grey',
            margin: [0, 10, 0, 20]
        },
        footer: {
            fontSize: 10,
            color: 'grey'
        }
    },

    pageSize: 'A4',
    pageMargins: [40, 60, 40, 60]
};

msg.payload = docDefinition;
return msg;
```

5. Drag a **pdfbuilder** node onto the canvas. Set the input property to `msg.payload`, set output type to Buffer, and output property to `msg.payload`.
6. Drag a **Write File**node, configure it with:
   - Filename: test.pdf
   - Action: Overwrite file
   - Add newline (\n) to each payload?: Checked
7. Connect the **SQLite** node to the **Function** node, then to the **pdfbuilder** node, and finally to the **Write File** node.
8. Deploy the flow and click inject node to generate the pdf.

Once the PDF is generated, you can find it in the `.node-red` directory.

However, if you want to share the PDF with others, display it on the dashboard, and provide a download button, you can use the HTTP API, an iframe, and a few supporting nodes. Let's walk through how to do that next.

### Step 4: Serving the PDF via HTTP and Previewing It on the Dashboard

In this step, we’ll make the generated PDF accessible through a web interface. You’ll be able to preview the PDF directly in the browser and embed it in your FlowFuse dashboard for a smooth, integrated experience. We’ll also add a download button so users can easily save the report. Instead of manually retrieving the file, we’ll create an HTTP endpoint to serve the PDF and use an iframe to display it.

#### Exposing the PDF via HTTP

1. Drag the **http-in** node onto the canvas. Set the method to 'GET' and the URL to `/report.pdf`. This will create an HTTP endpoint for retrieving the generated PDF.
2. Connect the **http-in** node to the **SQLite** node. This ensures that when a request is made to this endpoint, the necessary data is fetched from the database.
3. After the **Write File** node in your flow, add a **Change** node. Connect it to the **Write File** node, and configure it to set the following headers for the HTTP response:
   - Set `msg.headers` to:
   ```json
   {   
      'Content-Type': 'application/pdf',   
      'Content-Disposition': 'inline; filename="report.pdf"' 
   }
   ```
4. Drag the **HTTP-response** node onto the canvas and connect it to the Change node.
5. Deploy the flow

Now, this will send the generated PDF as a response to the incoming HTTP request, allowing it to be previewed in the browser. You can check by entering the URL:

`https://<your-instance-name>.flowfuse.cloud/report.pdf`

### Embedding the PDF on the Dashboard and Adding the Download Button

Now, let's embed the PDF into the dashboard:

1. Drag a **ui-event** node onto the canvas and configure it with the appropriate UI base settings.
2. Next, drag an **iframe** node onto the canvas.
   - Select the correct group where the PDF should be displayed.
   - Adjust the size according to your preferences.
   - In the URL field, enter:
   ```text
   https://<your-instance-name>.flowfuse.cloud/report.pdf
   ```
3. Click Done and Deploy the flow.

Once deployed, when you open the dashboard, the generated PDF will be embedded and displayed directly on the dashboard page.

Now, let's add a download button:

4. Drag a **ui-template** widget onto the canvas and paste the following HTML code into it:

```html
<div style="text-align:center; margin-top: 20px;">
    <a href="https://<your-instance-name>.flowfuse.cloud/report.pdf" download="report.pdf"
        style="display: inline-block; background-color: #4f7a28; color: white; padding: 14px 20px; text-align: center; text-decoration: none; font-size: 16px; border-radius: 5px; box-shadow: 0 4px 8px rgba(0, 0, 0, 0.2); transition: background-color 0.3s ease;">
        Download Report
    </a>
</div>
```

5. Deploy the flow.

![Dashboard displaying embedded PDF with a download button](https://flowfuse.com/blog/2025/05/images/dashboard-with-embedded-report.png){dataZoomable=""}&#x2A;[Dashboard displaying embedded PDF with a download button]*

## Final thought

Automating PDF report generation in Node-RED is a great way to save time and effort. Using tools like the node-red-contrib-pdfmake node, you can quickly turn your data into well-designed PDFs without manual work. If you want to save time and avoid the setup process, you can directly use our ready-made [PDF generation blueprint](https://flowfuse.com/blueprints/manufacturing/pdf-report-generator/). It’s an easy way to get started and generate professional reports quickly.


# Announcing Node-RED Con 2025: A Community Conference on Industrial Applications

At FlowFuse, our commitment to the Node-RED community is at the heart of everything we do. That's why we are thrilled to announce our support as a sponsor for **Node-RED Con 2025**, a free, online conference taking place on &#x2A;*Tuesday, November 4, 2025!**

This year's event is dedicated to exploring a vital theme: **Node-RED applications in industry**. It’s a fantastic opportunity for developers, engineers, and innovators to connect and share how Node-RED is being used to solve real-world challenges.

## The Agenda is Underway

The conference agenda is built from community submissions, and the Call for Papers received a great response. The organizing team reports receiving many excellent submissions, so we're in for some really interesting sessions.

The event will offer sessions in three different categories:

- **Full Talks & Demos (25-30 mins):** Focused on industrial use cases, IoT architectures, and edge computing.
- **Lightning Talks (8-10 mins):** Showcasing fun, creative, or inspiring projects.
- **Expert Panelists:** To discuss the future of industrial automation with Node-RED.

## Registration is Now Open

Head to [the Node-RED Con 2025 official page](https://nrcon.nodered.org/){rel="&#x22;nofollow&#x22;"} to secure your spot. Join the live event on November 4, ask your questions, be part of the conversation, this only happens once a year, and you won't want to miss what the community has built!


# Part 2: Building an Andon Task Manager with FlowFuse

In [Part 1](https://flowfuse.com/blog/2025/05/building-andon-task-manager-with-ff/), we introduced the concept of an Andon Task Manager, designed to streamline issue reporting and resolution on the factory floor, and outlined the system’s key features, user roles, and dashboard layout.

In this part 2, we move from planning to implementation. The focus now shifts to building the actual system using [FlowFuse Dashboard](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"} (Node-RED Dashboard 2.0), hosted on the FlowFuse platform. We will begin by developing the **Lines view** for regular users, along with a line selection menu. The Department View and Admin interface will follow in a later part of the series.

## Getting Started

To simplify the development process, the implementation is divided into the following key sections:

- Initialize SQLite Database
- Seed Demo Data: Departments & Lines
- Build Line Selection Menu
- Enable URL-Based Dashboard Access
- Create Live Request Fetch Flow (Per Line)
- Render Request Data in a Table
- Setting Up Visual Alerts and Timestamp Formatting
- Highlight Requests with CSS & Add Buttons to Update Request Status
- Create New Request Submission Flow

Before proceeding, a basic understanding of Node-RED is recommended. If you are new to Node-RED, consider going through this [free Node-RED Fundamentals Course](https://node-red-academy.learnworlds.com/course/node-red-getting-started){rel="&#x22;nofollow&#x22;"} to get started.

> **Tip:** Organize your flows into clearly defined groups. For reference, images of each flow are provided. Please use the exact names given to each flow, this will help ensure consistency and make it easier to navigate back to specific flows when referenced later.

### Prerequisites

Before you begin building the Andon Task Manager with FlowFuse, make sure you have the following:

- **Running FlowFuse Instance:** Make sure you have a FlowFuse instance set up and running. If you don't have an account, check out the [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and [learn](https://flowfuse.com/docs/user/introduction/#creating-a-node-red-instance) how to create an instance.
- **@flowfuse/node-red-dashboard:** Ensure you have FlowFuse Dashboard (also known as Node-RED Dashboard 2.0 in the community) installed.
- **SQLite Contrib Node:** Install `node-red-contrib-sqlite` to handle local data storage.
- **FlowFuse Multi-user Andon:** Install `@flowfuse/node-red-dashboard-2-user-addon` to enable multi-user support.
- **Enable FlowFuse User Authentication:** [Enable FlowFuse User Authentication](https://flowfuse.com/blog/2024/04/displaying-logged-in-users-on-dashboard/#enabling-flowfuse-user-authentication) on your FlowFuse instance.
- **Moment Contrib Node:** Install `node-red-contrib-moment` for date and time formatting.

### Initialize SQLite Database

The first step is to set up a database to store requests and their updates.

1. Drag an **Inject** node onto the canvas and configure it to trigger on Deploy, after a delay of 0.1 seconds.
2. Drag an **SQLite*&#x2A; node onto the canvas. Double-click and click the &#x2A;*+** icon to add a new database configuration.
3. Give the database a name and set the mode to **Read-Write-Create**. Click **Add** to save.
4. Set **SQL Query** to **Fixed statement** and enter:
   ```sql
   CREATE TABLE IF NOT EXISTS requests (
     rowid INTEGER PRIMARY KEY,
     line TEXT NOT NULL,
     support TEXT NOT NULL,
     requested TEXT NOT NULL,
     acknowledged TEXT,
     resolved TEXT,
     notes TEXT
   );
   ```
5. Connect the **Inject** node to the SQLite node.
6. Click **Deploy**.

![Node-RED flow showing an Inject node connected to an SQLite node to create a requests table in the database.](https://flowfuse.com/blog/2025/06/images/sqlite-create-flow.png){dataZoomable=""}&#x2A;Flow to initialize the SQLite database and create the requests table.*

Once deployed, this will create the SQLite database and `requests` table if it does not already exist.

### Seed Demo Data: Departments & Lines

As discussed in the planning section, only the admin role will have the ability to add new departments and lines. Since the admin feature is not yet available, we will populate demo data using a predefined flow to allow ourself to test the application while the standard user interface is being developed.

::render-flow{:height='300'}
```json
[{"id":"d5dd9bfc599374d4","type":"tab","label":"Populate with demo support areas and lines","disabled":false,"info":"","env":[]},{"id":"6471824e24f18939","type":"group","z":"d5dd9bfc599374d4","name":"Add demo production line and department","style":{"label":true},"nodes":["34c733b480e41a13","4e46ae25d198fd1b","882e29d2dcc9326c","399bd159f46c7427","5001c1cdf6661f88"],"x":34,"y":39,"w":1302,"h":122},{"id":"34c733b480e41a13","type":"inject","z":"d5dd9bfc599374d4","g":"6471824e24f18939","name":"Add production lines and department for testing","props":[],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":260,"y":100,"wires":[["4e46ae25d198fd1b","399bd159f46c7427"]]},{"id":"4e46ae25d198fd1b","type":"switch","z":"d5dd9bfc599374d4","g":"6471824e24f18939","name":"Is lines undefined?","property":"#:(persistent)::lines","propertyType":"global","rules":[{"t":"istype","v":"undefined","vt":"undefined"}],"checkall":"true","repair":false,"outputs":1,"x":770,"y":80,"wires":[["882e29d2dcc9326c"]]},{"id":"882e29d2dcc9326c","type":"change","z":"d5dd9bfc599374d4","g":"6471824e24f18939","name":"Store lines to context store","rules":[{"t":"set","p":"#:(persistent)::lines","pt":"global","to":"[{\"value\":\"T1\",\"label\":\"T1\"},{\"value\":\"T2\",\"label\":\"T2\"}]","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":1140,"y":80,"wires":[[]]},{"id":"399bd159f46c7427","type":"switch","z":"d5dd9bfc599374d4","g":"6471824e24f18939","name":"Is departments undefined?","property":"#:(persistent)::departments","propertyType":"global","rules":[{"t":"istype","v":"undefined","vt":"undefined"}],"checkall":"true","repair":false,"outputs":1,"x":800,"y":120,"wires":[["5001c1cdf6661f88"]]},{"id":"5001c1cdf6661f88","type":"change","z":"d5dd9bfc599374d4","g":"6471824e24f18939","name":"Store departments to context store","rules":[{"t":"set","p":"#:(persistent)::departments","pt":"global","to":"[{\"value\":\"Maintenance\",\"label\":\"Maintenance\"},{\"value\":\"Stores\",\"label\":\"Stores\"},{\"value\":\"Quality\",\"label\":\"Quality\"}]","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":1170,"y":120,"wires":[[]]}]
```
::

1. Import the provided demo flow.
2. **Deploy** the flow.

This will store demo lines and departments in the global context as `global.lines` if not already present.

### Build Line Selection Menu

Now, let us create a new page and menu item for Production Lines. This page will list all currently available production lines, making it easier to navigate through them.

1. Drag a **ui-event** node onto the canvas to detect page navigation.
2. Drag a **change**node and configure it to:
   - Set `msg.payload.lines` to `global.get("lines")`
3. Drag a **ui-template** node onto the canvas. Create a new page with name “Line Menu” and a group.
4. Paste the following into the template:

```html
<template>
  <v-container>
    <v-row>
      <v-col>
        <h3>Production Lines</h3>
      </v-col>
    </v-row>

    <v-row class="scrollable-row" no-gutters>
      <v-col v-for="(btn, index) in lines" :key="index" cols="auto">
        <v-btn :href="`/dashboard/lines?line=${btn.value}`" class="custom-btn" rounded>
          {{ btn.label }}
        </v-btn>
      </v-col>
    </v-row>

    <v-alert v-if="selectedLine" type="success" class="mt-3">
      Selected Line: {{ selectedLine }}
    </v-alert>
  </v-container>
</template>

<script>
export default {
  data() {
    return {
      selectedLine: '',
      lines: []
    };
  },
  methods: {
    updateButtonContent(data) {
      this.lines = (data.lines || []).sort((a, b) => a.label.localeCompare(b.label));
    }
  },
  mounted() {
    this.lines = [];
    this.$socket.on('msg-input:' + this.id, (msg) => {
      this.updateButtonContent(msg.payload);
    });
  }
};
</script>

<style scoped>
.scrollable-row {
  display: flex;
  overflow-x: auto;
  padding: 10px 0;
  flex-wrap: wrap;
}
.scrollable-row .v-col {
  flex-shrink: 0;
  margin-bottom: 10px;
}
.scrollable-row {
  min-height: 60px;
}
.custom-btn {
  background-color: rgb(32, 44, 52) !important;
  color: white !important;
  margin-right: 12px;
  padding: 8px 16px;
}
.custom-btn:hover {
  background-color: rgb(54, 70, 86) !important;
}
</style>
```

5. Deploy the flow.

Once deployed, the dashboard will show buttons for each production line. Clicking a line redirects the user to a page with following url:

```text
https://<your-instance-name>/dashboard/lines?line=T1
```

![Node-RED editor showing the flow setup for generating a menu of production lines using ui-event, change, and ui-template nodes.](https://flowfuse.com/blog/2025/06/images/menu-for-lines-flow.png){dataZoomable=""}&#x2A;Node-RED flow to create a dynamic menu for production lines on the dashboard.*

![FlowFuse Dashboard displaying styled buttons for each production line, enabling quick navigation to specific line pages.](https://flowfuse.com/blog/2025/06/images/menu-for-lines.png){dataZoomable=""}&#x2A;Dashboard view showing production line buttons generated from the flow.*

The "line" URL parameter will be used in the next section to store the user's selected production line.

### Enable URL-Based Dashboard Access

In this section, we’ll build a flow that allows users to directly access the dashboard using a URL with a line parameter (e.g., ?line=T1). The flow will validate this parameter and store the selected line for each user session. If the parameter is missing or invalid, the user will be redirected to a Not Found page.

To achieve this, we need to:

- Configure the dashboard to expose client-specific metadata.
- Create a flow that validates the line parameter from the URL.
- Store the user’s selected line using session-aware context data.

#### Configuring Dashboard Widgets to Include Client Information

To ensure client data is available in your flows, follow these steps:

1. Open the **Dashboard 2.0** sidebar.
2. Switch to the **Client Data** tab.
3. Enable the option &#x2A;*“Include client data”**.
4. Tick the checkbox in front of:
   - ui-control
   - ui-template
   - ui-button
   - ui-text-input
   - ui-dropdown
   - ui-notification
5. **Deploy** the updated configuration.

![Enabling client data in the Dashboard 2.0 settings to include metadata from specific widgets.](https://flowfuse.com/blog/2025/06/images/client-data-configuration.png){dataZoomable=""}&#x2A;Dashboard 2.0 settings to include client metadata from selected widgets like buttons and templates.*

With this setting enabled, the selected widgets will include client-related metadata in their output messages under the `msg._client` property. This metadata is essential for building session-aware features in the Dashboard.

#### Building a Dashboard Flow for URL Access, Line Validation, and User Selection

In this section, we'll build a Node-RED flow that handles dashboard access via direct URLs, validates the line parameter, and stores the selected line per user session using client metadata. This ensures that each user's line selection is tracked independently and that invalid or missing parameters are handled gracefully.

The flow performs the following key tasks:

- Detects when a user accesses the dashboard using a URL containing a line parameter.
- Validates the parameter against a list of predefined production lines.
- Stores the selected line using session-aware (client-specific) data.
- Redirects the user appropriately based on the validity of the parameter.

**Steps to Build the Flow:**

1. Drag a **ui-event node** onto the canvas and configure it with the correct UI base path.
2. Drag a **switch node** and name it "Is it a pageview event?" and configure it with the property `msg.topic` and add the following condition:
   - `== $pageview`
3. Drag another **switch node** and name it "Has line key?" and configure it with the property `msg.payload.page.params.line`, with two conditions:
   - has key `line`
   - is empty
4. Connect the **ui-event node** to the first switch node (labeled Is it a pageview event?). Then, connect the first output of this switch node to the second switch node (labeled Has line key?). This checks whether the page was accessed via URL and if a line parameter is present.
5. Drag a `function` node and name it "Extract Labels from Lines" and paste the following code:
   ```javascript
   let lines = global.get('lines', 'persistent') || [];
   let labels = [
      ...lines.map(obj => obj.label),
   ];
   msg.payload.labels = labels;
   return msg;
   ```

This retrieves the list of available lines from the persistent global context, extracts their labels, and creates an array for easier verification of whether the user selected line is present.

6. Drag a **change node**and name it "Store line selection":
   - Set `global.store[msg._client.socketId].line` to `msg.payload`.
7. Drag another **switch node** and name it "Is the currently accessed page 'Lines'?":

- is equal to "Lines"

8. Connect the **function node** (Extract Labels from Lines) and the **change node** (Store line selection) to the first output of the **switch node** (Has line key?).
9. Drag another `switch` node and name it "Is line valid?" and set the property to `msg.payload.labels`and add following conditions:
   - contains `global.store[msg._client.socketId].line`
10. For the first output of the `switch` node (Is the currently accessed page 'Lines'?), drag a **change**node and name it "Redirect the user to the All Lines menu" and Configure it to:
    - Set `msg.payload` to `"All Lines"`
11. Drag a **ui-control node** onto the canvas and connect it to the **change node** (Redirect the user to the All Lines menu). This node will handle the redirection or display feedback on the dashboard.

This checks whether the selected line is valid by comparing it with the list of known line labels.

12. For the second output of the switch node (Is line valid?), drag a switch node and give it name "Is the currently accessed page 'Lines'?" and Set property to `msg.payload.page.name` and add following condition to check against:

- \== "Lines"
- Otherwise

13. For the first output of the switch node ((Is the currently accessed page 'Lines'?), drag a change node and configure it to:
    \- Set `msg.payload` to "Incorrect Link"
14. Drag a ui-control node onto the canvas and configure it with the correct UI base path and connect it the change node (Redirect to Not found page).
15. Deploy the changes.

![Flow for handling dashboard navigation, validating URL parameters, and assigning selected production lines to individual client sessions.](https://flowfuse.com/blog/2025/06/images/accessing-production-lines.png){dataZoomable=""}&#x2A;Flow for managing URL-based access, validating line parameters, and storing client-specific selections on the OEE dashboard.*

### Create Live Request Flow (Per Line)

Let’s build the flow to retrieve the data now based on the user selection.

1. Drag a `Template` widget onto the canvas.
2. Double-click the Template widget to open its configuration.
3. Set the scope to `ui` and select the appropriate UI Base.
4. Paste the following script into the content field. This script triggers every second and sends a message that includes the current user's client data:
   ```html
   <script>
     export default {
       mounted() {
         // Set an interval to update the message every second
         this.intervalId = setInterval(() => {
           this.send('Component has loaded');
         }, 1000);
       },
       beforeUnmount() {
         // Clear the interval when the component is about to be destroyed
         clearInterval(this.intervalId);
       },
     };
   </script>
   ```
5. Drag a `Change` node and name it "Set params".
6. Configure the Change node with the following rules:
   - Set `msg.params.$line` to `global.store[msg._client.socketId].line`
   - Set `msg.query` to `"line"`
7. Drag a `Template` node onto the canvas.
8. Double-click the Template node and set the property to `msg.topic`.
9. Paste the following SQL query into the content field:
   ```sql
   SELECT * FROM requests WHERE "{{query}}" = "{{line}}" AND resolved IS NULL
   ```
10. Drag a `Markdown` widget and name it "Show currently selected line".
11. Create a new group in the UI for the Markdown widget to render into.
12. Enter the following content into the Markdown widget:
    ```html
    <h1 style="text-align: center;">Line: {{ msg?.line }}</h1>
    ```

![Dashboard view showing the title of the selected production line centered at the top.](https://flowfuse.com/blog/2025/06/images/lines-page-with-tittle-of-selected-line.png){dataZoomable=""}&#x2A;The dashboard displays the selected production line name, retrieved from the client context, rendered using a Markdown widget.*

13. Drag a `SQLite` node onto the canvas.
14. Select the appropriate database configuration.
15. Set the node to use the SQL query via "Prepared Statement".
16. Connect the `Template` widget to `Change` node and `Template` node to `SQLite` node.
17. Drag a `link-out` node onto the canvas and connect it to the `SQLite` node.
18. Deploy the changes.

![Node-RED flow to fetch live requests for a selected production line using client context and SQLite query.](https://flowfuse.com/blog/2025/06/images/retrive-data.png){dataZoomable=""}&#x2A;Flow that triggers periodic queries for open requests specific to the user’s selected line using the client session and a SQLite database.*

### Preparing Data Rendering it in a Table

Once the data is retrieved, it needs to be validated, formatted, and routed appropriately for display. In this section, a flow will be built to check whether any unresolved requests exist for the selected production line. If there are no requests, a message will be shown to the user. Otherwise, the data will be processed and rendered in a table format using Dashboard widgets.

1. Drag a **link-in node** onto the canvas and connect it to the last **link-out node**.
2. Add a **switch node** to check whether the `msg.payload` is empty, name it "Is Payload empty?".
   - Configure the switch with the following conditions:
     - `msg.payload is empty`
     - `Otherwise`
3. Drag a **change node**, name it "Show 'no outstanding request' message" and configure it to set a message when the payload is empty:
   - Set `msg.payload` to `"There are no outstanding requests"`
4. Connect this **change node** to the first output of the switch node ("Is Payload empty?").
5. Drag another **change node**, name it "Remove 'no outstanding request' message" and configure it as follows:
   - Set `msg.payload` to an empty string `""`
6. Connect this second **change node** to the second output of the switch node ("Is Payload empty?").
7. Drag a **text widget**, name it "Text Widget for Message", onto the canvas, double-click it, and add a new group in the "Lines" page to render the message.
8. Connect the **text widget** ("Text Widget for Message") to both **change nodes** that are setting the text message ("Show 'no outstanding request' message" and "Remove 'no outstanding request' message").
9. Drag another **link-out node** onto the canvas and connect it to the second output of the switch node ("Is Payload empty?") that checks whether `msg.payload` is empty.
10. Drag another **link-in** onto the canvas.
11. Drag a **split node**, name it "Split Node", onto the canvas and connect it to the **link-in node**.
12. Drag a **link-out node** and connect it to the **split node**.
13. Deploy the changes.

![Flow that checks if unresolved requests exist, sends an appropriate message when none are found, or prepares the data for tabular rendering](https://flowfuse.com/blog/2025/06/images/preparing-data.png){dataZoomable=""}&#x2A;Flow that checks if unresolved requests exist, sends an appropriate message when none are found, or prepares the data for tabular rendering.*

### Setting Up Visual Alerts and Timestamp Formatting

To enhance the visibility of production line requests, this section focuses on setting up visual alerts based on the age of each request and formatting timestamps in a user-friendly way. The created timestamp is always shown using relative time (e.g., "5 minutes ago"). For acknowledged and resolved, relative formatting is applied only when those timestamps are available. This improves readability and makes it easier to identify requests that are pending action.

1. Drag a **link-in node** and a **function node** onto the canvas. Name the **function node** as "Highlight Old Requests" and open it.
2. Paste the following JavaScript code into the **function node**:

```javascript
const requested = msg.payload.requested;
const now = Date.now();

const requestedTime = new Date(requested).getTime();
const difference = now - requestedTime;

const oldRequestThreshold = global.get('oldRequestThreshold');
const veryOldRequestThreshold = global.get('veryOldRequestThreshold');
const alertActivationThreshold = global.get('alertActivationThreshold');

if (difference > (veryOldRequestThreshold * 60 * 1000)) {
   msg.payload.class = 'older';
   if (difference > (alertActivationThreshold * 60 * 1000)) {
       msg.payload.alert = true;
   }
   return msg;
}
else if (difference > (oldRequestThreshold * 60 * 1000)) {
   msg.payload.class = 'old';
   if (difference > (alertActivationThreshold * 60 * 1000)) {
       msg.payload.alert = true;
   }
   return msg;
}
else {
   if (difference > (alertActivationThreshold * 60 * 1000)) {
       msg.payload.alert = true;
   }
   msg.payload.class = 'normal';
   return msg;
}
```

3. Connect the link-in node to the function node.
4. Drag a date time formatter node onto the canvas. Name it "Format Requested Time" and double-click it to configure.
   - Set outputFrom to fromNow.
   - Set both input and output to `msg.payload.requested`.
5. Connect the function node to the date time formatter node.
6. Drag a link-out node and connect it to the function node.
7. Drag a switch node onto the canvas. Name it "Check if Acknowledged is null". Set the property to `msg.payload.acknowledged`, and add the following conditions:
   - is null
   - Otherwise
8. Connect the function node to the switch node.
9. Drag a second date time formatter node onto the canvas. Name it "Format Acknowledged Time".
   - Set outputFrom to fromNow.
   - Set both input and output to `msg.payload.acknowledged`.
10. Connect the second date time formatter node to the second output of the switch node ("Check if Acknowledged is null").
11. Drag another switch node onto the canvas. Name it "Check if Resolved is null". set the property to `msg.payload.resolved`. Add the following conditions:

- is null
- Otherwise

12. Connect this switch node ("Check if Resolved is null") to the output of the second date time formatter ("Format Acknowledged Time") node and to the first output of the first switch node ("Check if Acknowledged is null").
13. Drag a third date time formatter node onto the canvas. Name it "Format Resolved Time" and set outputFrom to fromNow. Set both input and output to `msg.payload.resolved`.
14. Connect this third date time formatter node to the second output of the second switch node ("Check if Resolved is null") .
15. Drag a link-out node and connect it to the third date time formatter node.
16. Drag another link-out node and connect it to the first output of the second switch node. Name it "Link to First Switch Output".
17. Deploy the changes.

![Dashboard view displaying a highlighted request entry with visual emphasis based on request age.](https://flowfuse.com/blog/2025/06/images/highlighted-requst.png){dataZoomable=""}&#x2A;Dashboard showing a request visually highlighted based on how long ago it was made, with applied styling and alert classification.*

![Node-RED flow that includes nodes for assigning visual alert classes and formatting timestamps using relative time.](https://flowfuse.com/blog/2025/06/images/visual-alert-and-timestamp-formatting.png){dataZoomable=""}&#x2A;Flow for setting visual alert classes and formatting timestamps like "5 minutes ago" to enhance clarity and urgency of displayed requests.*

## Highlight Requests with CSS & Add Buttons to Update Request Status

We have the data prepared, the class property added to each request message, and the timestamp formatted for better readability. In this section, we will add &#x2A;*'Resolve'*&#x2A; and &#x2A;*'Acknowledge'** buttons for each request to update its status and apply CSS classes based on the `status` property for visual highlighting.

1. Drag a **link-in** node onto the canvas and connect it to the last **link-out** node.
2. Drag a switch node, name it "Is acknowledged null?", and set the property to `msg.payload.acknowledged`. Add the following conditions:
   - is null
   - otherwise
3. Drag a **template node*&#x2A;, name it &#x2A;*"Build ack link"**, set the property to `msg.payload.acknowledged`, and add the following Mustache:
   ```html
   <a href="/dashboard/lines?line={{line}}&action=ack&request={{payload.rowid}}" style="color: #000000" class="{{payload.class}}">ACKNOWLEDGE</a>
   ```
4. Connect the **link-in** node to the **switch** node. Connect the **first output** of the switch node ("Is acknowledged null?") to the input of the **template** node.
5. Drag another switch node, name it "Is resolved null?", set the property to `msg.payload.resolved`, and add the following conditions:
   - is null
   - otherwise
6. Drag a **template node**, give it name "Build res link", set the property to `msg.payload.resolved`, and add the following Mustache:
   ```html
   <a href="/dashboard/lines?line={{line}}&action=res&request={{payload.rowid}}" style="color: #000000">RESOLVE</a>
   ```
7. Connect the input of this second switch node ("Is resolved null?") to the **second output** of the previous switch node (`acknowledged` switch), then connect the **first output** of the `resolved` switch node to the input of the second **template** node.
8. Drag a **link-out** node and connect both outputs of the `resolved` switch node to this link-out.
9. Deploy the changes.

![Adding 'Acknowledged' and 'Resolved' buttons for each request in the table](https://flowfuse.com/blog/2025/06/images/add-request-update-button.png){dataZoomable=""}&#x2A;Adding action buttons to update the status of each request directly from the dashboard table.*

### Adding a Mechanism to Update the Status of a Request in the Database

1. Drag **ui event widget** onto the canvas and configure it with the correct ui base.
2. Drag **change node** onto the canvas and add the following element:
   - Set `msg.params` to `{}`
   - Set `msg.params.$request` to `msg.payload.query.request`
3. Drag **Date/Time Formatter node** onto the canvas and set input format to "timestamp: milliseconds since epoch" and output to `msg.now`.
4. Drag **switch node** onto the canvas, set property to `msg.query.action`, and add the following conditions to check against:
   - \== ack
   - \== res
   - otherwise
5. Drag two SQLite nodes onto the canvas, select the correct database configuration for both, and set the query type to 'Prepared Statement'.
6. For the **first**, set the following sql query:
   ```sql
   UPDATE requests 
   SET acknowledged = $now
   WHERE rowid = $request 
   AND acknowledged IS NULL
   ```
7. For the **second**, set the following sql query:
   ```sql
   UPDATE requests 
   SET resolved = $now
   WHERE rowid = $request 
   AND resolved IS NULL 
   ```
8. Connect the **ui event widget** to **change node**, **change node** to **date/time formatter node**, **date/time formatter** to **switch node**, and:

- **switch node first output** to first **first sqlite node**
- **switch node second output** to second **second sqlite node**

![Flow for the mechanism to update request status](https://flowfuse.com/blog/2025/06/images/update-request-status.png){dataZoomable=""}:br&#x2A;Flow that handles the update of request status based on user actions (Acknowledged or Resolved).*

### Render Request Data in a Table

Now, let's display the prepared data in a table. To do this, we'll use a **ui\_table** widget. However, before displaying, we need to convert the data back into an array, as we are currently spilling array data retrieved from the database into a single message.

1. Drag a **link-in** node onto the canvas and connect it to the **last link-out** node.
2. Drag a **join** node onto the canvas and connect it to the **link-in** node. Double-click on the join node and set the mode to **automatic**.
3. Drag another **link-out** node and connect it to the **join** node.
4. Drag a **link-in** node and connect it to the **last link-out** node.
5. Drag a **ui\_table** widget onto the canvas and double-click to configure.
6. Create a **new group** on the *lines* page.
7. Set **Action** to `replace` and **Interaction** to `none`.
8. Untick the **Auto Calculate Columns** option.
9. Add the following column elements:
   - Key: rowid, Label: Request, Align: Left, Type: Text
   - Key: line, Label: Line, Align: Left, Type: Text
   - Key: support, Label: Support, Align: Left, Type: Text
   - Key: requested, Label: Requested, Align: Left, Type: HTML
   - Key: acknowledged, Label: Acknowledged, Align: Left, Type: HTML
   - Key: resolved, Label: Resolved, Align: Left, Type: HTML
   - Key: notes, Label: Notes, Align: Left, Type: Text
10. Deploy the changes.

![Render Data on table"](https://flowfuse.com/blog/2025/06/images/render-data-in-table.png){dataZoomable=""}&#x2A;Render Data on table.*

## Create New Request Submission Flow

To create a flow that allows users to submit a request, follow these steps to set up the necessary UI elements, store the request details, validate input, and store the data in a database.

1. Drag the **ui-event** widget onto the canvas and configure it with the correct UI settings.
2. Drag a **change node** to retrieve the department list and name it "Show Dropdown Options". Add the following:
   - Set `msg.ui_update.options` to `global.departments`.
3. Create a new group for the dropdown widget on the lines page. Connect the **change node** to the input of the dropdown widget, then link it to the **ui-event** node.
4. Drag another **change node** and set `msg.payload` to `msg.store[msg._client.socketId].support`. Name it "Store support (department) to context store".
5. Drag a **text input widget** for the notes field. Create a group for it in the lines page.
6. Add another **change node** to store the notes in the global context and name it "Store notes to context store":
   - Set `msg.payload` to `msg.store[msg._client.socketId].notes`.
7. Connect the change node ("Store support (department) to context store") to the input of the dropdown widget and connect the change node ("Store notes to context store") to the text input widget.
8. Drag the **button widget**, label it "Request Support," and connect it to the **change node** that updates the UI with the department list.
9. Add a **change node** to store the request details in the global context and name it "Retrieve entered support request data":
   - Set `msg.request` to `{}`.
   - Set `msg.request.support` to the value `msg.store[msg._client.socketId].support`.
   - Set `msg.request.notes` to the value `msg.store[msg._client.socketId].notes`.
   - Set `msg.request.line` to the value `msg.store[msg._client.socketId].line`.
   - Set `msg.request.reference` to the value `msg.store[msg._client.socketId].reference`.
10. Drag the switch node onto the canvas and set property to `msg.request` and add condtion to check "is not null".
11. Drag a **function node** and add the following code. Name it "Does department and notes are not empty?":

```javascript
let request = msg.request;
if (typeof request !== "object" || request === null) {
   msg.payload = "Request must be an object.";
   return [null, null, msg];
} else if (!request.hasOwnProperty("support")) {
   msg.payload = "Please select the appropriate department for the request.";
   return [null, msg, null];
} else if (!request.hasOwnProperty("notes") || typeof request.notes !== "string" || request.notes.trim() === "") {
   msg.payload = "Please add notes to provide more context on the request.";
   return [null, null, msg];
} else {
   return [msg, null, null];
}
```

12. Connect the change node to switch node and switch node to function node. Connect the function node's first output to a **Date/Time Formatter** node. Set the input to 'Timestamp (milliseconds since epoch)' and the output to `msg.request.time`.
13. Drag a **change node** and set `msg.payload` to "Are you sure you want to submit a request?". Name it "Set Confirmation message".
14. Connect the change node ("Set Confirmation message") to the **Date/Time Formatter** node.
15. Drag a **ui-notification widget**, configure it with the correct UI, and set the position to center, checked the checkbox for both allow mnaual dismisal and all amnual confirmation, change close to "Cancel".
16. Connect the change node ("Set Confirmation message") to the **ui-notification** widget.
17. Drag another **ui-notification widget**, configure it with the correct UI, and set the position to center.
18. connect it to the second output of the function node.
19. Add a **switch node** and set the property to `msg.payload` with the condition:

- \== `confirm_clicked`
  Name it "Is confirm clicked?"

20. Drag a **change node** and add the following elements and give it name "Set Params":

- Set `msg.params` to `{}`.
- Set `msg.params.$line` to the value `msg.request.linet`.
- Set `msg.params.$support` to the value `msg.request.support`.
- Set `msg.params.$time` to the value `msg.request.time`.
- Set `msg.params.$notes` to the value `msg.request.notes`.

21. Connect the change node ("Set Params") to the switch node ("Is confirm clicked?").
22. Drag a **sqlite node**, select the correct database configuration, and choose SQL Query via "Prepared Statement" and connect that sqlite node to the input change node ("Set Params")
23. Drag a **change node** and set the following, give it name "Clear entered request data":

- Delete `msg.store[msg._client.socketId].support`.
- Delete `msg.store[msg._client.socketId].notes`.

24. Connect the **change node**\* ("Clear entered request data") to the **sqlite node**.
25. Drag a **link-out node** and connect it to the last change node.
26. Drag a **link-in node** and connect it to the last link-out node.
27. Drag two **change nodes** and configure them as follows:

- First change node: Set `msg.payload` to an empty array `[]`.
- Second change node: Set `msg.payload` to an empty string `""`.

28. Connect the change nodes to the link-in node to complete the flow.
29. Connect the first change node to the **ui dropdown widget** and the second to the **text input widget**.
30. Deploy the changes.

![Node-RED flow showing the logic for validating and storing user-submitted support requests.](https://flowfuse.com/blog/2025/06/images/submit-request-flow.png){dataZoomable=""}&#x2A;Node-RED flow to handle request submission, including form validation, timestamp formatting, and SQL database insertion.*

We have now successfully built one part of the Andon task dashboard. You can open the line view in the dashboard and check whether you can submit a request, mark it as acknowledged, and resolve it.

![UI form with dropdown, text input, and a submit button labeled "Request Support."](https://flowfuse.com/blog/2025/06/images/submit-form.png){dataZoomable=""}&#x2A;Dashboard UI where users select a department, enter notes, and submit a support request for the production line.*

## Up Next

Up until now, the focus has been on building the core functionality of the Andon Task Manager dashboard, including the Lines page. Design and layout have not been the priority. In the next part, you will learn how to enhance the visual design, improve usability, and create a dedicated page and menu for departments.

Later, we will guide you through building the Admin page for the Andon Task Manager dashboard, enabling request management, department configuration, and overall system control.


# Connect Your Shop Floor to Your ERP – Odoo Edition

A major problem in manufacturing today is when your ERP system isn't getting real-time information from the factory floor. This gap causes big issues, like ordering too much material because inventory numbers are old, or missing important production deadlines. This lack of instant, correct information directly leads to higher costs and lost opportunities for your business.

This problem often comes from old ways of recording data. Many factories still rely on paperwork, which takes up valuable space, and manual entries. These methods require extra human effort, causing big delays and added costs. These old, error-prone ways are simply not sustainable for modern manufacturing.

This post gives you a vital solution. We'll show you how to connect your factory floor directly to your ERP system using FlowFuse. This way, you'll see near real-time data in your ERP, helping you avoid issues such as costly over-orders, missed deadlines, and the burdens of excessive paperwork. For this article, we'll focus on integrating with the popular ERP system, Odoo.

## Basic Demo: Automating Production Data from the Shop Floor to Odoo with FlowFuse

Before we start diving into how you can connect your shop floor to ERP, let's first see a simple demo. This basic demo shows how FlowFuse acts as a smart link, making sure your production line data is always accurate in your ERP. We're doing this with a Raspberry Pi running the [FlowFuse Agent](https://flowfuse.com/platform/device-agent/), which talks to a Siemens S7 PLC. A counter in the PLC, which ticks up every second to act like products being made, is precisely read using the [S7 protocol](https://flowfuse.com/blog/2025/01/integrating-siemens-s7-plcs-with-node-red-guide/) through FlowFuse. This accurate count is then automatically sent to Odoo as the quantity for a "table leg product," keeping your inventory data always up-to-date.

This is just a simple example of what FlowFuse can do. But it has much more power! Imagine FlowFuse also checking your production orders (MOs) in your ERP to see what you need to make. It can look at your Bills of Material (BOMs) in your ERP to figure out all the parts required. If it sees you're short on something, it can automatically create purchase orders in your ERP to buy the missing parts. It can even make new manufacturing orders for components you need to build.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: bxVq_8m-GOk
---
::

Below is the complete flow for this demo, in case you would like to explore it further or try it out yourself after reading the article

::render-flow
```json
[{"id":"cab977c8e0d1c054","type":"group","z":"FFF0000000000001","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["6ba9343481e3b041","8a3adb31adbb7475","bfe37a946a6ed20a","304719d8be3f5694"],"x":664,"y":399,"w":732,"h":122},{"id":"6ba9343481e3b041","type":"odoo-xmlrpc-update","z":"FFF0000000000001","g":"cab977c8e0d1c054","name":"","host":"18818bdefd1f27ce","model":"product.template","filter":"","offset":0,"limit":100,"x":1270,"y":480,"wires":[[]]},{"id":"8a3adb31adbb7475","type":"change","z":"FFF0000000000001","g":"cab977c8e0d1c054","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"[[38],{\"qty_available\":payload}]","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":1020,"y":480,"wires":[["6ba9343481e3b041"]]},{"id":"bfe37a946a6ed20a","type":"debug","z":"FFF0000000000001","g":"cab977c8e0d1c054","name":"Good Product Produced","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1050,"y":440,"wires":[]},{"id":"304719d8be3f5694","type":"s7 in","z":"FFF0000000000001","g":"cab977c8e0d1c054","endpoint":"142c103a7735ea99","mode":"single","variable":"Counter","diff":true,"name":"S7 ","x":740,"y":480,"wires":[["8a3adb31adbb7475","bfe37a946a6ed20a"]]},{"id":"18818bdefd1f27ce","type":"odoo-xmlrpc-config","url":"","db":"","username":"","password":""},{"id":"142c103a7735ea99","type":"s7 endpoint","transport":"iso-on-tcp","address":"192.168.1.6","port":"102","rack":"0","slot":"1","localtsaphi":"01","localtsaplo":"00","remotetsaphi":"01","remotetsaplo":"00","connmode":"rack-slot","adapter":"","busaddr":2,"cycletime":1000,"timeout":2000,"name":"","vartable":[{"addr":"DB1,X4.0","name":"Trigger"},{"addr":"DB1,DW0","name":"Counter"}]}]
```
::

## Getting Data Into and Out of Odoo with FlowFuse

In this section, we will show you how you can connect your ERP (Odoo) with your shop floor using FlowFuse. This connection lets you read information, create new records, update existing ones, and search for specific data, bringing real-time factory insights right into your business system.

### Prerequisites

Before you begin, make sure you have the following:

- **Running FlowFuse Instance:** Make sure you have a FlowFuse instance set up and running. If you don't have an account, check out our [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}.
- **node-red-contrib-odoo-xmlrpc-filters-fields:** Ensure you have [node-red-contrib-odoo-xmlrpc-filters-fields](https://flows.nodered.org/node/node-red-contrib-odoo-xmlrpc-filters-fields){rel="&#x22;nofollow&#x22;"} installed. This package will enable operations like reading, creating, updating, and searching data, with specific capabilities for filtering records and selecting precise fields.

### Configuring the Odoo Connection Node

Before you can send or receive any data from Odoo, FlowFuse needs to know how to connect to your Odoo instance. This is a one-time setup for your connection details, which can then be reused across all your Odoo nodes in FlowFuse.

1. Drag any `odoo-xmlrpc` node (like `odoo-xmlrpc-read` or `odoo-xmlrpc-create`) onto your Node-RED canvas.
2. Double-click on the node to open its configuration.
3. Next to the "Host" field, click the pencil icon to add a new Odoo connection.
4. In the configuration dialog, you'll need to enter your Odoo instance's details:

- Host URL: This is the web address of your Odoo instance (e.g., `https://databaseName.odoo.com`).
- Database: The name of your Odoo database.
- Username: Your Odoo login username (e.g., your email address).
- Password: Your Odoo login password.

5. Click "Add" to save this configuration.

![Configuring Odoo Node](https://flowfuse.com/blog/2025/06/images/configuration-odoo.png)*Configuring Odoo Node*

Now, any `odoo-xmlrpc` node you use can select this saved host configuration, meaning you only have to enter your credentials once.

*Note: These configuration details (Host, Database, Username, Password) are confidential. To prevent exposing them when sharing your flows, it's crucial to use **FlowFuse Environment Variables**. These variables allow you to store sensitive information securely outside of your flow code. For more information, refer to our guide on [Environment Variables in Node-RED](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/).*

### Understanding Odoo Models

Once your connection is set up, the next key concept for interacting with Odoo is understanding **Models**. In Odoo, a "model" represents a specific type of business object or data record, much like a table in a traditional database. Every piece of data you want to read, create, update, or delete belongs to a specific model.

Common Odoo models relevant to manufacturing include:

- `product.template`: For general product information (e.g., product names, descriptions).
- `stock.quant`: For inventory quantities and locations.
- `mrp.production`: For manufacturing orders/production orders.
- `res.partner`: For contacts (customers, suppliers).
- `stock.picking`: For internal transfers or delivery orders.

When you use an `odoo-xmlrpc` node in FlowFuse, you'll always need to specify which `model` you want to work with. If you're unsure of a specific model's name, you can often find it by enabling "Developer Mode" in your Odoo instance and hovering over fields in the Odoo interface.

Let’s get started. When explaining each operation, I will demonstrate it using different models such as `product.product` or `mrp.production`. This is just for demonstration and your understanding. You can perform these operations in the same way with other models, just make sure to pass the correct parameters according to the model and its data.

### Reading Data from Odoo

To read data from Odoo, you'll use the `odoo-xmlrpc-search_read` node. This node requires you to send the id (or ids) of the record(s) you wish to read to this node with `msg.payload`. The `msg.payload` should contain an array of the IDs you want to read.

Here is how you can read products data:

1. Drag an inject node onto your canvas.
2. Connect it to a change node. Here, you'll set the query details:

- Set `msg.payload` to the following array:

```json
[ID]
```

Replace ID with the actual product ID you want to read. You can include multiple IDs, for example:

```json
[1, 5, 12]
```

4. Connect the change node to an odoo-xmlrpc-search\_read node. Select your Odoo connection, enter model to `product.product` (or the Odoo model you want to query).
5. Connect to a debug node to view the data.
6. Deploy the flow and click the inject node button to see the result.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: 9CdVOp_bDMk
---
::

::render-flow
```json
[{"id":"4f2bd9814f07c6a6","type":"odoo-xmlrpc-read","z":"295d40790bd21f48","name":"","host":"18818bdefd1f27ce","model":"product.template","x":1190,"y":280,"wires":[["5601affdba752326"]]},{"id":"5601affdba752326","type":"debug","z":"295d40790bd21f48","name":"debug 6","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1500,"y":280,"wires":[]},{"id":"4e8b22877e33b496","type":"inject","z":"295d40790bd21f48","name":"Read products with id 23 and 39","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":570,"y":280,"wires":[["b21cdd78ad81d65a"]]},{"id":"b21cdd78ad81d65a","type":"change","z":"295d40790bd21f48","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"[39,23]","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":280,"wires":[["4f2bd9814f07c6a6"]]},{"id":"18818bdefd1f27ce","type":"odoo-xmlrpc-config","url":"${HOST}","db":"${DB_NAME}","username":"${USERNAME} ","password":"${PASSWORD}"}]
```
::

### Creating New Record in Odoo

To create new records in Odoo using FlowFuse, use the `odoo-xmlrpc-create` node. This node requires you to send an array of objects containing the record information as `msg.payload`. The array can include multiple objects, allowing you to create multiple records at once.

Here is how you can create manufacturing order:

1. Drag an inject node onto your canvas and set it to trigger manually.
2. Connect it to a change node. Configure it to set `msg.payload` with the details for your new Odoo manufacturing order:

- Set `msg.payload` to:

```json
[{
    "product_id": 39,      
    "product_qty": 500,     
    "product_uom_id": 1 
}]
```

3. Connect the change node to an `odoo-xmlrpc-create` node. Select your configured Odoo connection for its Host and enter model to `mrp.production`
4. Connect the `odoo-xmlrpc-create node` to a debug node to see the ID of the new record Odoo creates.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: bq_yaF8etmw
---
::

::render-flow
```json
[{"id":"d89d98a5ec9a8733","type":"odoo-xmlrpc-create","z":"295d40790bd21f48","name":"","host":"18818bdefd1f27ce","model":"mrp.production","filter":"","offset":0,"limit":100,"x":1200,"y":380,"wires":[["ea101f5cab65a241"]]},{"id":"99ba2ffda10cf2d9","type":"inject","z":"295d40790bd21f48","name":"Create New MO","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":620,"y":380,"wires":[["33e0301b6e8f7838"]]},{"id":"ea101f5cab65a241","type":"debug","z":"295d40790bd21f48","name":"debug 5","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1500,"y":380,"wires":[]},{"id":"33e0301b6e8f7838","type":"change","z":"295d40790bd21f48","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"[{\"product_id\":30,\"product_qty\":200,\"product_uom_id\":1}]","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":380,"wires":[["d89d98a5ec9a8733"]]},{"id":"18818bdefd1f27ce","type":"odoo-xmlrpc-config","url":"${HOST}","db":"${DB_NAME}","username":"${USERNAME} ","password":"${PASSWORD}"}]
```
::

### Updating Existing Data in Odoo

To modify existing records in Odoo using FlowFuse, you'll use the `odoo-xmlrpc-update` node. This node requires the ID of the record(s) you want to update and the new values for the fields you wish to change. The `msg.payload` should contain an array, where the first element is a list of record IDs and the second element is an object with the fields to update.

Here is how you can update the status of manufacturing order:

1. Drag an inject node onto your canvas. Configure it to trigger manually.
2. Connect it to a change node. This node will prepare the `msg.payload` with the order ID and the new status.

- Set `msg.payload` to :

```json
[
    [13],
    {"state": "progress"}
]
```

3. Connect the change node to an `odoo-xmlrpc-update` node. Select your configured Odoo connection for its Host and enter model to `mrp.production`.
4. Connect the `odoo-xmlrpc-update` node to a debug node to confirm the update operation. (A successful update typically returns true or an empty payload).
5. Deploy the flow and click the inject node button to see the result.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: SsPfHxCwMI8
---
::

::render-flow
```json
[{"id":"e43dc05eb7df7ecf","type":"inject","z":"295d40790bd21f48","name":"Update MO Status","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":610,"y":540,"wires":[["11bbd21f1314b839"]]},{"id":"47b01f56b4800c5c","type":"debug","z":"295d40790bd21f48","name":"debug 3","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1500,"y":540,"wires":[]},{"id":"bd9de404f2ac1a2e","type":"odoo-xmlrpc-update","z":"295d40790bd21f48","name":"","host":"18818bdefd1f27ce","model":"mrp.production","filter":"","offset":0,"limit":100,"x":1200,"y":540,"wires":[["47b01f56b4800c5c"]]},{"id":"11bbd21f1314b839","type":"change","z":"295d40790bd21f48","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"[     [18],     {\"state\": \"progress\"} ]","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":540,"wires":[["bd9de404f2ac1a2e"]]},{"id":"18818bdefd1f27ce","type":"odoo-xmlrpc-config","url":"${HOST}","db":"${DB_NAME}","username":"${USERNAME} ","password":"${PASSWORD}"}]
```
::

### Deleting Records from Odoo (Unlink)

To delete records in Odoo using FlowFuse, you'll use the `odoo-xmlrpc-unlink` node. This node requires you to send the id (or ids) of the record(s) you wish to remove. The `msg.payload` should contain an array of the IDs you want to delete.

Here is how you can delete product from inventory:

1. Drag an inject node onto your canvas. Configure it to trigger manually.
2. Connect the inject node to a change node. This node will prepare the msg.payload with the ID(s) of the record(s) to delete.

- Set `msg.payload` to a JSON array containing the ID of the manufacturing order to delete:

```json
[16]
```

3. Connect the change node to an `odoo-xmlrpc-unlink`. Select your configured Odoo connection for its Host and enter model to `mrp.production`.
4. Connect the `odoo-xmlrpc-unlink` to a debug node to confirm the unlink operation.
5. Deploy the flow and click the inject node button to see the result.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: 1O1JYRtX-Sg
---
::

::render-flow
```json
[{"id":"f14241bb24af8dc8","type":"odoo-xmlrpc-unlink","z":"295d40790bd21f48","name":"","host":"18818bdefd1f27ce","model":"product.template","x":1190,"y":700,"wires":[["231e32e70753ab22"]]},{"id":"9452d125fd059f79","type":"inject","z":"295d40790bd21f48","name":"Delete the product with ID 60","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":580,"y":700,"wires":[["cfcabeae8b291a9c"]]},{"id":"231e32e70753ab22","type":"debug","z":"295d40790bd21f48","name":"debug 7","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1500,"y":700,"wires":[]},{"id":"cfcabeae8b291a9c","type":"change","z":"295d40790bd21f48","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"[60]","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":700,"wires":[["f14241bb24af8dc8"]]},{"id":"18818bdefd1f27ce","type":"odoo-xmlrpc-config","url":"${HOST}","db":"${DB_NAME}","username":"${USERNAME} ","password":"${PASSWORD}"}]
```
::

### Advanced Search with Filters and Fields

For advanced queries, you'll use the `odoo-xmlrpc-search_read` node. This versatile node combines the ability to search for records using complex criteria (filters) and to retrieve only the specific data fields you need from those results.

#### Understanding Filters

Filters are conditions you apply to narrow down your search results. They are structured as a **list of lists**, where each inner list defines a single condition: `[field, operator, value]`.

- `field`: The name of the Odoo field you want to filter by (e.g., `qty_available`, `state`, `name`).
- `operator`: How you want to compare the field. Common operators include:
  - `=`: Equal to
  - `!=`: Not equal to
  - `>`: Greater than
  - `<`: Less than
  - `>=`: Greater than or equal to
  - `<=`: Less than or equal to
  - `in`: Value is in a list (e.g., `[["id", "in", [1, 2, 3]]`)
  - `not in`: Value is not in a list
  - `ilike`: Case-insensitive "like" (contains substring)
  - `=like`: Case-sensitive "like"
- `value`: The value you're comparing against.

When you include multiple conditions within your filters list, Odoo treats them as an "AND" relationship by default. This means all conditions must be true for a record to be returned.

**Example Filters:**

- `[[["list_price", "<", 10]]]`: Find products with less than 10 units in stock.
- `[[["state", "=", "progress"], ["product_id", "=", 38]]]`: Find manufacturing orders for a specific product that are currently "in progress."
- `[[["name", "ilike", "coating"]]]`: Find products where the name contains "coating" (case-insensitive).

#### Understanding Fields

The `fields` parameter allows you to specify exactly which columns or properties you want to retrieve for the matching records. This is important for efficiency, as it avoids pulling unnecessary data, making your flows faster and your payloads smaller.

- **Structure:** A simple list of field names (e.g., `["name", "qty_available", "default_code"]`).

#### Controlling Results: Offset and Limit

For larger datasets, you'll want to control how many records are returned and where the results start.

- offset: This parameter specifies the number of records to skip from the beginning of the result set. It's useful for pagination.
- limit: This parameter specifies the maximum number of records to return in a single query. It's crucial for managing the amount of data you retrieve.

#### Example Flow

Here’s an example FlowFuse flow to find products with list price (more than 1000) that are also marked as "saleable" in Odoo, retrieving only their name, quantity, internal reference, and list price, and limiting the results.

1. Drag an inject node onto your canvas and configure it to trigger manually.
2. Connect it to a change node. This node will define your search criteria (filters and fields) and also set the offset and limit.

- Set `msg.filters` to JSON:

```json
[[
    ["list_price", ">", 1000],
    ["sale_ok", "=", true]
]]
```

- Set `msg.fields` to JSON:

```json
["name", "qty_available", "default_code", "standard_price"]
```

- Set `msg.offset` to Number 0 (Start from the first record).
- Set `msg.limit` to Number 5 (Retrieve a maximum of 10 records).

3. Connect the change node to an `odoo-xmlrpc-search_read` node. Select your configured Odoo connection.
4. Connect to a debug node to inspect the filtered and selected data in the debug sidebar.
5. Deploy the flow and click the inject node button to see the result.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: 8Asa3z2VctQ
---
::

::render-flow
```json
[{"id":"0cfe26fd5b4169e7","type":"debug","z":"295d40790bd21f48","name":"debug 4","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1500,"y":840,"wires":[]},{"id":"656023449ba5dee9","type":"inject","z":"295d40790bd21f48","name":"Read Top 5 Saleable Products >1000","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":550,"y":840,"wires":[["7f791bfc8caa0721"]]},{"id":"8ada5a972d94dd9d","type":"odoo-xmlrpc-search-read","z":"295d40790bd21f48","name":"","host":"18818bdefd1f27ce","model":"product.product","filter":"","offset":0,"limit":100,"x":1210,"y":840,"wires":[["0cfe26fd5b4169e7"]]},{"id":"7f791bfc8caa0721","type":"change","z":"295d40790bd21f48","name":"","rules":[{"t":"set","p":"filters","pt":"msg","to":"[[[\"list_price\",\">\",1000],[\"sale_ok\",\"=\",true]]]","tot":"json"},{"t":"set","p":"limit","pt":"msg","to":"5","tot":"num"},{"t":"set","p":"offset","pt":"msg","to":"0","tot":"num"},{"t":"set","p":"fields","pt":"msg","to":"[\"name\",\"qty_available\",\"default_code\",\"lst_price\"]","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":840,"wires":[["8ada5a972d94dd9d"]]},{"id":"18818bdefd1f27ce","type":"odoo-xmlrpc-config","url":"${HOST}","db":"${DB_NAME}","username":"${USERNAME} ","password":"${PASSWORD}"}]
```
::

## Final thought

So, we've talked about how those manual data methods, paper, spreadsheets, can really slow things down, cause mistakes, and cost money in your factory. And let's be honest, many digital fixes out there just add more complexity or demand specialized coding skills that your team might not have.

This is where FlowFuse comes in. FlowFuse is a platform made for factory floors that runs on your devices right there. It connects to all your machines, old or new, and even your ERP systems like Odoo. FlowFuse collects, cleans, and moves your data. It helps your engineers, who know your operations best, build industrial applications and solutions using simple drag-and-drop actions. This means they can link your factory data directly to your ERP, getting rid of all those manual steps and saving your IT team time and money.

What's the real payoff? You get to see less wasted time and money, fewer mistakes with accurate, real-time data, and simply better control over your whole factory. FlowFuse helps your entire operation run smarter and more reliably. If you're looking for a practical way to bring these kinds of improvements to your own manufacturing processes, we'd be glad to discuss how FlowFuse can assist. [Get in touch here](https://flowfuse.com/contact-us/)


# MES Data Acquisition: How to Unlock Your Factory’s Hidden Data

A Manufacturing Execution System (MES) is the central control system of a factory. To work properly, it needs a steady stream of real-time data from machines and systems on the factory floor. This data is essential for running operations smoothly. But in most factories, the hardest part is getting this data to the MES.

This article dives into the data that fuels your MES and the complex web of sources it comes from. We'll explore the core challenge that keeps this data locked away in silos. Most importantly, we’ll show how **FlowFuse** acts as the catalyst to liberate this data, empowering you to get the right information to your MES, exactly when and where you need it most.

## The Operational Data Your MES Needs

For a factory's main computer system (the MES) to do its job, it needs a constant stream of information. Think of it like a control room that needs to see everything at once. This information can be grouped into four main types:

- **Production Information:** This tells the system how much is being made, how fast it's being made, and if any products had to be thrown out. It's the basic "are we winning?" data.
- **Machine Information:** This is like a live health report for your equipment. It tells the system if a machine is running or stopped, what its settings are (like temperature or speed), and how much power it's using.
- **Context and Quality Information:** This data adds the "why." It tells the system who is working, why a machine stopped, and if the products being made are good enough to sell.
- **Material Information:** This tells the full story of a product. It tracks all the raw materials and parts from start to finish, so you know exactly what went into every single item.

Once the system gets all this information, it does more than just track numbers. It becomes the factory's control center. It gives workers step-by-step instructions on their screens, makes sure rules are followed to prevent mistakes, and lets managers see exactly what’s happening everywhere so they can fix small problems before they become big ones.

## The Origins Of Your Operational Data

This critical operational data doesn't live in one place; it's generated across a diverse and complex digital ecosystem.

A vast amount comes directly from shop floor equipment, the PLCs that orchestrate your machines, the thousands of sensors measuring every variable, and the Historians that diligently archive past performance. Then you have your core business systems. The ERP provides the what and why through production orders, while Quality (QCS) and Maintenance (CMMS) systems add essential layers of inspection and machine health data.

Each of these sources speaks its own digital language. A single factory floor is a cacophony of `Modbus`, `OPC UA`, `EtherNet/IP`, and `MQTT`, etc all running simultaneously. This mix of protocols defines the communication architecture of the operation.

To better understand the data involved, its sources, and the common protocols used, let's look at a detailed breakdown:

![A table showing the four main categories of data MES need](https://flowfuse.com/blog/2025/06/images/industrial-data-landscapes.png){dataZoomable=""}*A table showing the four main categories of data MES need*

## Why It's So Difficult, Slow, and Costly to Access Data

You know what data you need and where it is. The fundamental question is: can you actually get it from your machines and deliver it to your MES?

This is the central struggle where real-time decisions get delayed, opportunities are lost, and innovation is stifled. Your most valuable data is trapped. Because your factory’s systems don’t speak the same digital language, data is locked away in "silos," inaccessible and unusable. This isn't a technical inconvenience; it's a critical business problem.

Every new piece of equipment demands expensive, custom-coded integrations that are fragile and brittle. This necessitates a constant reliance on specialized programmers, driving up operational costs significantly. The result is a chaotic patchwork of inconsistent data flows, leaving you with a fragmented view of your operation instead of the unified intelligence you desperately need to make swift, informed decisions. This isn't just inefficient; it actively sabotages your agility, cripples your ability to innovate, and fundamentally undermines your competitive advantage.

## Orchestrate Your Factory's Data Flow with FlowFuse

It's frustrating to know the data is there but be unable to reach it. FlowFuse was built to solve this exact problem by acting as a data acquisition layer for your factory. It creates reliable pathways for information to get from your various machines and systems directly to your MES.

The power of FlowFuse lies in its foundation on the vast Node-RED ecosystem. This gives you immediate access to a library of over 5,000 pre-built connectors, or "nodes" ready to communicate with a massive array of industrial protocols. This eliminates the need for expensive, time-consuming custom code. The library includes robust nodes for standards like Modbus, OPC UA, and MQTT, as well as for specific controllers from Siemens, Mitsubishi, Omron, and more.

Following are some of the most commonly used protocol nodes:

- **Modbus:** <https://flows.nodered.org/node/node-red-contrib-modbus>{rel="&#x22;nofollow&#x22;"}
- **OPC UA:** <https://flows.nodered.org/node/node-red-contrib-opcua>{rel="&#x22;nofollow&#x22;"}
- **OPC DA:** <https://flows.nodered.org/node/node-red-contrib-opc-da>{rel="&#x22;nofollow&#x22;"}
- **MQTT:** [/node-red/core-nodes/mqtt-in/](https://flowfuse.com/node-red/core-nodes/mqtt-in/)
- **Ethernet/IP:** <https://flows.nodered.org/node/node-red-contrib-ethernet-ip>{rel="&#x22;nofollow&#x22;"}
- **Siemens S7:** <https://flows.nodered.org/node/node-red-contrib-s7comm>{rel="&#x22;nofollow&#x22;"}
- **MITSUBISHI MC:** <https://flows.nodered.org/node/node-red-contrib-mcprotocol>{rel="&#x22;nofollow&#x22;"}
- **OMRON FINS:** <https://flows.nodered.org/node/node-red-contrib-omron-fins>{rel="&#x22;nofollow&#x22;"}
- **HTTP:** [/node-red/core-nodes/http-in/](https://flowfuse.com/node-red/core-nodes/http-in/)
- **LwM2M:** <https://flows.nodered.org/node/node-red-contrib-lwm2m>{rel="&#x22;nofollow&#x22;"}
- **AMQP:** [/node-red/protocol/amqp/](https://flowfuse.com/node-red/protocol/amqp/)
- **Serialport:** <https://flows.nodered.org/node/node-red-node-serialport>{rel="&#x22;nofollow&#x22;"}
- **GPIO:** <https://flows.nodered.org/node/node-red-contrib-gpio>{rel="&#x22;nofollow&#x22;"}
- **Lorawan:** <https://flows.nodered.org/node/node-red-contrib-lorawan>{rel="&#x22;nofollow&#x22;"}

This extensive library allows you to reliably acquire data from various assets using a simple drag-and-drop approach, bringing your factory's siloed data into a cohesive and manageable flow.

In addition to protocol connectors, there are also powerful database nodes available to integrate with systems such as InfluxDB, TimescaleDB, PostgreSQL, Microsoft SQL Server, and more, making it easy to store, query, and analyze your factory data.

So, With FlowFuse, you can:

- **Deploy intelligent agents** directly to the edge, all managed from a central platform remotely.
- **Connect to any industrial asset** (PLCs, sensors, SCADA) using ready-made nodes.
- **Transform raw data** with visual logic, so it’s perfectly structured for your MES.
- **Build custom operator dashboards** with pre-built UI widgets to visualize and act on data.
- **Automate data flows** based on schedules, machine events, or production states.
- **Secure the entire process** with enterprise-grade features like multi-user authentication and role-based access control.
- **Scale seamlessly** from a single line to your entire enterprise.

This isn't just about solving a technical challenge. It’s about driving business outcomes. When you can finally see your entire operation in one clear picture, your production lines run more efficiently. You'll see tangible savings as you reduce waste and catch errors before they become costly. When you are known for exceptional quality and effortless compliance, you win. You can turn the messy, trapped data that has been holding you back into the very asset that pushes you ahead of the competition.

## Your Next Step Towards Operational Excellence

Bridging the gap between your factory floor and your MES is a huge task. The sheer diversity of machines, systems, and protocols can seem impossible to overcome. But it doesn’t have to be a barrier to innovation.

This is precisely where FlowFuse shines. It acts as the universal translator, bringing all your systems together regardless of the language they speak. With thousands of ready-to-use connectors and an intuitive low-code interface, FlowFuse empowers you to get your data flowing exactly where it needs to go.

Once that live data starts moving, your MES becomes exponentially more powerful, helping you spot problems faster, plan smarter, and run your operations with confidence.

Want to see it in action? [Book a live demo](https://flowfuse.com/book-demo/) and watch FlowFuse unlock your factory data, no custom code required.


# FlowFuse Forms: Easy Data Collection for Your Factory Floor

It's often a pain to get important data from the factory floor. Things like doing quality checks still rely on old methods like manual notes and slow spreadsheets. This can lead to delays, errors, and a lot of wasted time before anyone can actually use the information. It's especially tough when you need quick feedback from an operator.

This article will show you an easy way to gather data via a form entry. We'll look at how forms in FlowFuse Dashboard can make collecting data from factory workers much simpler. You'll learn how to build useful forms that connects your team's knowledge directly to your industrial processes. As a practical example, we'll walk you through building a solution to digitize production recipe updates, showing you exactly how to implement it.

## Prerequisites

Before you begin, make sure you have the following:

- **Node-RED:** Make sure you have an instance of Node-RED up and running. The quickest way to do this is via FlowFuse. If you don't have an account, check out our [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}.

Then you'll need to add two more sets of nodes to your palette:

- **FlowFuse Dashboard:** Ensure you have [FlowFuse Dashboard](https://flows.nodered.org/node/@flowfuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"} (also known as Node-RED Dashboard 2.0 in the community) installed and properly configured on your instance.
- **SQLite:** Install the [node-red-node-sqlite](https://flows.nodered.org/node/node-red-node-sqlite){rel="&#x22;nofollow&#x22;"} package, which will be used in the practical example.

and finally:

- **Basic Node-RED Knowledge:** You are familiar with creating and deploying basic flows in Node-RED. If not, consider taking the [Node-RED Fundamentals Course](https://node-red-academy.learnworlds.com/course/node-red-getting-started){rel="&#x22;nofollow&#x22;"} &#x2A;sponsored by FlowFuse.*

## Building Forms in FlowFuse Dashboard

The FlowFuse Dashboard makes it easy to build interactive industrial applications using drag-and-drop components, **no coding required**.

One of these components is the [Form](https://dashboard.flowfuse.com/nodes/widgets/ui-form.html){rel="&#x22;nofollow&#x22;"} widget, which allows you to create versatile forms within your applications. The Form widget supports a wide range of input types, including:

- Text Fields
- Number Inputs
- Date Pickers,
- Multi-line Text Areas
- Dropdown Selection
- Checkboxes

A key benefit of this widget is that you can configure the form fields either statically (with predefined values) or dynamically (updated through your Node-RED flow), depending on your application’s needs.

### Adding and Configuring the Form Widget

1. Drag the **Form** widget onto the canvas.
2. Double-click on the widget and create a new group for it with the correct page configuration to render it. (note: if this is the first widget you have, this will automatically be created for you)
3. Set an appropriate size (width and height) according to your preferences.
4. Enter the label for the form.

Now that we have completed all the basic and necessary configurations for the form, let’s add the input elements.

### Adding Input Fields to the Form Statically

:video{ariaLabel="Adding Form Elements" autoPlay="true" height="726" loop="true" muted="true" playsInline="true" preload="none" width="800"}*Adding Form Elements*

The widget supports various input element types that can be tailored to specific use cases, from collecting simple text to selecting dates or choosing from predefined options.

**To add input elements:**

1. Click the **+ add** button in the widget’s configuration dialog.
2. A new configuration row will appear for the element.
3. Configure each input element with the following fields:

- **Label**: This is the visible label for the field shown to the user.
- **Name**: A unique key used in the message payload (e.g., `msg.payload.firstname`) when the form is submitted.
- **Type**: Select the input type. Supported types include:
  - **Text**: For short text inputs (e.g., name, city).
  - **Number**: For numeric inputs (e.g., age, price).
  - **Date**: For selecting a date.
  - **Text Area**: For longer free-form text.
  - **Dropdown**: For selecting from a list of predefined values. :br&#x2A;We will cover how to add options to the dropdown field in a later section.*
  - **Checkbox**: For boolean values (checked or unchecked).
- **Required**: Check this box to make the field mandatory. The form cannot be submitted unless this field is filled.
- **Row**:: If Multiline is selected, this defines the number of visible rows in the text area.

### Adding Options to Dropdown Inputs Statically

When you add Dropdown type input element to the Form widget, you need to provide a list of `options` that the user can choose from. These options can be configured in the widget's configuration dialog.

1. In the widget's configuration dialog, switch to the "Dropdown Options" tab.
2. Click the **+ add** button to insert a new option row.
3. In the new row, fill in the following fields:
   - **Dropdown**: Select the dropdown input field you want to add options to.
   - **Value**: The internal value that will be sent in the form payload when this option is selected.
   - **Label**: The visible text shown to the user in the dropdown list.

Repeat this process for each option you want to add.

### Pre-filling Forms with Default Values

You can pre-fill forms with default values to streamline user input, reduce typing errors, and save time. This is especially useful in scenarios like editing an existing recipe, where the current details can be loaded directly into the form.

We can pass data to the `ui-form` node in our flow to set these values dynamically. To do this, send an object in `msg.payload` to the input of the relevant node. Each key of `msg.payload` corresponds to a form field and its value represents the pre-filled data.

For example, if your form includes fields for `product_name` and `target_temperature_c`, you can send a `msg.payload` like this:

```javascript
{
    "product_name": "Eco-Friendly Coating",
    "target_temperature_c": 120.0
};
```

### Add Form Input Elements Dynamically at Runtime

In some cases, you may need to define form elements dynamically based on real-time data.

For example, you might want to show additional fields based on a user’s selection or load dropdown options from an external API. This dynamic capability adds a new level of flexibility and interactivity to your forms.

**To define form fields at runtime:**

1. Use the `msg.ui_update.options`.
2. `options` should contain an array of objects, where each object defines the new configuration for the element:

Below are the supported element types and their corresponding JSON configurations:

| **Element Type** | **JSON Configuration**                                                                 |
| ---------------- | -------------------------------------------------------------------------------------- |
| **Text**         | `{ "type": "text", "label": "Name", "key": "name", "required": true }`                 |
| **Multiline**    | `{ "type": "multiline", "label": "Name", "key": "name", "required": true, "rows": 4 }` |
| **Password**     | `{ "type": "password", "label": "Password", "key": "password", "required": true }`     |
| **Email**        | `{ "type": "email", "label": "E-Mail Address", "key": "email", "required": true }`     |
| **Number**       | `{ "type": "number", "label": "Age", "key": "age", "required": true }`                 |
| **Checkbox**     | `{ "type": "checkbox", "label": "Subscribe to Newsletter", "key": "newsletter" }`      |
| **Switch**       | `{ "type": "switch", "label": "Enable Notifications", "key": "notifications" }`        |
| **Date**         | `{ "type": "date", "label": "Date of Birth", "key": "dob", "required": true }`         |
| **Time**         | `{ "type": "time", "label": "Time of Birth", "key": "tob", "required": true }`         |
| **Dropdown**     | `{ "type": "dropdown", "label": "Dropdown", "key": "selection" }`                      |

### Adding Options to Dropdown Inputs Dynamically at Runtime

To update the options of a dropdown field at runtime, use the `msg.ui_update.dropdownOptions` property in your flow.

This is useful when you want to update just the dropdown options without changing the rest of the form.

**Example:**

```json
[
   {
        "dropdown": "Machine Type",
        "value": "A",
        "label": "Option A"
   },
   {
        "dropdown": "Machine Type",
        "value": "B",
        "label": "Option B"
   }
]
```

The "dropdown" refers to the name of the dropdown field you want to add options for. The "value" represents the internal value that is sent when the user selects the option. The "label" is the option displayed to the user in the dropdown.

## Handling Input Data Collected from the Dashboard Form

When a user submits the dashboard form, the input data is sent to Node-RED, where it can be accessed and processed. This enables you to perform tasks such as validating the data, transforming it, or sending it to other systems like databases or APIs.

### Retrieving Submitted Data

The data submitted from the form is transmitted to any nodes connected to the output of the `ui-from` node, and is contained within `msg.payload`. Each field’s value can be accessed using the field’s key or name as the property within `msg.payload`.

For example, let’s say the form includes the following fields:

- Device Name (key: `device_name`)
- Device ID (key: `device_id`)
- Device Serial Number (key: `serial_number`)
- Country (key: `country`)

After submission, you can access these values like this in your flow:

- Device Name: `msg.payload.device_name`
- Device ID: `msg.payload.device_id`
- Device Serial Number: `msg.payload.serial_number`
- Country: `msg.payload.country`

You can use this data anywhere in your flow, for example, to save it in a database or store it in [FlowFuse’s context storage](https://flowfuse.com/docs/user/persistent-context/#flowfuse-persistent-context). Crucially, this collected data can also directly instruct machines on the shop floor, with FlowFuse Device Agent managing that precise control.

## Building Your Dynamic Production Recipe Update Form

In this section, you will build an advanced flow for dynamically updating production recipes using FlowFuse Forms.

A production recipe, often referred to as a manufacturing recipe or master batch record, is a critical set of instructions that defines the precise parameters, ingredients, and steps required to produce a specific product consistently. This includes details like material quantities, temperature, mixing speeds, pressures, and hold times.

This setup uses a **ui-dropdown** for selecting recipes and a **ui-form** that dynamically populates and allows updates to recipe parameters. Everything you have learned so far will come together here to create a practical and interactive solution.

### Set Up Your SQLite Database

Use the following flow to quickly set up your SQLite database. It creates a recipes table and populates it with demo data.

**Steps:**

1. Import the flow into your Node-RED editor (from the example provided below).
2. Deploy the flow to activate it.
3. Click the Inject node labeled "Populate Demo Recipes" to insert the sample data.

::render-flow{:height='300'}
```json
[{"id":"d248b8387940a5bc","type":"group","z":"295d40790bd21f48","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["b9693cc84311ae8e","e7619cfe7c7fdaa9","f9e35c9c3b213d47","c719f2b43aef7d44","69a914bb0479925c","bb3da75dcf2b4cdd"],"x":54,"y":79,"w":752,"h":162},{"id":"b9693cc84311ae8e","type":"sqlite","z":"295d40790bd21f48","g":"d248b8387940a5bc","mydb":"5e345bf74f08f47c","sqlquery":"fixed","sql":"CREATE TABLE IF NOT EXISTS recipes (\n    recipe_id TEXT PRIMARY KEY NOT NULL,          -- Unique internal identifier (e.g., 'PX-BLEND-V3')\n    product_name TEXT NOT NULL,                   -- Human-readable product name (e.g., 'Premium Polymer Blend')\n    version_no TEXT NOT NULL,                     -- Recipe version (e.g., '3.1', 'A-Rev')\n    target_temperature_c REAL NOT NULL,           -- Target temperature in Celsius\n    mixing_speed_rpm INTEGER NOT NULL,            -- Mixing speed in Revolutions Per Minute\n    pressure_bar REAL,                            -- Pressure in Bar (more common than PSI in many regions)\n    material_a_kg REAL NOT NULL,                  -- Quantity of main material A in kilograms\n    material_b_kg REAL,                           -- Quantity of secondary material B in kilograms (optional for some recipes)\n    catalyst_ml REAL,                             -- Quantity of catalyst in milliliters (specific additive)\n    hold_time_min INTEGER NOT NULL,               -- Hold time in minutes at target temperature\n    description TEXT,                             -- Optional notes about the recipe\n    created_date TEXT NOT NULL                    -- Date recipe was created/last updated (ISO format)\n);","name":"","x":470,"y":120,"wires":[["f9e35c9c3b213d47"]]},{"id":"e7619cfe7c7fdaa9","type":"inject","z":"295d40790bd21f48","g":"d248b8387940a5bc","name":"Create Recipe table","props":[],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":200,"y":120,"wires":[["b9693cc84311ae8e"]]},{"id":"f9e35c9c3b213d47","type":"debug","z":"295d40790bd21f48","g":"d248b8387940a5bc","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":700,"y":120,"wires":[]},{"id":"c719f2b43aef7d44","type":"sqlite","z":"295d40790bd21f48","g":"d248b8387940a5bc","mydb":"5e345bf74f08f47c","sqlquery":"fixed","sql":"INSERT INTO recipes (recipe_id, product_name, version_no, target_temperature_c, mixing_speed_rpm, pressure_bar, material_a_kg, material_b_kg, catalyst_ml, hold_time_min, description, created_date)\nVALUES\n('POLY_BLEND_V3.1', 'Advanced Polymer Resin', '3.1', 195.0, 850, 1.5, 1250.0, 450.0, 15.0, 60, 'Improved tensile strength for injection molding. Requires high shear.', '2025-01-10'),\n('COATING_ECO_V1.2', 'Eco-Shield Protective Coating', '1.2', 110.0, 320, 0.8, 800.0, 200.0, 5.0, 30, 'Low VOC formulation, quick dry time. Mix gently.', '2024-11-22'),\n('ADHESIVE_FAST_CURE', 'Industrial Adhesive X-500', '1.0', 70.0, 550, 2.1, 300.0, 120.0, 10.0, 15, 'Fast-curing formulation for rapid assembly. Must maintain precise temperature.', '2025-03-01'),\n('FOOD_LIQUID_PURE', 'PureBev Beverage Base', '2.0', 85.0, 180, 0.5, 2000.0, 500.0, NULL, 45, 'Food-grade liquid base. Ensure sterile conditions. No catalyst used.', '2025-02-15'),\n('PHARMA_API_MIX', 'API Compound Blend Alpha', '1.0', 45.0, 400, 1.2, 50.0, 25.0, 2.0, 90, 'Active Pharmaceutical Ingredient blend. Temperature sensitive. Strict hold time.', '2025-04-05');","name":"","x":470,"y":200,"wires":[["bb3da75dcf2b4cdd"]]},{"id":"69a914bb0479925c","type":"inject","z":"295d40790bd21f48","g":"d248b8387940a5bc","name":"Populate Demo Recipes","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":210,"y":200,"wires":[["c719f2b43aef7d44"]]},{"id":"bb3da75dcf2b4cdd","type":"debug","z":"295d40790bd21f48","g":"d248b8387940a5bc","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":700,"y":200,"wires":[]},{"id":"5e345bf74f08f47c","type":"sqlitedb","db":"/tmp/sqlite","mode":"RWC"}]
```
::

### Initial Setup: Populate Dropdown and Define Form Structure

We want this flow to run when our dashboard page loads. It queries your exiting recipes and then dynamically defines both the **ui-dropdown's** options and the **ui-form's** structure.

1. Drag an Event node onto the canvas. This node send a message when the dashboard page loads.
2. Connect the **ui-event** node to an **sqlite** node. Configure it to connect to your SQLite database, set SQL Query to fixed, and enter `SELECT recipe_id FROM recipes;` as the query. Ensure Return Output is set to a "Parsed JSON Object".
3. Connect the **sqlite** node's output to a new **function** node. Name it "Generate Form & Dropdown Definition". In this function, you will write JavaScript to dynamically create the form's elements and populate the dropdown options. Set the function to have 2 outputs.

```javascript
// msg.payload contains the recipe_id and recipe_name from SQLite query.
let dropdownOptions = [];
if (msg.payload && Array.isArray(msg.payload)) {
    dropdownOptions = msg.payload.map(recipe => {
        return {
            value: recipe.recipe_id,        // Internal value for dropdown
            label: recipe.recipe_name       // Display text for dropdown
        };
    });
}

// --- Define the ui_form structure (all input elements) ---
let formElements = [
    { type: "text", label: "Recipe ID", key: "recipe_id_display", readOnly: true },
    { type: "text", label: "Product Name", key: "product_name", readOnly: true },
    { type: "text", label: "Version No.", key: "version_no", readOnly: true },
    { type: "number", label: "Target Temp (°C)", key: "target_temperature_c", required: true },
    { type: "number", label: "Mixing Speed (RPM)", key: "mixing_speed_rpm", required: true },
    { type: "number", label: "Pressure (Bar)", key: "pressure_bar" },
    { type: "number", "label": "Material A (kg)", "key": "material_a_kg", "required": true },
    { type: "number", "label": "Material B (kg)", "key": "material_b_kg" },
    { type: "number", "label": "Catalyst (ml)", "key": "catalyst_ml" },
    { type: "number", "label": "Hold Time (min)", "key": "hold_time_min", "required": true },
    { type: "multiline", "label": "Description", "key": "description", "readOnly": true, "rows": 3 }
];

// Output 1: For the ui_dropdown node (msg.options)
let msg1 = { options: dropdownOptions }; 

// Output 2: For the ui_form node (msg.ui_update.options)
let msg2 = { ui_update: { options: formElements } };

return [msg1, msg2]; // Send two separate messages
```

4. Drag a **ui-dropdown** node onto the canvas. Configure its dashboard group and label (Select Recipe ID:). Ensure its "Options" list is empty, as it will be populated dynamically. Connect the first output of the "Generate Form & Dropdown Definition" **function** to the input of this **ui\_dropdown** node.
5. Drag a **ui-form** widget onto the canvas. Configure its dashboard group and label (Recipe Parameters). Crucially, leave its "Options" list completely empty in its properties. Set the "Submit" button text to Apply and "Cancel" to Clear. Connect the second output of the "Generate Form & Dropdown Definition" **function** to the input of this **ui-form** node.
6. Deploy your flow and open the dashboard. You should now see your form with the "Select Recipe" dropdown populated.

### Populate Form on Recipe Selection

This flow segment pre-fills the form with recipe details when an operator selects a recipe from the dropdown.

1. Connect the output of your dropdown node (from Step 2). This output will carry the selected `recipe_id` in `msg.payload`.
2. Connect the **ui-dropdown** output to a **change** node. Name it Set Params & Flow Context. Set `msg.params.$recipe_id` to `msg.payload` and `flow.selected_recipe_id` to `msg.payload`.
3. Connect the **change** node to an **sqlite** node. Configure it for your database, set SQL Query to prepared statement, and enter `SELECT * FROM recipes WHERE recipe_id = $recipe_id;` as the prepared statement. Ensure you add a rule in change node:
   - `msg.params.$recipe_id` to `msg.payload.recipe_id`
4. Connect the **sqlite** node's output to a **function** node. Name it Show values to form fields. This function will format the retrieved recipe details to pre-fill the form.

```javascript
let recipeDetails = msg.payload[0]; // Get the first (and only) result

if (recipeDetails) {
    // Map recipe details to the keys of your form elements for pre-filling.
    msg.payload = {
        recipe_id_display: recipeDetails.recipe_id, // For the display field in ui_form
        product_name: recipeDetails.product_name,
        version_no: recipeDetails.version_no,
        target_temperature_c: recipeDetails.target_temperature_c,
        mixing_speed_rpm: recipeDetails.mixing_speed_rpm,
        pressure_bar: recipeDetails.pressure_bar,
        material_a_kg: recipeDetails.material_a_kg,
        material_b_kg: recipeDetails.material_b_kg,
        catalyst_ml: recipeDetails.catalyst_ml,
        hold_time_min: recipeDetails.hold_time_min,
        description: recipeDetails.description
    };
} else {
    // If selection is cleared, prepare an empty payload (except for selected_recipe_id)
    msg.payload = {}; 
}
return msg;
```

5. Connect the output of the Show values to form fields **function** node back to the input of your form widget (from Step 2).

### Handle Form Submission & Update Database

This flow segment processes the data when the operator clicks the "Apply" button, updating the recipe in your database and providing feedback.

1. Connect a new wire from the main output of your **ui-form** widget. This output fires when the form is submitted.
2. Connect the form's output to a **change** node. Name it Prepare Update Params. This node will prepare the `msg.params` object for the SQLite update.

- Rules:
  - set `msg.params` to JSON `{}`.
  - set `msg.params.$recipe_id` to `flow.selected_recipe_id`.

For each editable field in your form (e.g., target\_temperature\_c, mixing\_speed\_rpm), add a rule: set `msg.params.$[FIELD_NAME] to msg.payload.[FIELD_NAME]`.

3. Connect the **change** node to an **sqlite** node.
   - Configure it for your database, set SQL Query to prepared statement.
   - Paste your UPDATE SQL query into the "Prepared Statement" field, using the $parameters that match your msg.params.
4. Connect the **sqlite** node's output to a **switch** node. Name it Check for Update Success.

- Set Property to payload and Rules to is empty.
- Add 1 output.

5. Connect the **switch** node's output to a **change** node. Name it Success Message.

- Set `msg.payload` to str "Recipe updated successfully".

6. Connect the **change** node to a **ui-notification** node to display the success message on the dashboard.
7. Deploy the flow, open the dashboard, and try selecting different recipes and updating them.

For practice, we use an SQLite database. However, since your recipe is often used across an entire production line, it is recommended to store it in a dedicated database instead of locally in SQLite. This ensures it is accessible to all systems and can be utilized by other components in the workflow.

*Note: This is just a simple demo we built. When using it in a production environment, you might need to make additional considerations based on your specific requirements."*

:video{ariaLabel="FlowFuse form designed for updating production recipes. The form shows a dropdown for recipe selection, dynamically populates fields with recipe parameters, and allows the user to modify and submit updates." autoPlay="true" height="415" loop="true" muted="true" playsInline="true" preload="none" width="800"}&#x2A;A demonstration of the dynamic **form for recipe updates** in action, showing how it streamlines data entry and submission.*

Below is the complete flow of the system we built.

::render-flow{:height='300'}
```json
[{"id":"a6eb2848159c68f4","type":"ui-form","z":"295d40790bd21f48","name":"Form","group":"83b5766434e42005","label":"","order":2,"width":0,"height":0,"options":[{"label":"demo","key":"demo","type":"text","required":false,"rows":null}],"formValue":{"demo":""},"payload":"","submit":"Apply","cancel":"Clear","resetOnSubmit":true,"topic":"topic","topicType":"msg","splitLayout":"","className":"","passthru":false,"dropdownOptions":[],"x":1170,"y":800,"wires":[["26303a8d6785dc68"]]},{"id":"5b2f1f1e42391625","type":"function","z":"295d40790bd21f48","name":"Generate Form & Dropdown Definition","func":"// msg.payload contains the recipe_id and recipe_name from SQLite query.\nlet dropdownOptions = [];\nif (msg.payload && Array.isArray(msg.payload)) {\n    dropdownOptions = msg.payload.map(recipe => {\n        return {\n            value: recipe.recipe_id,        // Internal value for dropdown\n            label: recipe.recipe_name       // Display text for dropdown\n        };\n    });\n}\n\n// --- Define the ui_form structure (all input elements) ---\nlet formElements = [\n    { type: \"text\", label: \"Product Name\", key: \"product_name\", readOnly: true },\n    { type: \"text\", label: \"Version No.\", key: \"version_no\", readOnly: true },\n    { type: \"number\", label: \"Target Temp (°C)\", key: \"target_temperature_c\", required: true },\n    { type: \"number\", label: \"Mixing Speed (RPM)\", key: \"mixing_speed_rpm\", required: true },\n    { type: \"number\", label: \"Pressure (Bar)\", key: \"pressure_bar\" },\n    { type: \"number\", \"label\": \"Material A (kg)\", \"key\": \"material_a_kg\", \"required\": true },\n    { type: \"number\", \"label\": \"Material B (kg)\", \"key\": \"material_b_kg\" },\n    { type: \"number\", \"label\": \"Catalyst (ml)\", \"key\": \"catalyst_ml\" },\n    { type: \"number\", \"label\": \"Hold Time (min)\", \"key\": \"hold_time_min\", \"required\": true },\n    { type: \"multiline\", \"label\": \"Description\", \"key\": \"description\", \"readOnly\": true, \"rows\": 3 }\n];\n\n// Output 1: For the ui_dropdown node (msg.options)\nlet msg1 = { options: dropdownOptions };\n\n// Output 2: For the ui_form node (msg.ui_update.options)\nlet msg2 = { ui_update: { options: formElements } };\n\nreturn [msg1, msg2]; // Send two separate messages","outputs":2,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":870,"y":780,"wires":[["80a5a9f40e19f5a7"],["a6eb2848159c68f4"]]},{"id":"9038572da428216c","type":"sqlite","z":"295d40790bd21f48","mydb":"5e345bf74f08f47c","sqlquery":"prepared","sql":"SELECT * FROM recipes WHERE recipe_id = $recipe_id;","name":"","x":1610,"y":760,"wires":[["462db842ba535af6"]]},{"id":"c2536d7e7a260bc1","type":"change","z":"295d40790bd21f48","name":"","rules":[{"t":"set","p":"params","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"params.$recipe_id","pt":"msg","to":"payload","tot":"msg"},{"t":"set","p":"selected_recipe_id","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1420,"y":760,"wires":[["9038572da428216c"]]},{"id":"462db842ba535af6","type":"function","z":"295d40790bd21f48","name":"Show values to form fields","func":"// msg.payload will be an array with one object: [{ recipe_id: '...', recipe_name: '...', ... }]\nlet recipeDetails = msg.payload[0]; // Get the first (and only) result\n\nif (recipeDetails) {\n    // Map recipe details directly to the keys of your form elements\n    // This msg.payload will be sent to the ui_form to pre-fill its fields\n    msg.payload = {\n        selected_recipe_id: recipeDetails.recipe_id, // Keep the dropdown selected\n        product_name: recipeDetails.product_name,\n        version_no: recipeDetails.version_no,\n        target_temperature_c: recipeDetails.target_temperature_c,\n        mixing_speed_rpm: recipeDetails.mixing_speed_rpm,\n        pressure_bar: recipeDetails.pressure_bar,\n        material_a_kg: recipeDetails.material_a_kg,\n        material_b_kg: recipeDetails.material_b_kg,\n        catalyst_ml: recipeDetails.catalyst_ml,\n        hold_time_min: recipeDetails.hold_time_min,\n        description: recipeDetails.description\n    };\n} else {\n    // Clear non-dropdown fields if no recipe found (e.g., if dropdown cleared)\n    let currentSelection = msg.payload.selected_recipe_id;\n    msg.payload = { selected_recipe_id: currentSelection }; // Keep dropdown value but clear others\n}\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1840,"y":760,"wires":[["9ff423aae018ab04"]]},{"id":"e495f9bc79062be3","type":"sqlite","z":"295d40790bd21f48","mydb":"5e345bf74f08f47c","sqlquery":"fixed","sql":"SELECT recipe_id FROM recipes;","name":"","x":570,"y":780,"wires":[["5b2f1f1e42391625"]]},{"id":"9d6013fa166356cf","type":"ui-event","z":"295d40790bd21f48","ui":"ee052dbdb58cf632","name":"","x":400,"y":780,"wires":[["e495f9bc79062be3"]]},{"id":"80a5a9f40e19f5a7","type":"ui-dropdown","z":"295d40790bd21f48","group":"83b5766434e42005","name":"Dropdown","label":"Select Recipe ID:","tooltip":"","order":1,"width":0,"height":0,"passthru":false,"multiple":false,"chips":false,"clearable":false,"options":[{"label":"","value":"","type":"str"}],"payload":"","topic":"topic","topicType":"msg","className":"","typeIsComboBox":true,"msgTrigger":"onChange","x":1190,"y":760,"wires":[["c2536d7e7a260bc1"]]},{"id":"9ff423aae018ab04","type":"link out","z":"295d40790bd21f48","name":"link out 1","mode":"link","links":["a4c1676c7c656ff3"],"x":2025,"y":760,"wires":[]},{"id":"a4c1676c7c656ff3","type":"link in","z":"295d40790bd21f48","name":"link in 1","links":["9ff423aae018ab04"],"x":905,"y":820,"wires":[["a6eb2848159c68f4"]]},{"id":"26303a8d6785dc68","type":"change","z":"295d40790bd21f48","name":"","rules":[{"t":"set","p":"params","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"params.$recipe_id","pt":"msg","to":"selected_recipe_id","tot":"flow"},{"t":"set","p":"params.$product_name","pt":"flow","to":"payload.product_name","tot":"msg"},{"t":"set","p":"params.$version_no","pt":"msg","to":"payload.version_no","tot":"msg"},{"t":"set","p":"params.$target_temperature_c","pt":"msg","to":"payload.target_temperature_c","tot":"msg"},{"t":"set","p":"params.$mixing_speed_rpm","pt":"msg","to":"payload.mixing_speed_rpm","tot":"msg"},{"t":"set","p":"params.$pressure_bar","pt":"msg","to":"payload.pressure_bar","tot":"msg"},{"t":"set","p":"params.$material_a_kg","pt":"msg","to":"payload.material_a_kg","tot":"msg"},{"t":"set","p":"params.$material_b_kg","pt":"msg","to":"payload.material_b_kg","tot":"msg"},{"t":"set","p":"params.$catalyst_ml","pt":"msg","to":"payload.catalyst_ml","tot":"msg"},{"t":"set","p":"params.$hold_time_min","pt":"msg","to":"payload.hold_time_min","tot":"msg"},{"t":"set","p":"params.$description","pt":"msg","to":"payload.description","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1420,"y":800,"wires":[["656fb4832e9224b7"]]},{"id":"656fb4832e9224b7","type":"sqlite","z":"295d40790bd21f48","mydb":"5e345bf74f08f47c","sqlquery":"prepared","sql":"-- Update key parameters for a specific recipe\nUPDATE recipes\nSET \n    target_temperature_c = $target_temperature_c,\n    mixing_speed_rpm = $mixing_speed_rpm,\n    pressure_bar = $pressure_bar,\n    material_a_kg = $material_a_kg,\n    material_b_kg = $material_b_kg,\n    catalyst_ml = $catalyst_ml,\n    hold_time_min = $hold_time_min,\n    description = $description,\n    version_no = $version_no\nWHERE recipe_id = $recipe_id","name":"","x":1610,"y":800,"wires":[["e82526d367b028b3"]]},{"id":"81a84dcab301a18f","type":"ui-notification","z":"295d40790bd21f48","ui":"ee052dbdb58cf632","position":"center center","colorDefault":true,"color":"#000000","displayTime":"3","showCountdown":true,"outputs":1,"allowDismiss":true,"dismissText":"Close","allowConfirm":false,"confirmText":"Confirm","raw":false,"className":"","name":"","x":2110,"y":800,"wires":[[]]},{"id":"e82526d367b028b3","type":"switch","z":"295d40790bd21f48","name":"","property":"payload","propertyType":"msg","rules":[{"t":"empty"}],"checkall":"true","repair":false,"outputs":1,"x":1770,"y":800,"wires":[["20e94224438447c1"]]},{"id":"20e94224438447c1","type":"change","z":"295d40790bd21f48","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"Recipe updated successfully.","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":1920,"y":800,"wires":[["81a84dcab301a18f"]]},{"id":"83b5766434e42005","type":"ui-group","name":"Recipe Form","page":"a9aa17e3cfcd76d0","width":6,"height":1,"order":1,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"5e345bf74f08f47c","type":"sqlitedb","db":"/tmp/sqlite","mode":"RWC"},{"id":"ee052dbdb58cf632","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":true},{"id":"a9aa17e3cfcd76d0","type":"ui-page","name":"Recipe","ui":"ee052dbdb58cf632","path":"/recipe","icon":"home","layout":"notebook","theme":"326855cf654199bc","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":true,"disabled":false},{"id":"326855cf654199bc","type":"ui-theme","name":"Default Theme","colors":{"surface":"#222322","primary":"#222322","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
```
::

## Conclusion

So, getting your factory data digital doesn't have to be a headache. Relying on paper or tricky old systems just causes slowdowns and mistakes. Plus, many digital form tools are too complicated or don't play nice with your current setup.

That's where FlowFuse comes in. It lets your engineers build exactly what they need for the factory, using simple drag-and-drop tools – no coding required. This means you can ditch the manual steps, cut down on errors, save time, and even lower your IT costs.

Also wiith FlowFuse, you get accurate, real-time data and better control, helping your factory run smarter and much more efficiently.

*Want to see how FlowFuse can reduce costs, boost profits, and increase production? [Get in touch with us.](https://flowfuse.com/contact-us/)*


# FlowFuse 2.18: Smarter Monitoring, AI Integration, Improved DevOps, and a preview of exciting things to come

This release is focused on improvements that help you manage and optimize the performance of your Node-RED instances and takes an important step in integrating AI with FlowFuse so that you can build applications even more quickly.

## Enhanced Observability for Better Performance Management

![Screenshot of Performance feature](https://flowfuse.com/blog/2025/06/images/observability1.png)*Screenshot of Performance Feature*

Understanding how your Node-RED instances perform is crucial for maintaining reliable applications. Our new observability feature provides detailed CPU usage metrics at both the instance and team levels, giving you the visibility needed to optimize performance and troubleshoot issues before they impact your operations.

With these insights, you can make informed decisions about scaling your instances, identify performance bottlenecks, and ensure your Node-RED instances run smoothly in production environments. This feature is available exclusively for Enterprise customers, providing the enterprise-grade monitoring capabilities your organization needs.

## Blueprint: OpenAI LLM with Chat Agent

:video{controls="true" src="https://website-data.s3.eu-west-1.amazonaws.com/Blueprint+-+Open+AI+Chat.mp4"}*Video of OpenAI LLM Blueprint demo*

We're bringing AI speed and power directly to your FlowFuse Dashboard. The new LLM Blueprint enables you to deploy an AI chat agent that can query and analyze data connected to your FlowFuse environment.

This Blueprint makes it simple to surface insights relevant to your Node-RED flows, allowing team members to ask natural language questions and get immediate answers about their connected systems and devices. Whether you're monitoring sensor data, analyzing trends, or troubleshooting issues, the AI chat agent will speed up your workflow.

Check out the video demo to see it in action, featuring the agent connected to a worldmap node!

To put this Blueprint to use, check out the Blueprint page for [OpenAI LLM Chat Agent.](https://flowfuse.com/blueprints/ai/llm-chat-agent/)

## Complete Git Integration with Pull Support

Building on our previous Git push functionality, we've now added Git pull support, completing the core Git integration experience within FlowFuse.

You can now seamlessly synchronize changes from your remote repositories, collaborate more effectively with team members, and maintain consistent version history across your Node-RED projects.

More details are available in the [Git Integration changelog](https://flowfuse.com/changelog/2025/06/git-integration/).

## Self-Hosted Blueprint Support

Organizations running self-hosted FlowFuse installations can now take advantage of the Blueprints we publish, bringing the same rapid development capabilities to on-premises and private cloud deployments.

Self-hosted installations will automatically pull down the [blueprint library](https://flowfuse.com/blueprints/), and will stay up to date when we publish new blueprints.

This update ensures that all FlowFuse users, regardless of their deployment model, can benefit from our growing library of pre-built solutions.

## Where are we headed?

Our Engineering team is hard at work on the next major developments in bringing the speed of AI to FlowFuse, developing AI functionality that will be integrated directly into the Node-RED editor. This upcoming feature set will dramatically accelerate your development process, helping you build and deploy applications faster than ever before.

By combining AI assistance with Node-RED's visual programming approach, we're creating a development experience that's both more intuitive for newcomers and more powerful for experienced developers.

Here is a sneak peek of something we're working on: an AI chat in the Node-RED editor that allows you to ask questions about the instance you are working in.

:video{ariaLabel="Preview of AI in Node-RED Editor" autoPlay="true" height="679" loop="true" muted="true" playsInline="true" preload="none" width="971"}

## What else is new?

For a full list of everything that went into our 2.18 release, you can check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/){rel="&#x22;nofollow&#x22;"}.

We're always working to enhance your experience with FlowFuse. We're always interested in your thoughts about FlowFuse too. Your feedback is crucial to us, and we'd love to hear about your experiences with the new features and improvements. Please share your thoughts, suggestions, or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Which feature do you think you're most likely to use? Email me directly and let me know! You can reach me at <greg@flowfuse.com>.

Together, we can make FlowFuse better with each release!

## Try FlowFuse

### Self-Hosted

We're confident you can have self managed FlowFuse running locally in under 30 minutes. You can install FlowFuse using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

### FlowFuse Cloud

The quickest and easiest way to get started with FlowFuse is FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} now, and you'll have your own Node-RED instances running in the Cloud within minutes.


# Optimizing operations: Improve Industrial Operations with FlowFuse

The announcement of our latest $7.25 million funding round isn't just a milestone for FlowFuse; it's a catalyst for our mission to revolutionize how industrial data is accessed and used.

Thousands of IT professionals and citizen developers now collaborate with our product on their digital transformation, and we’re expecting hundreds of thousands more to join over the next few years. We're incredibly proud of our recent growth – nearly 5x in customers and revenue just last year, a trend that’s only accelerating. But more than that, we're thrilled by what this allows us to build for you.

Our focus has always been to empower engineers and operational managers to connect the physical shop floor with their digital enterprise systems. We see FlowFuse, powered by Node-RED, as that critical layer that makes data accessible, understandable, and actionable. And with this new investment, we're doubling down on making this experience even more powerful and intuitive.

## FlowFuse: The Low-Code Powerhouse for Industrial Data

FlowFuse is enabling customers to bridge the gap between their physical and digital operations. They are leveraging FlowFuse to extract the data required to implement new use-cases from a wide range of sources. FlowFuse spans both digital systems like ERPs and physical equipment on the shop floor. Using the low-code interface of Node-RED within the FlowFuse platform, this captured data is then transformed and efficiently transported to various destinations. Significantly, users are orchestrating multiple Node-RED instances through FlowFuse to collaboratively inform and automate operational decisions, even incorporating crucial operator feedback directly into the workflow.

FlowFuse creates a singular and unified platform for users that not only extracts and transports data but also actively utilizes it for decision-making and incorporates human expertise, effectively closing the loop through fusing your operations with the corporate systems. The void often filled by complex SCADA systems and disparate, siloed solutions can now be seamlessly integrated and managed with FlowFuse.

![FlowFuse, the low-code powerhouse for inustrial data](https://flowfuse.com/blog/2025/06/images/low-code-powerhouse-for-industrial-data.png){dataZoomable=""}

## Where We're Going: Infusing AI for an Even Smarter Tomorrow

Over the past years we’ve been focused on augmenting Node-RED to enable it to scale better for an organization. This entails many facets:

- Ensure companies that are in regulated industries meet their compliance frameworks.
- Make it easy to run and maintain hundreds or thousands of Node-REDs.
- Extend DevOps to operational technology teams, ensure development is done outside of production systems.

Our shift towards becoming an &#x2A;**end to end*** platform to connect the physical world with your digital realm is next, and we’ve already started this journey. Over the past months we’ve enabled customers to store data long term by allowing them to store files on the platform. Also, we noticed that customers took longer than ideal to transport data between data consumers and producers and back again. Building a data orchestration layer, for example through a Unified Namespace (UNS), is vital to ensure data is available for building applications. So FlowFuse has allowed thousands of clients to send data through MQTT, a quick on-ramp to further the abilities for the platform of FlowFuse. Lastly, in the next FlowFuse release a data storage layer will be provided to persist and allow querying of events.

While we'll continue to enhance the core capabilities users already love, a significant portion of this new investment is earmarked for integrating AI more deeply into the FlowFuse platform. The FlowFuse Expert already has proven itself countless times. However, we believe improving our AI suggestions and capabilities are the key to unlocking the next level of low-code development.

While Node-RED is low-code and enables many engineers the power to integrate, automate, and interact with their operations, we want every engineer – mechanical, electrical, or operational – to harness its full potential quickly. AI will act as an intelligent guide, helping new users understand Node-RED's capabilities, learn best practices, and troubleshoot effectively. Imagine an assistant that helps you build your first flow, suggests optimal configurations, or explains complex functions in simple terms.

Furthermore, we see that AI can offer suggestions, identify potential optimizations, and even help generate partial flows in Node-RED. Allowing both new and experienced users to gain momentum.
FlowFuse is on a mission to get a billion people automating, having AI make suggestions allows more people to learn how, and get started, as well as advanced users remove boilerplate to create and get to brass tacks faster.

## The Vision: Everyone Can Increase Operational Excellence

There are millions of brilliant engineers and managers out there who understand their operations inside and out. They know what needs to be optimized, and have hunches to validate, but often lack the accessible tools to bridge the data gap. That’s what FlowFuse is for.

We are committed to making it super easy to get data, derive insight, and act on that insight to optimize operations. The infusion of AI into our low-code platform is the next logical step in this journey. We're incredibly excited about the path ahead and grateful to our customers, partners, and investors for their support. The future of industrial operations is intelligent, connected, and user-empowered – and we're building it, together.

Want to see how FlowFuse can help you optimize your operations? Let's talk about your specific needs and see our platform in action. [Schedule a demo](https://flowfuse.com/book-demo/) with our team today.


# What to Measure on the Shop Floor: Factory KPIs Your MES Should Deliver

When discussing an [MES](https://flowfuse.com/blog/2025/06/what-is-mes/), data is always at the core. In previous articles, we explored the crucial steps of collecting and structuring valuable operational data. However, merely having cleaned and structured data is not enough. Many manufacturers find themselves staring at thousands of records while trying to monitor equipment performance or track production, only to feel overwhelmed and unsure of what actions to take. This is not just time-consuming; it often leads to delayed decisions and missed opportunities.

It is not the volume of data that drives improvement, it is clarity. What manufacturers need is a way to cut through the noise and highlight what truly matters. Factory KPIs (Key Performance Indicators) do exactly that. By focusing attention on the metrics that reflect performance and progress, they turn complexity into clarity and enable faster, more confident decisions.

In this article, we will dive into the most critical factory KPIs that directly impact your bottom line and are a fundamental part of any effective MES implementation. These KPIs empower you to drive profit and eliminate waste.

## Strategic KPI Categories for MES Success

There are hundreds of factory KPIs available, but not all are relevant for every MES implementation. To effectively leverage MES and improve factory operations, it is important to organize KPIs into logical categories that support its core objectives. These categories provide a holistic view of factory performance and align operational data with key manufacturing goals.

While many KPIs can be tracked, the most impactful ones in the context of MES typically fall into the following strategic categories:

- **Productivity**: Measuring the efficiency and output of production lines.
- **Processes**: Assessing how reliably the production chain functions.
- **Deadlines**: Tracking time-related performance metrics.
- **Inventory Management**: Ensuring materials and products flow smoothly.
- **Resources**: Evaluating equipment reliability and effectiveness.
- **Quality**: Measuring consistency, conformance, and product standards.

### Key Factory KPIs

Here are some of the most crucial KPIs your **MES** should help you track:

![KPIs Tables](https://flowfuse.com/blog/2025/06/images/KPIs.png){dataZoomable=""}*KPIs Tables*

## Turning Your Data into KPIs

Now that you understand the critical factory KPIs, the next logical question is: How does your MES deliver these insights? It’s not about manual calculations or picking up a calculator. The MES should have an integrated pipeline that handles everything, from raw data collection to the clear, actionable KPIs displayed on your [manufacturing dashboards](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/).

Once the data is collected and stored from the factory floor, this pipeline involves four essential stages:

- **Retrieve Data**: Pull the necessary stored data from the central database to perform KPI calculations.
- **Build Logic**: Define the rules, conditions, and formulas based on operational goals and KPI definitions.
- **Calculate KPIs**: Execute real-time or scheduled computations to derive metric values from the retrieved data.
- **Visualize**: Display the results using dashboards to provide clear insights for operators, supervisors, and decision-makers.

Once the workflow is set up, it should run automatically in the background, pulling in fresh data, applying the logic, and updating dashboards in real time. This ensures that performance metrics are always current and actionable.

### Building KPI Workflow with FlowFuse

To turn stored factory data into live KPIs, you need a solution with a powerful logic engine capable of processing at scale. Ideally, this solution should also support the rapid development of industrial applications. This is where **FlowFuse**, built on **Node-RED**, offers a clear advantage.

FlowFuse provides a low-code environment that unifies data connectivity, processing logic, and visualization. As covered in our previous articles, [MES Data Acquisition: How to Unlock Your Factory’s Hidden Data](https://flowfuse.com/blog/2025/06/data-acquisition-for-mes/) and [Structuring and Storing Data for Effective MES Integration](https://flowfuse.com/blog/2025/06/structuring-storing-data-mes-integration/), FlowFuse connects seamlessly to nearly all shop floor assets, prepares the data, and stores it in an accessible format.

From there, KPI logic flows can be built visually, defining how and when data is retrieved, how calculations are applied, and how results are displayed. This enables continuous KPI updates without manual effort.

![OEE Dashboard built with FlowFuse](https://flowfuse.com/blog/2025/06/images/oee.png){dataZoomable=""}:br*OEE Dashboard built with FlowFuse*

The example above shows an [OEE Dashboard](https://flowfuse.com/blueprints/manufacturing/oee-dashboard/), updated every 10 seconds using FlowFuse. Operational data is automatically retrieved, processed, and visualized, delivering accurate, real-time metrics through gauges, charts, and tables.

The following flow powers this dashboard:

![OEE Dashboard Flow](https://flowfuse.com/blog/2025/06/images/oee-dashboard-flow.png){dataZoomable=""}:br*OEE Dashboard Flow*

Each node in this flow performs a specific task: retrieving data, transforming it, applying OEE formulas, and delivering results to the dashboard. The entire process is automated and repeatable, providing a real-time view of equipment performance and production health.

#### Build Your First KPI Flow

Let’s see how easy it is to calculate a KPI with a practical example where we will calculate **Machine Downtime**, using demo data stored in an SQLite database.

##### To Begin

1. Login to the FlowFuse platform. If you don't have an account, you can register for a [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} to get started. Once registered, create a FlowFuse instance and open its editor.
2. Install the `node-red-node-sqlite` from the Palette Manager.
3. For the demo database, import the following database flow. Upon deployment, it will create an SQLite table and insert the demo data:

::render-flow{:height='300'}
```json
[{"id":"2b80c9ff5297fcf0","type":"inject","z":"fa7147e04d4d5ec3","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":620,"y":1540,"wires":[["0e3ad13c7f083c30"]]},{"id":"a0a5bf61836aaaba","type":"debug","z":"fa7147e04d4d5ec3","name":"debug 6","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1160,"y":1540,"wires":[]},{"id":"0e3ad13c7f083c30","type":"sqlite","z":"fa7147e04d4d5ec3","mydb":"0710931c9543fc07","sqlquery":"fixed","sql":"CREATE TABLE machine_runtime_logs (\n    id INTEGER PRIMARY KEY AUTOINCREMENT,\n    machine_id TEXT NOT NULL,\n    date DATE NOT NULL,\n    total_operational_time INTEGER NOT NULL,  -- in minutes, e.g., shift duration or planned availability\n    run_time INTEGER NOT NULL                 -- in minutes, actual machine active time\n);\n","name":"Create 'machine_runtime_logs' table","x":910,"y":1540,"wires":[["a0a5bf61836aaaba"]]},{"id":"d9b8478110727f43","type":"inject","z":"fa7147e04d4d5ec3","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":620,"y":1620,"wires":[["65e503477a2e5349"]]},{"id":"65e503477a2e5349","type":"sqlite","z":"fa7147e04d4d5ec3","mydb":"0710931c9543fc07","sqlquery":"fixed","sql":"INSERT INTO machine_runtime_logs (machine_id, date, total_operational_time, run_time) VALUES\n('BX02', '2025-06-10', 480, 410),\n('AX01', '2025-06-10', 480, 465),\n('BX02', '2025-06-11', 480, 400),\n('AX01', '2025-06-12', 480, 455),\n('BX02', '2025-06-12', 480, 390),\n('AX01', '2025-06-11', 480, 470),\n('AX01', '2025-06-13', 480, 460),\n('BX02', '2025-06-13', 480, 420),\n('AX01', '2025-06-14', 480, 405),\n('AX01', '2025-06-14', 480, 450);\n","name":"Insert Demo Data","x":850,"y":1620,"wires":[["45f1950b01ebb3f3"]]},{"id":"45f1950b01ebb3f3","type":"debug","z":"fa7147e04d4d5ec3","name":"debug 7","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1160,"y":1620,"wires":[]},{"id":"0710931c9543fc07","type":"sqlitedb","db":"/tmp/sqlite","mode":"RWC"}]
```
::

##### Flow Setup

1. Drag an **Inject** node onto the canvas and configure it to trigger at your desired interval (e.g., every 10 seconds) to start the data retrieval process.
2. Drag a **Change** node and connect it to the Inject node, adding elements to include query parameters for sql query as shown in the following image.

![Change node setting parameters](https://flowfuse.com/blog/2025/06/images/params-change-node.png){dataZoomable=""}*Change node setting parameters*

3. Drag an **SQLite** node, connect it to the Change node, and configure it with following sql statement and select set query to "Prepared Statement"

```sql
SELECT *
FROM machine_runtime_logs
WHERE machine_id = $machine_id
  AND date BETWEEN $start_date AND $end_date;
```

4. Drag a **Split** node and connect it to the SQLite node to break down the returned array or multiple rows from the database.
5. Drag **two Join** nodes and connect them to the output of the Split node.
6. Configure the **first Join** node in *Reduce* mode to sum `total_operational_time` using the expression `$A + payload.total_operational_time`.
7. Configure the **second Join** node in *Reduce* mode to sum `run_time` using the expression `$A + payload.run_time`.
8. Drag a **Change** node and connect it to the first Join node to store `msg.payload` as `flow.total_operational_time`.
9. Drag another **Change** node and connect it to the second Join node to store `msg.payload` as `flow.run_time`.
10. Drag a **new Change** node and connect both previous Change nodes to it, then set `msg.payload` using the following JSONata expression to calculate Machine Downtime Percentage:

```text
(($flowContext("total_operational_time") - $flowContext("run_time")) / $flowContext("total_operational_time")) * 100
```

11. Drag a **Debug** node onto the canvas, connect it to the last Change node, and configure it to display `msg.payload`.
12. **Deploy** the flow to continuously calculate and output the Machine Downtime Percentage in real time.

After deploying the flow, observe the debug sidebar on the right. You'll see the calculated machine downtime percentage being continuously printed. To present this data visually, leverage [Flowfuse Dashboard](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"}.

![Downtime printed on debug panel](https://flowfuse.com/blog/2025/06/images/downtime.png){dataZoomable=""}*Downtime printed on debug panel*

You’ve just seen how easy it is to calculate a foundational KPI like machine downtime. But with FlowFuse’s low-code environment, this is just the beginning. You not only connect, collect, transform, and visualize data, but also scale effortlessly.

FlowFuse enables you to manage thousands of device instances remotely, with built-in security, access control, and version management. This level of control ensures consistency across your factory operations and allows you to deploy updates and changes quickly with confidence.

There is much more to explore, FlowFuse gives you the flexibility and power to build a fully integrated, intelligent MES solution that grows with your manufacturing needs.

**What does this mean for your factory?**

- You'll put more money in your pocket, by slashing hidden waste and squeezing every drop of efficiency out of your machines and time.
- You'll be in total control, ditching the daily firefighting for a clear view that lets you fix problems before they even start.
- You'll produce quality you're genuinely proud of, every single time, catching issues on the spot for fewer headaches and happier customers.
- You'll unleash the genius of your own team, giving them the insights they need to innovate and drive continuous improvement on the floor.
- You'll leap into tomorrow's factory, today, rapidly building powerful solutions that make your entire operation smarter, faster, and truly future-ready.

## Final Thought

We've talked a lot about Factory KPIs and how they're not just some numbers on a screen; they're your secret weapon. And we've seen how a powerful MES, especially one built on something as flexible as FlowFuse, is the real workhorse, taking all that raw data and turning it into clear, actionable gold.

Forget about guessing games. With the right MES and smart KPIs, you get the full picture, right now. It means knowing what is happening on your floor, fixing issues fast, and making decisions that drive measurable impact.

[Schedule a demo](https://flowfuse.com/book-demo/) and we'll show you how FlowFuse transforms your operations.


# Structuring and Storing Data for Effective MES Integration

Collecting factory data for your MES is just the first step. If that data isn't properly organized, cleaned, and stored, it's a jumbled mess, leading to missed opportunities and wasted investments. Disorganized information prevents your MES from quickly finding, understanding, and comparing crucial data, directly impacting production, increasing errors, and hindering confident decision-making.

FlowFuse simplifies [live factory data acquisition](https://flowfuse.com/blog/2025/06/data-acquisition-for-mes/), and now it's time to make that data work harder. This article dives into best practices for structuring and storing factory data, helping you maximize your MES's performance and turn raw information into a powerful tool.

## Core Strategies for Structuring Your Factory Data

Now that we understand the importance of data structuring, let's explore how to achieve it. This involves giving your data a clear shape and defining rules, ensuring that every system, that is part of your MES, can easily interpret the meaning of each piece of information.

Here are some straightforward ways we get data structred:

- **Making a Plan for Your Data (Data Modeling):** This is like drawing a simple map for your data. It helps you decide exactly what pieces of information you'll collect (like machine temperature, how many items are made, or who operated the machine) and how they connect to each other. This keeps everything neat and consistent. For example, a data model might say that every "production run" must have a "start time" and an "end time." This makes sure your MES always gets the full picture and avoids confusing or incomplete information. On an [automotive](https://flowfuse.com/industries/automotive/) line, that might mean every changeover event carries the same machine ID, line ID, and torque value, in the same units, no matter which plant it happened in.
- **Speaking the Same Language (Standardizing):** Imagine if everyone in your factory used different words for the same thing. It would be confusing! Standardizing means always using the same names, units, and formats everywhere. For example, if you measure temperature, always use Celsius. If one machine sends "TempC" and another just "Temperature," standardizing ensures both are read as "Temperature in Celsius." This prevents your MES from getting confused by different terms for the same data.
- **Adding the Full Story (Contextulization):** A raw number like "100" by itself doesn't tell you much. But if you add "100 items made by Machine A on June 10th at 2:00 PM in Batch 123," suddenly you know the whole story! This means attaching important details like the exact time, the machine's name, the batch number, or who was working at that moment. This extra information makes raw numbers meaningful, so your MES can track things accurately and you can make smarter decisions based on the full picture.

## How FlowFuse Brings Your Data Strategy to Life

FlowFuse simplifies data structuring with its intuitive, drag-and-drop environment. Raw machine data, often just numeric signals, can be enriched, formatted, and organized in real time, **without writing any code**.

You can easily:

- Add timestamps to readings
- Associate data with specific machines or lines
- Convert units (e.g., Fahrenheit to Celsius)
- Rename fields for consistency

FlowFuse comes with standard nodes, like `split`, `change`, `join`, and `switch`. These let you visually tell FlowFuse how to transform your data. These nodes handle all the technical work for you. You just connect the blocks that clean your data, add context, and prepare it for use in monitoring dashboards or other industrial applications.

There's another simple and powerful node to tell you about. It lets you handle data modeling, standardization, and contextualization, plus it checks your data to make sure it's in the correct range or type. We call this method JSON Schema validation.

> **JSON Schema** is a vocabulary that allows you to annotate and validate JSON documents. It defines the structure, data types, and validation rules, ensuring consistency and interoperability across different applications and systems.

### Setting Up JSON Schema Validation

To get started, open your **FlowFuse instance editor**.

Next, you'll need to install the specific node for JSON Schema validation. Search for and install `node-red-contrib-json-full-schema-validator`.

Once the node is installed, your next step is to **plan your data schema**. This involves deciding:

- **Which properties are essential** for your data.
- **What data types** these properties should have (e.g., number, string, boolean).
- **The units** for numerical data (e.g., if it's temperature, should it be Celsius or Fahrenheit?).
- **Valid ranges** for your data (e.g., a temperature range of -40°C to 150°C).
- Other factors like **precision**, **mandatory fields**, and any **additional attributes**.

After planning, you'll prepare this schema in **JSON format**. For a comprehensive guide on how to define your JSON Schemas, check out this helpful: [Getting Started Guide](https://json-schema.org/learn/getting-started-step-by-step){rel="&#x22;nofollow&#x22;"}.

```json
{
  "title": "Hydraulic Pump",
  "type": "object",
  "required": ["timestamp", "temperature", "pressure"],
  "properties": {
    "timestamp": {
      "type": "string",
      "format": "date-time",
      "description": "Timestamp of when the data was recorded."
    },
    "temperature": {
      "type": "object",
      "required": ["value", "unit"],
      "properties": {
        "value": {
          "type": "number",
          "description": "The temperature value.",
          "minimum": 0
        },
        "unit": {
          "type": "string",
          "enum": ["Celsius"],
          "description": "The unit of the temperature value."
        }
      }
    },
    "pressure": {
      "type": "object",
      "required": ["value", "unit"],
      "properties": {
        "value": {
          "type": "number",
          "description": "The pressure value.",
          "minimum": 0
        },
        "unit": {
          "type": "string",
          "enum": ["Pascal"],
          "description": "The unit of the pressure value."
        }
      }
    }
  }
}
```

This JSON schema defines the structure for data related to a hydraulic pump. It includes three key properties: `timestamp`, `temperature`, and `pressure`. The `timestamp` must be in a valid date-time format. Both `temperature` and `pressure` require two properties: value (a number representing the actual measurement) and `unit` (which must be Celsius for `temperature` and Pascal for `pressure`). Both values must be greater than or equal to zero. This schema ensures that all data is recorded with the correct units and valid values, maintaining consistency and reliability.

### Implementing Data Schema Validation

Let's implement the data schema validation mechanism to ensure each incoming data adheres to the specified JSON schema.

1. Drag the **JSON Full Schema Validator** node onto the Node-RED canvas.
2. Double-click the node to open its settings.
3. Copy and paste your schema into the node’s schema field.

![Configuring "JSON Full Schema Validator" node with JSON schema for our data ](https://flowfuse.com/blog/2025/06/images/json-full-validator-node.png){dataZoomable=""}*Configuring "JSON Full Schema Validator" node with JSON schema for our data*

4. Click **Done** to save the changes.
5. Connect the input of the **JSON Full Schema Validator** node to the data source from where your data is coming.
6. Connect the node's first output to another node to process or handle the validated data (e.g., an MQTT node, a database node, or any other destination).
7. Connect the second output to the flow that will handle the situation where data does not meet the schema. This could be a notification flow sending an email or Telegram to your team or a dashboard alert.
8. Deploy the flow.

Now, let's understand this with an example. Below is the data that we are receiving from the PLC. After transforming it, we’ve added essential properties such as unit and value. However, notice that the data doesn't meet the schema definition because the temperature is given in Fahrenheit and is a negative number, which isn't within the expected range.

![Message passes through the second output and includes errors when it does not align with the data schema.](https://flowfuse.com/blog/2025/06/images/invalid-data.png){dataZoomable=""}&#x2A;Message passes through the second output and includes errors when it does not align with the data schema.*

If the data doesn't align with the data schema, it will pass through the "JSON Full Schema Validator" node and flow through the second output. The message will contain an error array with detailed information about what is wrong with the data (e.g., incorrect unit or out-of-range value). From this output, you can easily connect email or Telegram nodes to send alert notifications.

When the data meets the schema, it passes through the first output without errors. The validated data is then sent to the next stage in the flow.

![Message passes through the first output and does not include errors when it aligns with the data schema.](https://flowfuse.com/blog/2025/06/images/valid-data-message.png){dataZoomable=""}&#x2A;Message passes through the first output and does not include errors when it aligns with the data schema.*

## Where to Keep All That Factory Data

Once your factory data is structured and validated, you need a smart place to store it. Different kinds of information often require different storage types to be most useful for your MES.

Here are the main types of storage typically used for factory data:

- **Time-Series Databases (TSDBs):** Perfect for constantly changing data like sensor readings (temperature, machine speed). They handle massive updates efficiently, ideal for spotting trends over time. Think of them as a super-efficient diary recording every moment. **InfluxDB** and **TimescaleDB** are good examples.
- **Standard Databases (SQL Databases):** Best for structured information with clear connections, such as production orders, material usage per batch, or quality check results. They keep data organized and ensure correct links between pieces of information, like a well-organized spreadsheet. You'll often see **PostgreSQL** or **MySQL** used here.
- **Data Lakes or Cloud Storage:** Use these for vast amounts of diverse data, even if it's not perfectly organized. They're great for long-term historical records or data you'll analyze later with advanced tools. Imagine them as a huge warehouse for anything, ready when you need to sort through it. **Amazon S3** and **Azure Data Lake Storage** are common examples.

When choosing storage, consider your data volume and speed, how often you need to access it (real-time vs. historical), cost, scalability, system connectivity, and data security.

## FlowFuse Also Helps with Data Routing to Storage

FlowFuse isn't just for changing and cleaning data; it also makes sure your data gets to the right storage spot.

It has tons of nodes for almost every database and cloud storage system you'll find in a factory today.

This includes direct **connections** to normal databases like [MySQL](https://flows.nodered.org/node/node-red-node-mysql){rel="&#x22;nofollow&#x22;"} and [PostgreSQL](https://flows.nodered.org/node/node-red-contrib-postgresql){rel="&#x22;nofollow&#x22;"} for your organized production data.

It also has special nodes for time-series databases like [InfluxDB](https://flows.nodered.org/node/node-red-contrib-influxdb){rel="&#x22;nofollow&#x22;"} and [TimescaleDB](https://flowfuse.com/node-red/database/timescaledb/) to handle fast sensor and machine data.

Plus, FlowFuse **connects** to big Data Lakes and Cloud Storage services like [Amazon S3](https://flows.nodered.org/node/node-red-node-aws){rel="&#x22;nofollow&#x22;"}, [Google Cloud Storage](https://flows.nodered.org/node/node-red-contrib-google-cloud){rel="&#x22;nofollow&#x22;"}, and [Microsoft Azure](https://flows.nodered.org/node/node-red-contrib-azure-storage){rel="&#x22;nofollow&#x22;"}.

**FlowFuse Fuels Your MES Dashboards and Applications**

Once your factory data is effectively structured, validated, and routed by FlowFuse to the right place, it becomes an incredibly powerful asset for your MES.

FlowFuse doesn't just manage your data; it also empowers you to easily build the user interface (UI) for your MES. You can create insightful dashboards and industrial applications using a no-code, drag-and-drop approach with components from [FlowFuse Dashboard](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"}. This allows you to design the screens operators use to visualize critical information and control processes, all built upon the reliable data foundation you've established.

## Final Thought

Your factory's success hinges on smart decisions, and smart decisions need good data. It's not enough to just collect information from your machines; you need to make sense of it.

That means organizing your data so it's clear and consistent. Think of it like putting all your tools in the right place – easy to find when you need them. You also need to clean up the data, getting rid of errors so you can trust what you see. Finally, you need to store it smartly, choosing the best spot for different types of information so it's always ready for use.

FlowFuse helps with all of this. It's like your data's personal assistant, collecting raw information, tidying it up, and sending it to the right storage, all without complicated coding. This ensures your Manufacturing Execution System (MES) gets the accurate, reliable data it needs to help you run your factory smoother and make better choices. Hundreds of other manufacturing companies are already using FlowFuse to transform their data into a powerful asset.

If you want to see FlowFuse in action, [book a demo](https://flowfuse.com/book-demo/) today!


# What Is MES (Manufacturing Execution System)? How It Works, Benefits, and Challenges

Ask three people on the same shop floor whether an order is on track and you might get three different answers. One is looking at a whiteboard. Another is checking an hour-old spreadsheet. The plans live in the ERP system, while machines run under SCADA and PLC control—but the layer connecting the two is often missing. That gap is where a manufacturing execution system belongs.

A Manufacturing Execution System (MES) connects live shop-floor activity with the production plan. It tracks the work order, materials, quality checks, and output as production happens, rather than requiring teams to reconstruct what occurred at the end of a shift.

:cta-image{alt="Build, Scale, and Manage the MES Capabilities You Need" cta="sign-up" src="https://flowfuse.com/blog/2025/06/images/mes-blog-cta.png"}

## How does an MES system work on the shop floor?

An MES pulls live data from machines, sensors, and operators, then uses it to guide and confirm each step of production. As a work order runs, it can track which machine is handling it, how much material is used, and whether output is meeting specification in real time.

The hard part is rarely the concept. It is [getting data out of equipment that was never built to share it](https://flowfuse.com/blog/2025/06/data-acquisition-for-mes/). A decade-old PLC may expose raw, uncontextualized tags over a vendor-specific protocol, while the SCADA system reading that data was designed to present it to an operator, not publish it upward. [Modbus](https://flowfuse.com/node-red/protocol/modbus/), EtherNet/IP, Profinet, [S7comm](https://flowfuse.com/blog/2025/01/integrating-siemens-s7-plcs-with-node-red-guide/), and [OPC UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/) can coexist on the same floor, and none inherently carry the order context an ERP system needs.

In a brownfield environment spanning several sites, that becomes a standing integration problem rather than a one-time project. [IT/OT connectivity](https://flowfuse.com/use-cases/it-ot-middleware/) moves production events and quality checks between [PLCs](https://flowfuse.com/landing/plc/), [SCADA](https://flowfuse.com/use-cases/scada/), and [enterprise systems](https://flowfuse.com/landing/enterprise-integration/) without relying on brittle point-to-point integrations.

Each new plant usually means remapping equipment, because legacy systems rarely match exactly from location to location. FlowFuse lets teams standardize operational applications and deploy them across sites, so they can reuse the logic while adapting connections for the equipment at each location.

![MES diagram showing FlowFuse connecting ERP, SCADA, edge devices, machines, production scheduling, workflow optimization, resource availability, and quality control](https://flowfuse.com/blog/2025/06/images/mes-diagram.png){dataZoomable=""}

## MES vs. SCADA: where each system's job ends

Both MES and SCADA deal with real-time data, but they sit at different levels of the [ISA-95 stack](https://flowfuse.com/blog/2023/08/isa-95-automation-pyramid-to-unified-namespace/): PLCs at Level 1, SCADA at Level 2, MES at Level 3, and ERP at Level 4. Each answers a different question.

### What SCADA controls, and where it stops

PLCs execute deterministic machine control: starting and stopping equipment and enforcing interlocks. SCADA sits above them, aggregating sensor readings, presenting them to operators, distributing setpoints, logging to a historian, and raising alarms when something is out of range.

SCADA does not track work orders, manage quality checks across a batch, or connect machine activity to the wider production plan. It reports on the machine, not the order.

### What MES manages that SCADA cannot

An MES applies raw machine data to the production plan: which order is running, whether the output meets specification, and what remains to complete a shift. It also manages work-order dispatch, material genealogy and traceability, and the sequence in which steps happen. Manufacturers weighing an [MES build-versus-buy](https://flowfuse.com/blog/2023/10/mes-build-buy/) decision should look beyond machine monitoring alone.

### How data moves between the two systems

MES and SCADA depend on a steady, two-way flow of data. SCADA reports machine and sensor states upward; MES sends work instructions, recipes, and quality parameters back down as supervisory setpoints. The MES never sits inside the control loop—interlocks and safety logic stay in the PLC.

When data moves through brittle custom integrations, a change to a machine or protocol can ripple through the whole system. Publishing data once to a broker, such as through [MQTT with Sparkplug B](https://flowfuse.com/blog/2024/08/using-mqtt-sparkplugb-with-node-red/), gives each layer a consistent way to subscribe to the information it needs.

## The real benefits of MES software

The return on MES is clearest when it is tied to measurable operational outcomes, not general claims about efficiency. Real-time production visibility can help teams spot issues before a batch or shift is complete.

### Fewer defects and less scrap

Real-time operational monitoring can catch quality issues as they happen instead of after a batch is finished. With live production data, teams can identify deviations early enough to correct them before more material is wasted.

### Faster time from idea to deployed application

Adding a quality check, connecting a new data point, or changing an operational workflow often means waiting on a development backlog. A low-code platform can shorten that cycle by helping engineers build, test, and deploy the needed logic with less custom code.

### Standardization without rebuilding at every site

Multi-site manufacturers can lose time rebuilding MES logic at every plant because equipment and legacy systems differ. FlowFuse supports reusable operational applications, so teams can [structure and store shop-floor data](https://flowfuse.com/blog/2025/06/structuring-storing-data-mes-integration/) consistently and deploy the same core integration pattern across sites.

## Final thoughts

An MES earns its place by closing the gap between what machines are doing and what the business needs to know. That depends far more on connectivity than on any single feature list. The distinction between SCADA and MES matters in practice because it defines how cleanly data can move from the machine to the production plan and back again.

For manufacturers managing several plants with different equipment and legacy systems, the real test is whether the MES logic has to be reinvented at every location. FlowFuse gives industrial teams a way to build operational applications once and deploy them where they are needed, without starting the integration work from scratch each time.


# Curated Node-RED Integrations: FlowFuse Certified Nodes 2.0

At FlowFuse, we believe that enterprises deserve access to the best of Node-REDs
custom nodes and solutions crafted by recognized experts who bring deep domain
knowledge and professional standards to their work. That's why we are thrilled
to announce a significant evolution of our ecosystem: **FlowFuse Certified Nodes
v2.0**.

## From Community Contribution to Professional Partnership

The Node-RED community has always had a pasionate and thrived on the
domain-expertise of its developers. The community has created an environment of
innovation, and now we're taking the next step to support enterprise-grade
solutions that companies are building on Node-RED today.

Our new **Certified Nodes** program we hope to elevate the community. We are
establishing a professional partnership with the most skilled node developers
and domain experts in the community.

Here’s how it works:

- **Expertise Recognition:** FlowFuse partners with developers who have
  demonstrated deep expertise in their domains, and may have already published
  nodes in their area of expertise. Ensuring our enterprise customers access the
  most knowledgeable contributors in each field.
- **Quality-Driven Selection:** Our certification process identifies nodes that
  excel in real-world environments, focusing on reliability, security,
  up-to-date documentation and professional implementation standards.
- **Comprehensive Solutions:** We welcome both open-source innovations and
  proprietary solutions. This approach allows experts to share their knowledge
  broadly while also providing targeted solutions for specific industry needs.

## What Does It Take to Become a Certified Publisher?

We are seeking partners who represent the pinnacle of expertise in their
respective domains. To join our certified ecosystem, we look for developers who
demonstrate:

- **Domain Expertise:** Deep knowledge and proven experience in the specific
  technology or industry vertical their nodes address
- **Professional Standards:** Commitment to enterprise-grade code quality,
  comprehensive testing, and security best practices
- **Continuous Innovation:** Ongoing development and enhancement of features
  that solve real-world enterprise challenges
- **Expert Support:** Ability to provide advanced technical support and guidance
  that goes beyond basic troubleshooting

Our certification process ensures that every node in the certified nodes
ecosystem meets these exacting standards. When enterprises choose certified
nodes, they gain access not just to code, but to the expertise and ongoing
support of recognized industry professionals. This creates a sustainable model
where expert knowledge is properly valued and enterprises receive the
reliability they require.

## Why Partner with FlowFuse?

Joining the FlowFuse Certified Nodes v2.0 program means becoming part of an
elite community of experts. Moreover, there's now a financial reward for doing
so. FlowFuse commits a fixed percentage of our FlowFuse Enterprise Platform Fee
to be distributed quarterly to the node authors.

If you are an expert developer or organization that has built exceptional
Node-RED nodes and are committed to maintaining the highest professional
standards, we want to collaborate with you. Let's work together to create a more
sustainable, professional ecosystem that connects enterprise users with the
industry's leading experts.

### Contact us to discuss your node certification

:hub-spot-form{cta="cta-certified-nodes-contact" form-id="6e02fe34-13c3-442b-8c27-9a12e72bba37" reference="certified-nodes-v2"}


# Node-RED Serial Port Tutorial: Connect RS232/RS485 Manufacturing Equipment (2026)

Many factories rely on machines, both new and old, that communicate via traditional serial interfaces such as **RS-232, RS-422, or RS-485**. These machines remain reliable but can be challenging to integrate with modern systems due to their connectivity style.

This guide shows you how to use FlowFuse (Node-RED with enterprise capabilities) to connect manufacturing equipment, collect data, and enable real-time monitoring, without modifying your original hardware.

## Making Sense of Serial Communication

Before diving into the wiring and flow configuration, it helps to understand how serial communication works, and why it is still relevant in industrial settings.

Serial ports move data one bit at a time, like passing beads on a string. This may sound old-fashioned, but it remains one of the most reliable and predictable ways to connect machines.

### Data Direction: Which Way Does It Flow?

Not all serial connections behave the same. The direction of data flow is defined by its duplex mode:

- **Simplex**: One-way only. Like a speaker giving a lecture, the machine talks, you just listen. This is common for devices like weight scales or scanners that only output data.
- **Half-Duplex**: Data can flow in both directions, but only one side can transmit at a time. This is like using a walkie-talkie. It is the most common operational mode for **RS-485** (using two wires), where multiple devices share the same communication line.
- **Full-Duplex**: Two-way, simultaneous communication. This is like a phone call, both sides can talk and listen at once. This is the typical mode for **RS-232** (using separate transmit and receive lines) and **RS-422**, which is designed for full-duplex, multi-drop scenarios (one sender, multiple listeners).

Across industrial environments, serial interfaces like **RS-232, RS-422, and RS-485** remain prevalent for device communication, depending on the wiring and number of connected devices.

### Data Format: How Is It Structured?

Machines are picky, they expect data to arrive in a specific format. Here are the key pieces that make up a serial data **frame**:

| Setting       | What It Means                                |
| :------------ | :------------------------------------------- |
| **Baud Rate** | Speed of transmission (e.g., 9600 or 115200) |
| **Data Bits** | The actual data, usually 7 or 8 bits         |
| **Parity**    | Optional error check, even, odd, or none     |
| **Stop Bits** | Marks the end of each message                |

### Interface Types: How Devices Physically Connect

Different machines use different physical standards. The most common are:

- **RS-232**: Typically full-duplex and one-to-one. Good for short-distance device communication.
- **RS-422**: Full-duplex, multi-drop (one sender, multiple receivers). Used for longer distances than RS-232.
- **RS-485**: Typically half-duplex and multi-device. Ideal for networks and even longer cable runs.
- **USB (via adapter)**: Most modern PCs and gateways use USB-to-Serial adapters to talk to RS-232/422/485 devices.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

## Setting Up Serial Communication with FlowFuse

Now that you understand how serial communication works and what kind of interfaces your machine might use, the next step is to put that knowledge into practice.

Using **FlowFuse**, you can easily establish serial communication, process the data, and integrate it into dashboards or automated workflows, all without modifying the original hardware.

Let's walk through how to set this up.

### Prerequisites

Before we start, ensure the following prerequisites are met:

- **Hardware Connection:** The machine must be physically connected to your system using a serial interface.
- **Node-RED Instance:** Make sure you have an instance of Node-RED up and running. The quickest way to do this is via FlowFuse. If you don't have an account, check out our [free trial](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"}.
- **Serialport Node:** Install the [node-red-node-serialport](https://flows.nodered.org/node/node-red-node-serialport){rel="&#x22;nofollow&#x22;"} package if it is not already available in your palette.

### Configuring the Serial Port Node

After installing the `node-red-node-serialport` package, follow these steps to configure serial communication in your Node-RED flow:

1. Drag a **Serial In** node from the Node-RED palette onto the canvas.
2. Double-click the node to open the configuration dialog.
3. Click the pencil icon next to the **Serial Port** field to add a new port configuration.
4. Enter the serial port path (e.g., `/dev/ttyUSB0` on Linux or `COM3` on Windows). You can also click the **search** option to list available ports.

:video{ariaLabel="Screenshot of Node-RED serial port node configuration showing available serial ports after clicking the search option." autoPlay="true" height="784" loop="true" muted="true" playsInline="true" preload="none" width="1036"}&#x2A;Screenshot of Node-RED serial port node configuration showing available serial ports after clicking the search option.*

6. Set the **baud rate**, **data bits**, **stop bits**, and **parity** according to your machine's specifications. These values must match the device exactly, or communication will fail or result in corrupted data.
7. Optionally, define an **input delimiter**, such as `\n` or `\r`, to segment incoming messages if your device sends data in lines or chunks.
   If the output is fixed-length, you can configure it to wait for a specific number of characters. You can also set a **timeout** to receive data at regular intervals.
   Later in the output section, you can choose to **add characters** back to the message, such as restoring the line break. :br![Screenshot of input and output settings in the Node-RED serial port node, showing options like delimiter, character count, and timeout.](https://flowfuse.com/blog/2025/07/images/input-output-serial-node.png){dataZoomable=""}&#x2A;Screenshot of input and output settings in the Node-RED serial port node, showing options like delimiter, character count, and timeout.*
8. Click **Done** to save the configuration.

Once the serial port is correctly configured and the device is connected, the **serial in** node will show a "connected" status below the node with a small green square.

![Screenshot of the Serial In node in Node-RED showing a green square that indicates a successful connection to the serial port.](https://flowfuse.com/blog/2025/07/images/serial-port-node-status.png){dataZoomable=""}&#x2A;Screenshot of the Serial In node in Node-RED showing a green square that indicates a successful connection to the serial port.*
{data-zoomable}

### Writing to Serial Port

To send data to a machine, use the **serial out** node in Node-RED. This is often necessary to trigger actions such as starting a process, requesting a reading, or changing an internal state.

Follow these steps to send a command:

1. Drag an **inject** node onto the canvas.
2. Set the **payload type** appropriate to your machine's requirements. This could be a string, number, raw buffer, or JSON object.
3. Add a **serial out** node and select the configured serial port.
4. Connect the **inject** node to the **serial out** node.

Once deployed, clicking the inject button will send the specified data to the machine via the serial interface.

In this guide, we are using a real machine connected via a serial interface. The machine is programmed to simulate a production process when it receives the `"START"` command (sent as a string). Once triggered, it begins incrementing the count of good and defect products and sends this data back over the same serial connection.

The next section demonstrates how to read and process this simulated production data using the **serial in** node.

### Reading and Processing Serial Data

Follow these steps to read and handle the serial data:

1. Drag a **serial in** node onto the canvas and configure it to use the same serial port.
2. Add a **debug** node and connect it to the output of the **serial in** node. This helps you inspect the raw payload and confirm that data is being received correctly.
3. Once you confirm the format of the incoming data, use any of the **change**, **JSON**, or **function** node to parse and convert it into a structured format, here we have used function.

In our case, the machine sends production data every 2 seconds in the following format:

![Screenshot of Node-RED debug panel showing production data sent from the machine every 2 seconds](https://flowfuse.com/blog/2025/07/images/debug-panel-output.png){dataZoomable=""}&#x2A;Screenshot of Node-RED debug panel showing production data sent from the machine every 2 seconds.*

To convert this string into a structured JSON object, you can use a **function** node with the following code:

```javascript
let parts = msg.payload.trim().split(' ');
let result = {};

parts.forEach(part => {
    let [key, value] = part.split(':');
    result[key.trim()] = parseInt(value);
});

msg.payload = result;
return msg;
```

This transforms the string into a JSON object like:

```json
{
  "GOOD": 214,
  "DEFECT": 22
}
```

> **Tip**: You do not need to know JavaScript to use the **function** node.
> If you are using FlowFuse, the built-in [FlowFuse Assistant](https://www.google.com/search?q=/docs/user/expert/){rel="&#x22;nofollow&#x22;"} can help you write function code using natural language. Simply provide a sample of the data received from your machine and describe the output you expect, the Assistant will generate the function for you.

### Handling Request-Response Serial Communication

Not all machines stream data continuously. Some expect a request command, and only then respond with data. In these cases, using a combination of **inject**, **serial out**, and **serial in** nodes can become tricky, especially if you need to match each request with exactly one response. That's where the **serial request** node becomes useful.

The **serial request** node handles this entire pattern for you. Internally, it combines the logic of sending a message and waiting for a single reply, working in a **first-in, first-out** manner. This means it will only send the next request after receiving a response (or timeout) for the previous one, making it ideal for synchronous devices.

To use it:

1. Drag a **serial request** node from the palette.
2. Double-click to configure the port, use the same path and settings as your other serial nodes.
3. Connect it to an **inject** node configured with the command your machine expects, such as `"READ"` or `"STATUS"`.
4. On the output side, connect a **debug** or **function** node to handle the response.

Each time you trigger the inject, the command will be sent over the serial port, and the response will be delivered to the output, ready to be parsed just like before. This approach is clean, predictable, and removes the guesswork from matching writes with reads.

The output message includes `msg.payload` containing the response (if any), `msg.status` with the result status, and `msg.port` for reference.

This node is especially useful for polling machines that respond with production counts, part IDs, temperature readings, or system status, but only when asked.

### Dynamically Managing Serial Ports

In a perfect setup, the serial device is connected, the port is stable, and everything just works. But in practice, hardware is not always so predictable.

For example, You might disconnect and reconnect a USB-to-serial adapter, and now the device shows up as `/dev/ttyUSB1` instead of `/dev/ttyUSB0`. Or maybe you need to temporarily release the serial port to flash new firmware onto an Arduino. In some environments, the port assignment could change on every reboot, making it difficult to hardcode anything.

Rather than redeploying or editing your flow every time, Node-RED gives you a more flexible option: the **serial control** node.

This node lets your flow adjust serial communication settings on the fly. You can:

- Stop the serial connection when needed.
- Start it again later.
- Even switch to a different port entirely, without touching the Node-RED editor.

All of this happens by sending a simple message to the control node.

To stop communication:

```json
{ "enabled": false }
```

To start it again:

```json
{ "enabled": true }
```

And if the port changes or needs reconfiguration, you can send everything in one message:

```json
{
  "serialport": "/dev/ttyUSB1",
  "serialbaud": 9600,
  "databits": 8,
  "parity": "none",
  "stopbits": 1,
  "enabled": true
}
```

This is especially useful when your flow needs to recover automatically, for example, after a USB reconnection, or if you want to let a user select the correct port from a dashboard interface.

Each time a message is received, the node also outputs the current port configuration. This allows you to log or verify changes as part of your flow, making it easy to track what the system is doing behind the scenes.

In short, the **serial control** node adds a layer of resilience and flexibility that is often essential in real-world deployments, where devices come and go, ports are never quite consistent, and downtime is not an option.

## Key Takeaways

Manufacturing floors often bring together a mix of old and new machines. Among them, many still operate on traditional communication methods that are reliable but difficult to integrate with modern systems. These machines continue to perform their core functions well, but without connectivity, they remain isolated from digital workflows.

With FlowFuse and Node-RED, you can bridge that gap, bringing equipment online without changing or replacing existing hardware. From data collection to triggering actions and monitoring performance, your machines can become part of a connected and intelligent system.

Whether you're in textiles, precision engineering, or [automotive manufacturing](https://flowfuse.com/industries/automotive/), FlowFuse helps you unlock the full potential of your existing equipment. No rip-and-replace needed, just smarter connections. [Get in touch with us](https://flowfuse.com/contact-us/) and start building your serial integration flow today.


# FlowFuse Expert: Let Your Engineers Build Automation, Not Write Code

Every manufacturing engineer knows this scenario: Node-RED's visual programming handles most of your automation needs brilliantly. Connect to PLCs, route data, trigger actions, all with drag-and-drop simplicity, but then you hit the wall. Your machine outputs data in a proprietary format. You need a custom dashboard widget that doesn't exist. You're manually creating test data for hours, or you're trying to understand a complex flow built by someone who left last year.

These bespoke tasks can often demand coding skills, JavaScript for parsing data, Vue.js for custom widgets, CSS for styling. Skills your automation engineers might not have. Skills that pull them away from what the engineers do best: optimizing production.

FlowFuse Expert changes this dynamic completely. Describe what you need in plain English, then, get working code instantly. No more hours lost to syntax errors or Stack Overflow searches. Your engineers can focus on their own expertise, and FlowFuse Expert fills in the gaps. Let's look at how manufacturing teams can use it to solve real problems.

## Parsing Machine Data Without the JavaScript Struggle

While Node-RED's low-code nodes cover most scenarios, every production line has unique quirks. Complex data parsing, multi-step calculations, proprietary protocols, these can all be accomplished in Node-RED by writing your own JavaScript. Engineers, who should be focussed on optimizing processes, end up out of their comfort zone, searching regex patterns and debugging syntax errors.

Consider this output from a CNC machine that's been reliable for 15 years:

```text
-- CYCLE END REPORT --
ID: M-45B / PART: XF-201
TIMESTAMP: 2025-07-09T14:22:01Z
SERIAL: 2025-0001547
OPERATOR: JONES, M
STATS ---
PART_COUNT: 481
CYCLE_TIME: 114.72
MAX_TEMP: 85.3
TOOL_WEAR_IDX: 0.73
COOLANT_LEVEL: OK
ALERTS: NONE
-- END --
```

The traditional approach means spending 30-50 minutes writing regex patterns, handling edge cases, and testing thoroughly. Your engineer needs to remember JavaScript string methods, debug regex syntax, and account for variations in the output format.

With FlowFuse Expert, the process changes completely. Your engineer opens a function node, clicks the FlowFuse Expert button, and types:

> "Parse this CNC report format. Extract PART\_COUNT as integer, CYCLE\_TIME as float, TOOL\_WEAR\_IDX as float, OPERATOR name, and ALERTS. Return as JSON."

The engineer reviews the code, tests it with their data, and moves on to solving actual manufacturing problems instead of wrestling with JavaScript syntax.

:video{ariaLabel="FlowFuse Expert generating a Node-RED function node to extract data from a CNC text report." autoPlay="true" height="720" loop="true" muted="true" playsInline="true" preload="none" width="1258"}&#x2A;FlowFuse Expert generating a Node-RED function node to extract data from a CNC text report.*

## Creating Test Data in Seconds, Not Hours

Before connecting to live equipment, you need test data that looks real. Making it by hand is tedious and wastes lots of time.

With FlowFuse Expert, just ask:

> "Generate 20 machine records with machine\_id, production\_count, efficiency\_percentage, downtime\_minutes, and last\_maintenance\_date. Show realistic variations."

It's as simple as that.

:video{ariaLabel="FlowFuse Expert generating test JSON data with multiple machine records including production counts and efficiency metrics" autoPlay="true" height="720" loop="true" muted="true" playsInline="true" preload="none" width="1356"}&#x2A;FlowFuse Expert creating realistic test data for manufacturing dashboards, complete with machine IDs, production metrics, and maintenance dates.*

## Building Custom Dashboards Without Web Development

[FlowFuse Dashboard](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"} widgets cover most UI needs, but manufacturing can often demand more. Custom visualizations for specific KPIs can be build in Dashboard with the ["Template"](https://dashboard.flowfuse.com/nodes/widgets/ui-template){rel="&#x22;nofollow&#x22;"} node, where developers can write their own Vue.js templates.

Developing custom components to match your HMI design standards takes CSS expertise. Whether you're building new widgets or styling existing ones, you're suddenly in web development territory, far from where most automation engineers want to be.

Take a [Pareto Chart](https://en.wikipedia.org/wiki/Pareto_chart){rel="&#x22;nofollow&#x22;"} for defect analysis as an example, essential for quality teams but not available as a standard Dashboard widget. Building it requires Vue.js knowledge, Chart.js integration, and responsive design skills.

With FlowFuse Expert, just describe what you need:

> "Create a Pareto chart widget showing defect counts as bars with a cumulative percentage line. Include the 80% threshold."

:video{ariaLabel="FlowFuse Expert creating custom dashboard components and styling for manufacturing displays" autoPlay="true" height="720" loop="true" muted="true" playsInline="true" preload="none" width="1364"}&#x2A;FlowFuse Expert building both custom widgets and styling existing components for manufacturing dashboards.*

Or consider input boxes for operator data entry that look too modern. Your team prefers the familiar green LCD screens they've used for decades, you can ask FlowFuse Expert:

> "Add CSS that makes the input with classes 'calculator' and 'text-input' look like an old green LCD calculator screen."

:video{ariaLabel="FlowFuse Expert generating CSS to style input fields with green LCD calculator display appearance" autoPlay="true" height="720" loop="true" muted="true" playsInline="true" preload="none" width="1364"}&#x2A;FlowFuse Expert creating CSS that transforms standard input boxes into retro LCD displays with glowing green text.*

Whether creating new widgets or styling existing ones, FlowFuse Expert handles the Vue.js and CSS complexity. You describe the outcome, it generates the code.

## Documenting Complex Flows Before Knowledge Walks Out

Production flows evolve over years into complex systems. Hundreds of nodes, critical logic buried in functions, intricate routing between tabs. When knowledge walks out the door, new team members can face weeks of detective work trying to understand flows and their colleague's work.

FlowFuse Expert's Flow Explainer solves this. Select any flow or group of nodes, click "Explain," and get instant documentation. It analyzes connections, reads function code, and generates clear explanations of what everything does and why.

:video{ariaLabel="FlowFuse Expert explaining the purpose and behavior of a complex Node-RED flow in plain language." autoPlay="true" height="720" loop="true" muted="true" playsInline="true" preload="none" width="1364"}&#x2A;FlowFuse Expert turning complex flows into clear documentation for easy knowledge transfer.*

## Start Building Today

FlowFuse Expert is just one way FlowFuse helps manufacturing teams work faster.

Teams collaborate on flows in real-time. Version control with snapshots means you can always go back if something breaks. Remote device management handles edge devices across your factory floor. Deploy to one machine or a thousand with a single click. Built-in DevOps pipelines streamline your workflow from development to production.

For production reliability, high availability keeps systems running 24/7. The integrated MQTT broker handles all your device messaging. Enterprise security includes SSO, multi-factor authentication, role-based access control, and complete audit logs.

FlowFuse gives you everything you need to build, deploy, and manage Node-RED at scale.

[Try FlowFuse free →](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}


# FlowFuse 2.19: More Powerful AI in Node-RED, Drop-In Blueprints, Memory Monitoring, and Faster Onboarding

This release focuses on speeding time to value with more powerful AI functionality within Node-RED, along with reducing friction for new users while enhancing the experience for existing users through improved Blueprint functionality, comprehensive performance monitoring, and a modernized interface that reflects FlowFuse's evolution.

## AI Enhancements to Node-RED

:video{ariaLabel="Video of AI Flow Explainer" autoPlay="true" height="790" loop="true" muted="true" playsInline="true" preload="none" width="1089"}*Video of AI Flow Explainer*

The FlowFuse Expert can now do more than create a Function node based on your text instructions. With this release, you can highlight a flow in the Node-RED editor and ask the FlowFuse Expert to explain the purpose of the flow. This new functionality is perfect for learning and collaboration.

You can also use the FlowFuse Expert to create Dashboard templates with HTML, VUE, Vuetify, and CSS, allowing you to build even faster.

Stay tuned for more developments as we continue to add enhancements to the Node-RED editor in FlowFuse to enable even faster development.

## Comprehensive Performance Monitoring

![Screenshot of Memory in Performance Feature](https://flowfuse.com/blog/2025/07/images/Memory.png)*Screenshot of Memory Monitoring*
Building on our existing CPU monitoring capabilities, we've added memory usage tracking to the Performance feature. This enhancement provides:

- Complete visibility into both CPU and memory utilization
- Better understanding of instance resource consumption
- More informed decision-making for scaling and optimization

With these features, you can now get a holistic view of your instance performance and make informed decisions about resource allocation.

## Add Blueprints to Existing Instances

![Screenshot of Blueprint Import](https://flowfuse.com/blog/2025/07/images/blueprint-import.png)*Screenshot of Blueprint Import*

Previously, Blueprints could only be used when creating new instances. Now you can import Blueprints into existing instances, making them much more versatile. Blueprints now appear as an option in the Import menu.

And if you're running Node-RED version 4.1, when you select a Blueprint to import that uses nodes not in your current palette, it will offer to install them automatically.

This change transforms Blueprints from a one-time instance creation tool into a constantly useful resource to speed your development with Node-RED.

## Social Sign-in for Easy Onboarding

![Screenshot of Google Signin](https://flowfuse.com/blog/2025/07/images/social-sign-on.png)*Screenshot of Google Signin*

To make it easier than ever to create a FlowFuse account, we've introduced social sign-in options that allow users to create FlowFuse Cloud accounts using their Google credentials.

This enhancement removes multiple steps from the onboarding process, making it significantly easier for new users to get started with FlowFuse.

## Enhanced Device Agent Flow Selection

Connecting your existing Node-RED instances running on remote devices is now even easier with the new Device Agent terminal file browser. When installing the Device Agent, you can now easily navigate your file system and select existing Node-RED instances through an interactive interface directly in the terminal.

This improvement replaces the previous manual file path entry process with:

- An intuitive file browser that works directly in your terminal
- Easy navigation through your file system to locate flows
- Contextual information about flows including file size and modification dates
- A streamlined selection process that reduces setup friction

## Modernized User Interface

![Screenshot of New Homepage](https://flowfuse.com/blog/2025/07/images/homepage.png)*Screenshot of Homepage*

The FlowFuse user interface was due for a restructuring in light of what users are looking for, along with a visual touchup. This release introduces a dedicated landing page that focuses on what we've learned users want to do when they first access FlowFuse. The new homepage provides:

- Direct access to relevant hosted and remote instances
- Smart prioritization based on recent activity and deployments
- Prominent display of issues requiring attention (performance alerts, errors)
- Recent team activity overview through audit log integration
- Improved layout and visual hierarchy
- Updated color scheme and styling

These changes make it easier to find what you are looking for within FlowFuse, address issues that may arise, and creates a more pleasant workspace.

## What's Next?

Our development team continues to focus on AI integration and workflow optimization. The upcoming releases will build on these foundational improvements while introducing more intelligent automation and development assistance features.

We're also working on expanding our Blueprint library and improving the overall development experience within the Node-RED editor, with several exciting features planned for the coming months.

## What else is new?

For a complete list of everything included in our 2.19 release, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/){rel="&#x22;nofollow&#x22;"}.

Your feedback continues to be invaluable in shaping FlowFuse's development. We'd love to hear your thoughts on these new features and any suggestions for future improvements. Please share your experiences or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Which of these new features are you most excited to try? Email me directly at <greg@flowfuse.com> - I'd love to hear from you!

## Try FlowFuse

### FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in the cloud within minutes.

### Self-Hosted

Get FlowFuse running locally in under 30 minutes using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# FlowFuse 2.20: AI-Assisted Node-RED & New Database Service

This release represents a major leap forward in FlowFuse's data management and AI capabilities, introducing our new FlowFuse Tables database feature, along with enhanced AI assistance features and a streamlined user interface. These improvements make FlowFuse a complete solution for building industrial applications, even while reducing development time.

:product-update-note

## Introducing: FlowFuse Tables

![A screenshot of the new "Tables" view, now available in FlowFuse](https://flowfuse.com/blog/2025/07/images/tables-ui-screenshot.png){dataZoomable=""}*A screenshot of the new "Tables" view, now available in FlowFuse*

FlowFuse Tables is our brand new database offering that provides a simple way to store your data, all within the FlowFuse ecosystem. This comprehensive database offering comes with FlowFuse's enterprise-grade security and unlocks the ability to seamlessly build critical systems like MES and ERP.

FlowFuse Tables eliminates the complexity of setting up and managing separate database infrastructure, allowing you to focus on building applications that drive operational efficiency.

FlowFuse Tables is available now for all Enterprise users running on FlowFuse Cloud.

### New Node: Query

![A flow in Node-RED that uses the new FlowFuse "Query" node](https://flowfuse.com/blog/2025/07/images/tables-query-node.png){dataZoomable=""}*A flow in Node-RED that uses the new FlowFuse "Query" node*

Alongside the new Tables offering, we have shipped a new node that you can find in your Node-RED Editor - "Query". This will automatically connect to any associated database you have with your team, saving you time in manually configuring nodes and credentials, giving you more time to just focus on the fun of building your flows, and making it really easy to start storing and querying your data.

## AI-Assisted Node-RED with Smart Suggestions

:video{ariaLabel="Video of Smart Suggestions" autoPlay="true" height="702" loop="true" muted="true" playsInline="true" preload="none" width="1139"}*Video of Smart Suggestions in Action*

Development in Node-RED is now even faster with Smart Suggestions, an agent that runs in-browser and offers intelligent flow completion for next-node recommendations. With Smart Suggestions, as you place a node, the agent will automatically calculate the most likely next node to place, and will offer suggestions for the node's configuration. It present up to 5 options, so even if the first suggestion isn't correct, it's very likely that the correct choice is only a quick keyboard shortcut away.

This work extends the functionality of the in-built FlowFuse Expert and it's MCP server that runs behind the Node-RED Editor to provide power additional development enhancements.

## New Blueprint: Agentic AI with Retrieval Augmented Generation

:video{controls="true" src="https://website-data.s3.eu-west-1.amazonaws.com/Blueprint+-+Open+AI+RAG.mp4"}

The new RAG (Retrieval Augmented Generation) Blueprint enables you to train your own LLM agents, combining your own data with natural language capabilities.

This Blueprint provides two flows: one that adds text into Node-RED's flow context store and uses it to train an OpenAI agent, so you can query the content of the flow directly; and one flow that scrapes websites to train an OpenAI agent so that content can be queried and used as well.

The RAG Blueprint makes it easy to create intelligent agents that leverage your organizational knowledge without requiring deep AI expertise. [Try it out for yourself here.](https://flowfuse.com/blueprints/ai/rag-chat-agent/)

## Refined Applications Page

![Screenshot of New Applications Page](https://flowfuse.com/blog/2025/07/images/applications-redesign.png){dataZoomable=""}*Screenshot of Redesigned Applications Page*

With the new FlowFuse Home page in place, we have greatly streamlined the Applications page. The new structure includes:

- **Streamlined Navigation**: Applications now appear under Instances in the navigation hierarchy
- **Reduced Cognitive Load**: Eliminated the overwhelming number of buttons and links in the previous design
- **Focus on Important Information**: The newly refined design focusses on giving you a clear overview of the status of your Hosted and Remote Instances, split by Application.
- **Performance Optimizations**: The above has also lead to faster page loading and improved responsiveness

This redesign creates a more intuitive workflow that aligns with how teams actually use FlowFuse, reducing clicks and improving productivity.

## More Powerful "Small" Instances

Based on user feedback and our own review of instance performance, we have increased the CPU and memory of all "small" Node-RED instances running on FlowFuse. This will have the immediate benefit of preventing slowdowns and loading issues for all Starter and Team customers.

## What's Next?

Our development roadmap continues to focus on AI integration and enterprise data management. Upcoming releases will expand FlowFuse Tables with additional database types and analytics capabilities, while our FlowFuse Expert will gain more sophisticated workflow automation features.

We're also working on enhanced Blueprint offerings and deeper integration between our AI capabilities and industrial data sources, with several exciting announcements planned for the coming months!

## What else is new?

For a complete list of everything included in our 2.20 release, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.20.0){rel="&#x22;nofollow&#x22;"}.

Your feedback continues to be invaluable in shaping FlowFuse's development. We'd love to hear your thoughts on these new features and any suggestions for future improvements. Please share your experiences or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Which of these new features are you most excited to try? Email me directly at <greg@flowfuse.com> - I'd love to hear from you!

## Try FlowFuse

### FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in the cloud within minutes.

### Self-Hosted

Get FlowFuse running locally in under 30 minutes using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# Statistical Process Control (SPC): Benefits and Implementation Guide

Leading manufacturers are quietly saving thousands, sometimes millions, of dollars annually with a quality control method that's been proven since the 1920s. The difference today? Modern tools make it simple to implement.

Consider this real example: A manufacturer shared on Practical Machinist forum that they process 400,000 parts per year with a 4% scrap rate. That's 16,000 parts discarded annually. At even a conservative [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[10]{.mord}[p]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[p]{.mord.mathnormal}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[t]{.mord.mathnormal}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[t]{.mord.mathnormal}[hi]{.mord.mathnormal}[sr]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[p]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[ese]{.mord.mathnormal}[n]{.mord.mathnormal}[t]{.mord.mathnormal}[s]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 160,000 in direct losses from a single production line. They accepted this as normal because industry reports confirm 4-5% scrap rates are standard.

What separates industry leaders from the rest? They refuse to accept "normal" waste. Using Statistical Process Control (SPC), they detect problems as they occur, not after producing defective parts. When a process begins drifting, they receive immediate alerts and correct it before generating scrap.

This guide shows you exactly how to build a real-time SPC system using FlowFuse. You'll create a live dashboard that tracks measurements and alerts operators the moment something goes wrong. No statistics degree needed, just practical steps you can implement today.

## Why Traditional Quality Control Falls Short

Most manufacturers still rely on end-of-line inspection. Make parts, check parts, scrap the bad ones. This reactive approach creates three expensive problems:

**Problem 1: You're always too late**
When inspection finds a defect, you've already invested in material, machine time, labor, and energy. That investment is now scrap. Worse, how many parts did you make between when the problem started and when you caught it?

**Problem 2: The borderline parts you miss**
Not all defects are obvious. Parts that barely pass inspection today might fail in the field tomorrow. These marginal parts slip through because traditional inspection only catches clear failures, not process degradation.

**Problem 3: No insight into root causes**
Finding bad parts tells you nothing about why they're bad. Was it temperature drift? Tool wear? Material variation? Without process data, you're guessing at solutions.

**The Proactive Alternative: Statistical Process Control**

SPC flips the entire approach. Instead of checking parts after production, it monitors your process during production. The NIST Engineering Statistics Handbook explains it simply:

> "The underlying concept of statistical process control is based on a comparison of what is happening today with what happened previously."

When your process starts to drift from its normal behavior, SPC alerts you immediately. You fix the issue before making defective parts, not after.

Walter Shewhart developed this method at Bell Labs in the 1920s, proving its effectiveness across industries. Today, FlowFuse makes it accessible to any manufacturer, regardless of size or technical expertise.

## Building Your First SPC System with FlowFuse

Let's build a real example. This guide shows you how to create a SPC control chart for individual measurements - perfect for monitoring critical dimensions in real-time.

First, open your FlowFuse Node-RED instance. If you don't have one yet, you can [sign up for a free account](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have an instance running in minutes.

### What We're Building

A real-time SPC control chart that monitors individual measurements and automatically calculates control limits. Perfect for scenarios where you measure one part at a time - like bearing dimensions on a CNC line. When measurements drift outside the calculated limits, you'll know instantly.

### Step 1: Get Your Tools Ready

First, we need two nodes for SPC monitoring.

1. Open FlowFuse's palette manager (hamburger menu → Manage palette)
2. Go to the Install tab
3. Search for and install these nodes:
   - `node-red-contrib-simple-spc` - This is your statistics engine
   - `@flowfuse/node-red-dashboard` - For that slick real-time chart
4. Click Install for each node and wait for completion

### Step 2: Simulate Your Machine Data

In production, you'd connect to your PLC. For now, let's simulate a bearing measurement around 10mm nominal.

1. Drag an **inject** node onto your canvas. This is your "sensor."
2. Double-click it and set:
   - Repeat: `interval` → `2 seconds` (mimics real sensor timing)
   - Payload: switch to JSONata mode and enter: `$random() * 0.2 + 10`

This generates readings like 10.05, 9.98, 10.11 - realistic variation around 10mm.

### Step 3: Add the Statistical Brain

Find the **spc** node in your palette (it'll be under "function" category after install).

1. Drag it over and wire your inject node to it.
2. Double-click to configure:
   - Control Limit Multiplier: `3` (for 3-sigma limits)
   - Timer: `10` (seconds before alerting out-of-control)

Once configured, the node outputs an object like this:

```javascript
{
    value: 10.020214950604476,      // Current measurement
    avg: 10.089877376434453,         // Running average
    ucl: 10.344067494423967,         // Upper control limit
    lcl: 9.835687258444938,          // Lower control limit
    outOfControl: false              // Alert status
}
```

### Step 4: Make the Data Chart-Ready

Charts need data in a specific format. Add a **change** node between SPC and your chart.

1. Drag a **change** node onto the canvas
2. Wire it between the SPC node and where your chart will go
3. Double-click to configure and set one rule: `Set msg.payload` to this JSONata expression:

```json
[
    {"series": "Measurement", "x": $millis(), "y": payload.value},
    {"series": "UCL", "x": $millis(), "y": payload.ucl},
    {"series": "LCL", "x": $millis(), "y": payload.lcl},
    {"series": "Average", "x": $millis(), "y": payload.avg}
]
```

This creates four lines on your chart, your actual measurements plus the three control lines.

### Step 5: Build Your Control Room Dashboard

Now we'll create the dashboard that displays your SPC control chart. This is what operators will watch to spot problems in real-time.

1. Drag a **chart** widget from the dashboard section and set:
   - Type: `Line Chart`
   - X-axis: `HH:mm:ss` (shows time)
   - Series: Set to `series` (as key)
   - X: Set to `x` (as key)
   - Y: Set to `y` (as key)
   - Legend: `Show`
   - Label: "SPC Chart: Bearing Diameter (mm)"
2. Connect the change node to it.
3. Deploy the flow.

![Node-RED flow showing SPC monitoring setup with inject node, SPC calculations, data formatting, and dashboard chart configuration](https://flowfuse.com/blog/2025/07/images/spc.png){dataZoomable=""}*Complete SPC monitoring flow with real-time chart display*

### Step 6: Add the Alert System

A chart is nice, but you need immediate alerts. Here's the clever bit:

1. Add a **switch** node connected to your SPC output
2. Set it to check `msg.payload.outOfControl`
3. Create two outputs: true and false
4. Now add a **text** nodes from dashboard. Wire it to your switch outputs.

For the "true" path, set the text to something attention-grabbing using change node:
`⚠️ PROCESS OUT OF CONTROL - CHECK MACHINE!`

For the "false" path:
`✓ Process Stable`

5. Deploy the flow.

![Node-RED alert system with switch node: Process stable](https://flowfuse.com/blog/2025/07/images/spc-visual-alert.png){dataZoomable=""}*Node-RED alert system with switch node: Process stable*

### Step 7: Test Your SPC System

Open your dashboard (switch to the Dashboard 2.0 tab → click Open Dashboard button on the top-right of the right sidebar).

**What you'll see initially:**

- First 20 measurements: Chart builds up baseline data
- After 20 points: Control limits appear automatically
- Blue line bouncing between red lines: Process is stable

Let the system run for a minute to establish your baseline. The control limits aren't arbitrary - they're calculated from your actual process data.

**Now test it with a simulated process shift:**

1. Double-click the Inject node
2. Change the formula to `$random() * 0.2 + 10.5` (this shifts the mean up by 0.5mm)
3. Click Done to close the node
4. Deploy only the modified nodes:
   - Click the down arrow next to the **Deploy** button
   - Select **Modified Nodes**
   - Click the **Deploy** button

![Node-RED deploy menu showing Modified Nodes option for selective deployment](https://flowfuse.com/blog/2025/07/images/modifed-nodes-deploy.png){dataZoomable=""}*Deploy menu with Modified Nodes option for updating only changed nodes*

Once done You will see the chart detect the change within seconds.

![SPC chart showing process shift with measurements exceeding upper control limit and alert triggered](https://flowfuse.com/blog/2025/07/images/spc-visual-alert2.png){dataZoomable=""}*SPC chart detecting process shift - measurements above UCL trigger immediate alert*

::render-flow{:height='300'}
```json
[{"id":"124f531365b82e1c","type":"group","z":"071524a8fd482116","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["4082f89605793666","2ec8351f01f957a4","c90d67c57d1af3bd","53ef849a41aee2b3","d78ff3dbe97a5be9","98e76616c28ed9ca","5fd3415ef4c36b6e","9763632606c2a165"],"x":214,"y":159,"w":872,"h":162},{"id":"4082f89605793666","type":"inject","z":"071524a8fd482116","g":"124f531365b82e1c","name":"","props":[{"p":"payload"}],"repeat":"2","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"$random() * 0.2 + 10.5","payloadType":"jsonata","x":310,"y":240,"wires":[["2ec8351f01f957a4"]]},{"id":"2ec8351f01f957a4","type":"spc","z":"071524a8fd482116","g":"124f531365b82e1c","name":"","limitMultiplier":"3","timer":"10","x":430,"y":240,"wires":[["c90d67c57d1af3bd","d78ff3dbe97a5be9"]]},{"id":"c90d67c57d1af3bd","type":"change","z":"071524a8fd482116","g":"124f531365b82e1c","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"[     {\"series\": \"Measurement\", \"x\": $millis(), \"y\": payload.value},     {\"series\": \"UCL\", \"x\": $millis(), \"y\": payload.ucl},     {\"series\": \"LCL\", \"x\": $millis(), \"y\": payload.lcl},     {\"series\": \"Average\", \"x\": $millis(), \"y\": payload.avg} ]","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":600,"y":200,"wires":[["53ef849a41aee2b3"]]},{"id":"53ef849a41aee2b3","type":"ui-chart","z":"071524a8fd482116","g":"124f531365b82e1c","group":"3af21cf2cea638c8","name":"","label":"I-MR Chart: Bearing Diameter (mm)","order":1,"chartType":"line","category":"series","categoryType":"property","xAxisLabel":"","xAxisProperty":"x","xAxisPropertyType":"property","xAxisType":"time","xAxisFormat":"","xAxisFormatType":"auto","xmin":"","xmax":"","yAxisLabel":"","yAxisProperty":"y","yAxisPropertyType":"property","ymin":"","ymax":"","bins":10,"action":"append","stackSeries":false,"pointShape":"circle","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"3600","removeOlderPoints":"","colors":["#0095ff","#ff0000","#ff7f0e","#2ca02c","#a347e1","#d62728","#ff9896","#9467bd","#c5b0d5"],"textColor":["#666666"],"textColorDefault":true,"gridColor":["#e5e5e5"],"gridColorDefault":true,"width":"12","height":"7","className":"","interpolation":"linear","x":840,"y":200,"wires":[[]]},{"id":"d78ff3dbe97a5be9","type":"switch","z":"071524a8fd482116","g":"124f531365b82e1c","name":"","property":"payload.outOfControl","propertyType":"msg","rules":[{"t":"true"},{"t":"false"}],"checkall":"true","repair":false,"outputs":2,"x":570,"y":260,"wires":[["98e76616c28ed9ca"],["5fd3415ef4c36b6e"]]},{"id":"98e76616c28ed9ca","type":"change","z":"071524a8fd482116","g":"124f531365b82e1c","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"⚠️ PROCESS OUT OF CONTROL - CHECK MACHINE!","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":780,"y":240,"wires":[["9763632606c2a165"]]},{"id":"5fd3415ef4c36b6e","type":"change","z":"071524a8fd482116","g":"124f531365b82e1c","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"✓ Process Stable","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":780,"y":280,"wires":[["9763632606c2a165"]]},{"id":"9763632606c2a165","type":"ui-text","z":"071524a8fd482116","g":"124f531365b82e1c","group":"3af21cf2cea638c8","order":2,"width":0,"height":0,"name":"Visual Alert","label":"","format":"{{msg.payload}}","layout":"col-center","style":true,"font":"Arial,Arial,Helvetica,sans-serif","fontSize":"24","color":"#717171","wrapText":false,"className":"","x":990,"y":260,"wires":[]},{"id":"3af21cf2cea638c8","type":"ui-group","name":"Group 1","page":"735102f229f1a45b","width":"12","height":"7","order":1,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"735102f229f1a45b","type":"ui-page","name":"SPC","ui":"3c2e7c6f438349e4","path":"/page1","icon":"home","layout":"grid","theme":"daff84b6f7fe1f97","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"3c2e7c6f438349e4","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":true},{"id":"daff84b6f7fe1f97","type":"ui-theme","name":"Default Theme","colors":{"surface":"#ffffff","primary":"#0094CE","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
```
::

## SPC Chart Rules That Actually Matter

Control limits catch obvious problems. But subtle issues need pattern recognition. Here are the four rules that catch 95% of real problems:

- **Rule 1: Any point outside limits**
  This one is fairly obvious: If a measurement point falls outside of the established upper or lower limits, something is wrong.
- **Rule 2: Seven points on one side**
  Seven consecutive points above or below the center line means your process has shifted. Maybe a new material lot, maybe tool wear.
- **Rule 3: Seven points trending**
  Seven points in a row going up or down. Classic sign of tool wear or temperature drift.
- **Rule 4: Repeating and Cyclical Patterns**
  This rule is for recurring behaviors that the other rules miss. Cycles that repeat over time, like a regular pattern that appears at the start of every shift change or every Monday. Speak with your operators, they will likely know what these mean.

Here's how to implement these rules in FlowFuse:

1. Drag a **Function** node onto the workspace and add the following JavaScript code to it.
2. Replace switch node with this **Function** node.
3. Deploy the flow.

```javascript
const buffer = context.get('measurements') || [];
const current = msg.payload;

// Rule 1: Out-of-control point (handled by SPC node)
if (msg.payload.outOfControl) {
    msg.payload = "⚠️ PROCESS OUT OF CONTROL – CHECK MACHINE!";
    return msg;
}

// Store the current measurement
buffer.push({
    value: current.value,
    avg: current.avg,
    timestamp: new Date()
});

// Keep only the last 20 measurements
if (buffer.length > 20) {
    buffer.shift();
}
context.set('measurements', buffer);

// Initialize alert message
let alertMessage = "✓ Process Stable";

// Check rules if we have enough data
if (buffer.length >= 7) {
    const recent = buffer.slice(-7);
    const values = recent.map(r => r.value);

    // Rule 2: Seven points on one side of the center line
    const allAbove = values.every(v => v > current.avg);
    const allBelow = values.every(v => v < current.avg);
    if (allAbove || allBelow) {
        alertMessage = "⚠️ Process shift detected – 7 points on one side of center";
    }

    // Rule 3: Seven points trending up or down
    let trending = true;
    const increasing = values[1] > values[0];
    for (let i = 2; i < values.length; i++) {
        if ((increasing && values[i] <= values[i - 1]) ||
            (!increasing && values[i] >= values[i - 1])) {
            trending = false;
            break;
        }
    }
    if (trending) {
        alertMessage = increasing
            ? "⚠️ Increasing trend – check for tool wear"
            : "⚠️ Decreasing trend – check material quality";
    }
}

msg.payload = alertMessage;
return msg;
```

The following image demonstrates the advanced alerting system in action, detecting specific patterns beyond simple control limit violations:

:video{ariaLabel="SPC system detecting process drift in real-time, showing chart responding to simulated measurement changes and triggering alerts" autoPlay="true" height="227" loop="true" muted="true" playsInline="true" preload="none" width="400"}*Real-time SPC monitoring detecting process drift and triggering appropriate alerts based on trend analysis*

## Connecting to Real Equipment

Time to connect your actual machines. The approach depends on what equipment you have.

For modern PLCs - anything from the last decade like Siemens S7-1200/1500, Allen-Bradley ControlLogix, or Omron NX - you'll use OPC UA. It's already built into these PLCs. Enable it in the configuration, install `node-red-contrib-opcua` from the FlowFuse palette, and point it at your PLC. The endpoint looks like `opc.tcp://192.168.1.100:4840`. Browse for your measurement tags and connect them to your SPC flow. [Full OPC UA guide here](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/).

Older equipment speaks Modbus TCP. Check your manual's appendix for the register map. Install `node-red-contrib-modbus`, configure it with your device's IP address and the register holding your measurement (like 40001 for holding registers). Almost every industrial device from the last 30 years supports this. [Modbus tutorial here](https://flowfuse.com/node-red/protocol/modbus/).

For everything else, get creative. Old gauges with RS-232 ports work fine with a USB adapter and the serial node - [see our serial port guide](https://flowfuse.com/blog/2025/07/connect-legacy-equipment-serial-flowfuse/). Machines that dump CSV files can be monitored with the watch node. Manual measurements need just a simple dashboard form, one input field, one submit button. Don't overcomplicate it.

Before connecting to SPC, always test with inject → protocol node → debug to make sure data flows. Once you see measurements in the debug panel, wire it to your SPC node and you're monitoring real processes.

## The Money You're Leaving on the Table

Remember that manufacturer from the forum processing 400,000 parts annually with a 4% scrap rate? That's 16,000 parts straight to the trash. At just [[]{.katex-mathml}[[[]{.strut style="height:0.9463em;vertical-align:-0.1944em;"}[10]{.mord}[p]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[p]{.mord.mathnormal}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[t]{.mord.mathnormal}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[t]{.mord.mathnormal}[ha]{.mord.mathnormal}[[t]{.mord.mathnormal}[[[[[[]{.pstrut style="height:2.7em;"}[[[′]{.mord.mtight}]{.mord.mtight}]{.sizing.reset-size6.size3.mtight}]{style="top:-3.063em;margin-right:0.05em;"}]{.vlist style="height:0.7519em;"}]{.vlist-r}]{.vlist-t}]{.msupsub}]{.mord}[s]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 160,000 in annual waste. Cut that rate to 2% with SPC and you save $80,000 yearly.

But here's what most people miss - the $10 part cost is just the beginning. Consider what every defective part also burned through:

- **Machine time**: Say 3 minutes at [[]{.katex-mathml}[[[]{.strut style="height:1em;vertical-align:-0.25em;"}[200/]{.mord}[h]{.mord.mathnormal}[o]{.mord.mathnormal}[u]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[]{.mspace style="margin-right:0.2778em;"}[=]{.mrel}[]{.mspace style="margin-right:0.2778em;"}]{.base}[[]{.strut style="height:0.6944em;"}[an]{.mord.mathnormal}[o]{.mord.mathnormal}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 10 gone
- **Labor**: About 15 minutes handling the defect at [[]{.katex-mathml}[[[]{.strut style="height:1em;vertical-align:-0.25em;"}[30/]{.mord}[h]{.mord.mathnormal}[o]{.mord.mathnormal}[u]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[]{.mspace style="margin-right:0.2778em;"}[=]{.mrel}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 7.50 more
- **Materials**: The raw stock you'll never get back

That " [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[10]{.mord}[p]{.mord.mathnormal}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[t]{.mord.mathnormal}["]{.mord}[a]{.mord.mathnormal}[c]{.mord.mathnormal}[t]{.mord.mathnormal}[u]{.mord.mathnormal}[a]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[y]{.mord.mathnormal style="margin-right:0.0359em;"}[cos]{.mord.mathnormal}[t]{.mord.mathnormal}[y]{.mord.mathnormal style="margin-right:0.0359em;"}[o]{.mord.mathnormal}[u]{.mord.mathnormal}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[u]{.mord.mathnormal}[n]{.mord.mathnormal}[d]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 27.50 to scrap. Those 16,000 defects? Try $440,000 in real losses.

SPC attacks all of this simultaneously. When your process stays in control, you're not just saving parts - you're saving machine capacity, labor hours, and materials. Plus stable processes need less inspection, letting you redeploy quality staff to improvement projects instead of firefighting.

**Quick ROI calculation**: Take your annual defect count, multiply by your true cost per defect (part + machine + labor), then multiply by 0.5 for a conservative estimate. That's your yearly savings potential with SPC. Most manufacturers see payback in under 3 months.

SPC works. It's not magic, it's not complicated, and it doesn't have to be expensive. It's just math applied to manufacturing data in real-time.

The tools exist. Node-RED gets you started, but FlowFuse keeps you running in production. With built-in high availability, your SPC charts stay live even if a server fails. Multiple engineers can work on the same flows without conflicts. Deploy updates to 50 production lines with one click. When downtime costs thousands per hour, you need a platform built for manufacturing.

## Start Preventing Defects Today

Every day without SPC is money left on the table. Those 16,000 scrapped parts per year? The warranty claims from undetected drift? All preventable.

Here's your path to production-ready SPC:

1. **[Start Free with FlowFuse](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}** - Get your instance running in minutes
2. **Follow this tutorial** - Build your first SPC chart today
3. **Connect one machine** - Start with your most critical measurement
4. **Expand gradually** - Add more parameters as you prove value

Don't wait for the perfect plan. Don't form another committee. Pick one measurement that matters and start monitoring it today. Need help getting started? [Book a demo](https://flowfuse.com/book-demo/) to discuss your specific requirements or [contact our team](https://flowfuse.com/contact-us/) for enterprise deployment guidance.

Because somewhere right now, one of your machines is drifting out of spec. The only question is whether you'll catch it in time.

**[Build Your First SPC Dashboard Now →](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}**

## References

1. [Six Sigma Online - Statistical Process Control](https://www.sixsigmaonline.org/six-sigma-statistical-process-control/){rel="&#x22;nofollow&#x22;"} - Background on manufacturers saving thousands with quality control methods
2. [Practical Machinist Forum - Scrap Rates Discussion](https://www.practicalmachinist.com/forum/threads/scrap-rates.234251/){rel="&#x22;nofollow&#x22;"} - Real manufacturer example: 400,000 parts/year with 4% scrap rate
3. [ServiceChannel - Industry Scrap Rate Report](https://servicechannel.com/reports/scrap-rate/){rel="&#x22;nofollow&#x22;"} - Industry data confirming 4-5% scrap rates are standard
4. [NIST Engineering Statistics Handbook - Statistical Process Control](https://www.itl.nist.gov/div898/handbook/pmc/section1/pmc12.htm){rel="&#x22;nofollow&#x22;"} - Official definition and explanation of SPC principles
5. [Walter Shewhart - Wikipedia](https://en.wikipedia.org/wiki/Walter_A._Shewhart){rel="&#x22;nofollow&#x22;"} - SPC creator at Bell Labs in the 1920s


# OPC UA Tutorial: Connect and Exchange Data with Industrial Equipment

If you’ve ever tried to connect industrial equipment from different vendors, you know how frustrating it can be, a mess of incompatible protocols, proprietary software, and confusing drivers. Your Siemens PLC speaks one language, your Allen-Bradley controller another, and that Modbus sensor? Yet another protocol entirely.

**OPC UA changes that.**

OPC UA (Open Platform Communications Unified Architecture) is the industry-standard protocol that eliminates this chaos. Also known as OPC Unified Architecture or IEC 62541, it provides a universal language for secure communication between PLCs, SCADA systems, HMIs, and enterprise applications ,regardless of the manufacturer.

This hands-on guide walks you through building your first **OPC UA integration** using **Node-RED** and **FlowFuse**:

- **Connect** to any OPC UA server, Kepware, MatrikonOPC, or built-in PLC servers
- **Browse** available tags and discover Node IDs from your equipment
- **Read** real-time values from PLCs, sensors, and industrial devices
- **Write** control signals and setpoints back to your systems

## Why OPC UA?

If you have worked with industrial equipment, you know the pain. Every PLC vendor uses a different protocol. Your Siemens S7-1500 requires TIA Portal and PROFINET drivers. The Allen-Bradley ControlLogix needs RSLinx and EtherNet/IP. A Modbus temperature sensor needs yet another tool. Before long, you are juggling a dozen different software packages, each with its own licensing, training, and maintenance overhead.

### Breaking the Cycle

OPC UA eliminates this fragmentation. Instead of relying on vendor-specific protocols, it provides a universal language for all your equipment. Here is why it is becoming the industry standard:

### Universal Connectivity

Connect to any modern PLC using a single protocol. Leading manufacturers like Siemens, Rockwell, Schneider, and ABB now embed OPC UA servers directly into their controllers. One client, all your equipment.

### Information, Not Just Data

Reading a temperature value from OPC UA does not just give you "42.5", it gives the full context: 42.5 °C, measured at 14:32:15.625 with "Good" quality, from "Tank\_01/Temperature", and includes alarm limits (10 °C / 80 °C). This context reduces guesswork and helps prevent costly mistakes.

### Security Built for Industry

While protocols like Modbus transmit everything in plain text, OPC UA uses enterprise-grade security. It supports X.509 certificates, 256-bit encryption, and robust user authentication to safeguard critical infrastructure from cyber threats.

### Future-Proof Investment

OPC UA is the foundation of Industry 4.0 initiatives around the world. It is not just another protocol, it is the one major vendors are standardizing on. Choosing OPC UA today ensures long-term compatibility and ROI.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

## Getting Started

Now that you understand why OPC UA is widely adopted, let’s explore how to implement it using FlowFuse Node-RED.

This next section walks you through exactly what you need to get started with a working setup, whether for prototyping or production.

### What You’ll Need

Before diving into the flow-building process, make sure you have the following:

- An OPC UA server (like Kepware, MatrikonOPC, or built into your PLC)
- A FlowFuse Node-RED instance running on your edge device.

For production OPC UA deployments, we recommend using FlowFuse. When connecting to industrial systems, you need more than just Node-RED, you need team collaboration so multiple engineers can work on flows safely, audit logs for compliance tracking, high availability to prevent downtime, and remote device management for edge deployments.

FlowFuse provides these enterprise features plus automatic backups, one-click rollbacks, environment variables for different sites, and DevOps pipelines for testing changes before they reach production.

[Get started →](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}

### Installing OPC UA Support in FlowFuse

To work with OPC UA in FlowFuse Node-RED, you will first need to install the required nodes.

#### Install the OPC UA Node Package

1. Open the **FlowFuse Node-RED editor**.
2. Click the menu in the top-right and choose **Manage palette**.
3. Navigate to the **Install** tab and search for `node-red-contrib-opcua`.
4. Click **Install**.

Once installed, you will find new nodes for OPC UA communication in your palette, including **Client**, **Item**, and **Browser** and other OPC UA nodes.

### Connecting to Your OPC UA Server

To begin accessing industrial data, create a client connection using the OPC UA Client node.

1. Drag an **OPC UA Client** node onto the canvas.
2. Double-click to configure it.
3. Click the &#x2A;*+** icon to create a new endpoint configuration.
4. Enter your OPC UA server address, for example: `opc.tcp://192.168.0.10:4840`
5. Set the security mode to **None** (you can add security later).

> **Security Note:*&#x2A; This tutorial uses &#x2A;*"None"*&#x2A; for the security setting to keep things simple.
> In production environments, always use appropriate security, typically &#x2A;*"Sign & Encrypt"** with certificates.

6. Click **Add**, then **Done**.

![OPC UA endpoint configuration](https://flowfuse.com/blog/2025/07/images/opcua-endpoint-config.png){dataZoomable=""}*OPC UA endpoint configuration*

With the connection now defined, you’re ready to explore what tags are available.

### Browsing Tags (Optional)

If you do not already know the Node IDs of the tags you want to access, use the OPC UA Browser node to explore the tag structure.

1. Drag an **Inject**, **OPC UA Browser**, and **Debug** node onto the canvas.
2. Connect the output of the Inject node to the input of the **Browser** node, then connect the Browser's output to the Debug node.
3. In the **Browser** node, set the topic to `ns=0;i=85` (the root *Objects* folder).
4. Configure the Inject node to send a timestamp.
5. Deploy the flow and click the Inject node.

Tag information will be printed to the debug sidebar. You can now identify the exact Node IDs to use in your reads or writes.

![OPC UA Browser node](https://flowfuse.com/blog/2025/07/images/opcua-browser.png){dataZoomable=""}*OPC UA Browser node*

::render-flow{:height='300'}
```json
[{"id":"c3a8303048e6588f","type":"OpcUa-Browser","z":"f66e9c91c269e7fb","endpoint":"c0f8c79fc00845c8","item":"","datatype":"","topic":"ns=0;i=85","items":[],"name":"","x":510,"y":300,"wires":[["3428199852f9fcdc"]]},{"id":"1549f797c58ba667","type":"inject","z":"f66e9c91c269e7fb","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":280,"y":300,"wires":[["c3a8303048e6588f"]]},{"id":"3428199852f9fcdc","type":"debug","z":"f66e9c91c269e7fb","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":740,"y":300,"wires":[]},{"id":"c0f8c79fc00845c8","type":"OpcUa-Endpoint","endpoint":"","secpol":"None","secmode":"None","none":true,"login":false,"usercert":false,"usercertificate":"","userprivatekey":""}]
```
::

### Reading Tag Values

Once you know the Node IDs, you can start reading data from your industrial equipment through the OPC UA server.

#### Reading a Single Tag

Here’s how to read a single value in real time:

1. Drag an **Inject** node onto the canvas (this will trigger the read operation).
2. Add an **OPC UA Item** node and configure:
   - **Node ID**: Enter the tag’s identifier (e.g., `ns=3;i=1003`)
   - **Data Type**: Select the appropriate type (e.g., `Boolean`)
   :br![OPC UA Item node configuration](https://flowfuse.com/blog/2025/07/images/opcua-item-node.png){dataZoomable=""}
3. Connect the output of the **Inject** node to the input of the **Item** node.
4. Add an **OPC UA Client** node and set its **Action** to `read`. :br![OPC UA Client node configured for reading](https://flowfuse.com/blog/2025/07/images/opcua-client-read-node.png){dataZoomable=""}
5. Select the endpoint configuration you created earlier.
6. Connect the output of the **Item** node to the input of the **Client** node, then connect the **Client** node's top output to a **Debug** node.

> The **OPC UA Client** node has three outputs: the top carries the data payload, the middle indicates connection status, and the bottom provides raw responses for debugging.

7. Deploy the flow and click the **Inject** button to trigger the read.

You should see the tag value appear in the debug panel. This confirms that communication is working correctly.

You can also pass the Node ID dynamically using `msg.topic` from the Inject node if you prefer not to use an Item node.

::render-flow{:height='300'}
```json
[{"id":"d128582dda7adbed","type":"OpcUa-Client","z":"ead97ed756a13a15","endpoint":"a4df18253e5a79a0","action":"read","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"setstatusandtime":false,"keepsessionalive":false,"name":"","x":580,"y":240,"wires":[["3fc16bf912f16169"],["17724a6889ec7378"],["c6b0f16ef7371699"]]},{"id":"3fc16bf912f16169","type":"debug","z":"ead97ed756a13a15","name":"Tag Value","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":740,"y":200,"wires":[]},{"id":"2691196551812a21","type":"OpcUa-Item","z":"ead97ed756a13a15","item":"ns=3;i=1001","datatype":"Boolean","value":"","name":"OPC UA Item Node","x":370,"y":240,"wires":[["d128582dda7adbed"]]},{"id":"96d17841a7f13ac4","type":"inject","z":"ead97ed756a13a15","name":"Read tag","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":200,"y":200,"wires":[["2691196551812a21"]]},{"id":"17724a6889ec7378","type":"debug","z":"ead97ed756a13a15","name":"Errors","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":730,"y":240,"wires":[]},{"id":"c6b0f16ef7371699","type":"debug","z":"ead97ed756a13a15","name":"Raw Respons","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":760,"y":280,"wires":[]},{"id":"a4df18253e5a79a0","type":"OpcUa-Endpoint","endpoint":"opc.tcp://192.168.0.10:4840","secpol":"None","secmode":"None","none":true,"login":false,"usercert":false,"usercertificate":"","userprivatekey":""}]
```
::

#### Reading Multiple Tags

Batch reading improves performance when you need multiple data points from your equipment

1. Drag an **OPC UA Client** node and set its **Action** to "READ MULTIPLE".

![Screenshot showing OPC UA Client node with "READ MULTIPLE" action selected](https://flowfuse.com/blog/2025/07/images/read-multiple.png){dataZoomable=""}:br*Screenshot showing OPC UA Client node with "READ MULTIPLE" action selected*

2. Select the endpoint configuration.
3. Add an **OPC UA Item** node for each tag you want to read.
4. Add an **Inject** node for each Item node to trigger it.
5. Connect each Inject node to its corresponding Item node.
6. Wire all Item nodes into the OPC UA Client node.
7. Add a **Debug** node to the top output of the **Client** node.
8. Deploy the flow.
9. Click each Inject node once, the client node will store the tag definitions.
10. Send a message with `msg.topic = "readmultiple"` to trigger the actual read.
11. To clear stored items, send `msg.topic = "clearitems"`.

You now have a flexible setup for reading multiple values from your PLC on demand.

::render-flow{:height='300'}
```json
[{"id":"6f5e2b1cbce15025","type":"OpcUa-Client","z":"ead97ed756a13a15","endpoint":"","action":"readmultiple","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","useTransport":false,"maxChunkCount":"","maxMessageSize":"","receiveBufferSize":"","sendBufferSize":"","setstatusandtime":false,"keepsessionalive":false,"name":"","x":580,"y":500,"wires":[["28b575f06bbbe7a7"],["139d346aab204f2f"],["3497d5566fb78f5f"]]},{"id":"4daa958d34c648c5","type":"OpcUa-Item","z":"ead97ed756a13a15","item":"ns=5;s=Counter1","datatype":"Int32","value":"","name":"","x":380,"y":480,"wires":[["6f5e2b1cbce15025"]]},{"id":"baa2733ca1fcb69d","type":"inject","z":"ead97ed756a13a15","name":"Add item","repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"str","x":200,"y":480,"wires":[["4daa958d34c648c5"]]},{"id":"dfd96a4dfe6330af","type":"OpcUa-Item","z":"ead97ed756a13a15","item":"ns=5;s=Random1","datatype":"Double","value":"","name":"","x":380,"y":520,"wires":[["6f5e2b1cbce15025"]]},{"id":"b8d5e40a98b1fb9f","type":"inject","z":"ead97ed756a13a15","name":"Add item","repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"str","x":200,"y":520,"wires":[["dfd96a4dfe6330af"]]},{"id":"3f63c46f499c3bca","type":"inject","z":"ead97ed756a13a15","name":"Read multiple items","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"readmultiple","payload":"","payloadType":"str","x":370,"y":440,"wires":[["6f5e2b1cbce15025"]]},{"id":"75c7927996cf44c2","type":"inject","z":"ead97ed756a13a15","name":"Clear nodeId array","repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"clearitems","payload":"","payloadType":"str","x":370,"y":560,"wires":[["6f5e2b1cbce15025"]]},{"id":"28b575f06bbbe7a7","type":"debug","z":"ead97ed756a13a15","name":"Tag Value","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":760,"y":460,"wires":[]},{"id":"139d346aab204f2f","type":"debug","z":"ead97ed756a13a15","name":"Errors","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":500,"wires":[]},{"id":"3497d5566fb78f5f","type":"debug","z":"ead97ed756a13a15","name":"Raw Response","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":780,"y":540,"wires":[]}]
```
::

### Writing Values

In addition to reading data, OPC UA also allows you to write control signals or parameters to your equipment.

#### Writing a Single Tag

To write a single value:

1. Drag an **Inject** node onto the canvas (used to trigger the write operation).
2. Add an **OPC UA Item** node and configure:
   - **Node ID**: Enter the target identifier.
   - **Data Type**: Choose the appropriate type (e.g., `Boolean`, `Double`).
   - **Value**: Enter the value to write.
   :br![Screenshot showing OPC UA Item node configuration for write operation](https://flowfuse.com/blog/2025/07/images/opcua-item-node-write.png){dataZoomable=""}:br*OPC UA Item node configured for a write operation*
3. Connect the **Inject** node to the **Item** node.
4. Add an **OPC UA Client** node and set its **Action** to `WRITE`. :br![Screenshot showing OPC UA Client node with "WRITE" action selected](https://flowfuse.com/blog/2025/07/images/opcua-client-write-ops.png){dataZoomable=""}:br*OPC UA Client node with "WRITE" action selected*
5. Select the endpoint configuration you created earlier.
6. Connect the **Item** node to the **Client** node, then connect the **Client** node's top output to a **Debug** node.
7. Deploy the flow and click the **Inject** button to trigger the write.

The OPC UA Client node will confirm the operation with a status like &#x2A;*"values written"**.

::render-flow{:height='300'}
```json
[{"id":"c922a70d48ecba6f","type":"OpcUa-Client","z":"ead97ed756a13a15","endpoint":"","action":"write","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","useTransport":false,"maxChunkCount":"","maxMessageSize":"","receiveBufferSize":"","sendBufferSize":"","setstatusandtime":false,"keepsessionalive":false,"name":"","x":520,"y":480,"wires":[["7eb010a4671ac181"],["392bb1fd60c29baf"],["e9d279677dbc87e8"]]},{"id":"5ff1e3c2d5977a34","type":"OpcUa-Item","z":"ead97ed756a13a15","item":"ns=5;s=Counter1","datatype":"Int32","value":"20","name":"","x":340,"y":480,"wires":[["c922a70d48ecba6f"]]},{"id":"8cdd141dbdb350c7","type":"inject","z":"ead97ed756a13a15","name":"Write","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"str","x":190,"y":480,"wires":[["5ff1e3c2d5977a34"]]},{"id":"7eb010a4671ac181","type":"debug","z":"ead97ed756a13a15","name":"Tag Value","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":680,"y":440,"wires":[]},{"id":"392bb1fd60c29baf","type":"debug","z":"ead97ed756a13a15","name":"Errors","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":670,"y":480,"wires":[]},{"id":"e9d279677dbc87e8","type":"debug","z":"ead97ed756a13a15","name":"Raw Response","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":700,"y":520,"wires":[]}]
```
::

#### Writing Multiple Tags

To write multiple values at once, follow this pattern:

1. Add an **OPC UA Client** node and set its **Action** to `WRITE MULTIPLE`. :br![Screenshot showing OPC UA Client node with "WRITE MULTIPLE" action selected](https://flowfuse.com/blog/2025/07/images/opcua-client-write-multiple.png){dataZoomable=""}:br*OPC UA Client node configured for writing multiple values*
2. Select the appropriate endpoint configuration.
3. Add multiple **OPC UA Item** nodes, each configured with a **Node ID**, **Data Type**, and **Value** to be written.
4. Add an **Inject** node for each **Item** node.
5. Connect each **Inject** node to its corresponding **Item** node, then connect all **Item** nodes to the **Client** node.
6. Add a **Debug** node to the top output of the **Client** node.
7. Deploy the flow and trigger all **Inject** nodes to load the values.
8. To execute the write operation, send a message with `msg.topic = "writemultiple"`.
9. To clear the stored items, send a message with `msg.topic = "clearitems"`.

This setup allows you to prepare multiple tag values and write them all at once, giving you precise control through a single command.

::render-flow{:height='300'}
```json
[{"id":"ed421a9.d6319e8","type":"OpcUa-Client","z":"ead97ed756a13a15","endpoint":"","action":"writemultiple","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","useTransport":false,"maxChunkCount":"","maxMessageSize":"","receiveBufferSize":"","sendBufferSize":"","setstatusandtime":false,"keepsessionalive":false,"name":"","x":560,"y":420,"wires":[["b0788fb9285c48ea"],["bde690208cbf2c4c"],["0883826b4a0ca030"]]},{"id":"96bd763.14a9308","type":"OpcUa-Item","z":"ead97ed756a13a15","item":"ns=3;i=1007","datatype":"Double","value":"1.0","name":"","x":360,"y":400,"wires":[["ed421a9.d6319e8"]]},{"id":"d8a68c7a.a73008","type":"inject","z":"ead97ed756a13a15","name":"Add item","repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"str","x":180,"y":400,"wires":[["96bd763.14a9308"]]},{"id":"8ae51c8c.20bd3","type":"OpcUa-Item","z":"ead97ed756a13a15","item":"ns=3;i=1008","datatype":"Int32","value":"50","name":"","x":360,"y":440,"wires":[["ed421a9.d6319e8"]]},{"id":"1335adce.7f46ba","type":"inject","z":"ead97ed756a13a15","name":"Add item","repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"str","x":180,"y":440,"wires":[["8ae51c8c.20bd3"]]},{"id":"2c050a3d.91f496","type":"inject","z":"ead97ed756a13a15","name":"Write multiple items","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"writemultiple","payload":"","payloadType":"str","x":350,"y":360,"wires":[["ed421a9.d6319e8"]]},{"id":"690e4f9f.faeca","type":"inject","z":"ead97ed756a13a15","name":"Clear nodeId array","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"clearitems","payload":"","payloadType":"str","x":350,"y":480,"wires":[["ed421a9.d6319e8"]]},{"id":"b0788fb9285c48ea","type":"debug","z":"ead97ed756a13a15","name":"Tag Value","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":740,"y":380,"wires":[]},{"id":"bde690208cbf2c4c","type":"debug","z":"ead97ed756a13a15","name":"Errors","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":730,"y":420,"wires":[]},{"id":"0883826b4a0ca030","type":"debug","z":"ead97ed756a13a15","name":"Raw Response","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":760,"y":460,"wires":[]}]
```
::

## What’s Next

You’ve now mastered the fundamentals of OPC UA integration, connecting to servers, browsing tags, and reading or writing data. These core building blocks lay the foundation for powerful industrial automation.

In real deployments, you will want more than Inject nodes and debug panels. With **FlowFuse Dashboard 2.0**, you can build full operator interfaces, live gauges, control buttons, trend charts, fully connected to your OPC UA data.

This guide covered the basics, but OPC UA offers far more. In the next article, we will explore:

- Subscriptions for real-time monitoring without polling
- Events and alarms directly from equipment
- Historical data queries for trend analysis
- Method calls to execute functions on your devices

When it is time to move beyond prototypes, **FlowFuse** delivers what industrial systems truly need, remote device management, instant rollbacks with full version control, built-in team collaboration, and high availability you can trust.

If you’re ready to simplify your OPC UA integration and scale industrial workflows with Node-RED, [start your free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} of FlowFuse today.

OPC UA is one of several protocols FlowFuse uses to connect PLCs to MQTT, cloud platforms, and enterprise systems. See the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/) for EtherNet/IP, Siemens S7, Modbus, and more.


# How we Built a Smart Manufacturing Order Execution Panel with FlowFuse

A few days ago, I had a conversation with a solution architect about how the lack of integration between the shop floor and business systems often leads to missed opportunities and financial losses. He also mentioned that while many manufacturers want to bridge this gap, they often hesitate, mostly due to concerns about complexity of integration or fear of disrupting existing operations.

But there is no need to be afraid. In this blog, I will walk you through a simple demo that shows how easy it can be to connect production systems with your ERP. With just a small integration, you can improve visibility, avoid manual errors, and prevent unnecessary losses.

To demonstrate this, I built a smart Manufacturing Order (MO) execution panel using FlowFuse, connected to ERP.

Let’s take a closer look.

## Demo: Smart Manufacturing Order Execution Panel in Action

::d
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: M_CIoHiSW6s
---
In this demonstration, an operator starts by selecting a Manufacturing Order (MO) from a list pulled directly from Odoo ERP. The system immediately checks if enough raw materials are available for that specific order.

If the materials are ready, production begins, and the MO status in Odoo is automatically updated to In Progress. The system then tracks the production count in real time. However, if materials are missing, production won’t start, and the operator is notified instantly. Once the produced quantity matches the target, the system automatically stops the line and marks the MO as Done in Odoo, completing the cycle without manual intervention.

## How It Works: Behind the Scenes

To build this system, I used **FlowFuse** to create a Node-RED flow that connects to **Odoo ERP** and controls a simulated production line.

### System Components

- **Odoo ERP**:br
  Holds Manufacturing Orders, product details, and inventory data. This integration allows for a two-way conversation between the shop floor and the business's core planning system. For a detailed guide on how to read from and write to Odoo, you can read our article, [Connect Your Shop Floor to Your ERP – Odoo Edition](https://flowfuse.com/blog/2025/06/connect-shop-floor-to-odoo-erp-flowfuse/)
- **FlowFuse**:br
  Executes logic such as fetching manufacturing orders, checking material availability, updating statuses, controlling production, and building the operator interface.
- **Simulated Production Line (Factory I/O)**:br
  Acts as the shop floor. Starts and stops production based on FlowFuse commands.
- **PLC**:br
  Receives commands from FlowFuse and controls the actual machinery or simulated production environment.
- **S7 Protocol (S7Comm)**:br
  This is the protocol used to communicate with Siemens S7 series PLCs. We use Node-RED nodes within FlowFuse to send control commands (e.g., start/stop production) and read critical data (e.g., produced quantity, machine status) directly from the PLC’s memory blocks. To learn exactly how to set this up, check out our step-by-step tutorial, [Getting Started: Integrating Siemens S7 PLCs with Node-RED](https://flowfuse.com/blog/2025/01/integrating-siemens-s7-plcs-with-node-red-guide/)

Below is the full Node-RED flow that powers this smart manufacturing execution panel.

  :::render-flow{:height='300'}
  ```json
  [{"id":"FFF0000000000001","type":"tab","label":"Manufacturing Order Execution Panel","disabled":false,"info":""},{"id":"9aad63553d0d5812","type":"group","z":"FFF0000000000001","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["4e8b22877e33b496","a0e5e90344e88702","16744562f37152fd","f44680e87cdce3ac","b04986985da9af6d"],"x":14,"y":99,"w":1272,"h":82},{"id":"283e4560434b3d9d","type":"group","z":"FFF0000000000001","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["13462b8b0f1607f7","8a482fd274547e0f","3efb1c1f34d51979","41b87ca07226c044","dda4ef8740ffb258","226fe05ccb3626e4","51a994a919a9ef23","4556a1575a3c8cf0","e23884a220043451","9df108ae0c62ee39"],"x":14,"y":179,"w":1272,"h":162},{"id":"8df3544692ccd8d8","type":"group","z":"FFF0000000000001","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["0ce2a3c49003ca9f","b11dfaf019777940"],"x":14,"y":359,"w":572,"h":82},{"id":"0a5f467b0d3f15a9","type":"group","z":"FFF0000000000001","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["e079fb2baac0a769","e8069c4a2b3f5457","1f9227a4cad571bd","c81b1fb4e1b78f64","befaaf0dd824e0e9","8f4dbf296b38a3c3"],"x":14,"y":559,"w":912,"h":122},{"id":"b9d1401e33f657a5","type":"group","z":"FFF0000000000001","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["67598322bfa17031","2c3da53c9785237d"],"x":14,"y":459,"w":352,"h":82},{"id":"c85a3940e02e9d05","type":"ui-theme","name":"Default Theme","colors":{"surface":"#1a1c25","primary":"#0094ce","bgPage":"#000102","groupBg":"#1a1c25","groupOutline":"#000000"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"18818bdefd1f27ce","type":"odoo-xmlrpc-config","url":"${URL}","db":"${DB_NAME}","username":"${EMAIL}","password":"${PASSWORD}"},{"id":"e70720e10a4d3490","type":"ui-page","name":"Manufacturing Order Execution Panel\t","ui":"127331d7913b7654","path":"/page1","icon":"home","layout":"grid","theme":"c85a3940e02e9d05","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":true,"disabled":false},{"id":"127331d7913b7654","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":true},{"id":"9beea4acdde08f57","type":"ui-group","name":". ","page":"e70720e10a4d3490","width":"3","height":"2","order":1,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"2aabe3e541e4ba61","type":"ui-group","name":"Running Order Summary","page":"e70720e10a4d3490","width":"9","height":1,"order":2,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"9dc2b3b0074096ee","type":"ui-group","name":"Manufacturing Orders","page":"e70720e10a4d3490","width":"12","height":1,"order":3,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"a75a1ee3b5119c06","type":"s7 endpoint","transport":"iso-on-tcp","address":"192.168.1.10","port":"102","rack":"0","slot":"1","localtsaphi":"01","localtsaplo":"00","remotetsaphi":"01","remotetsaplo":"00","connmode":"rack-slot","adapter":"","busaddr":2,"cycletime":1000,"timeout":2000,"name":"","vartable":[{"addr":"QD30","name":"Lid Counter"},{"addr":"Q1.3","name":"STOP"},{"addr":"DB4,X192.0","name":"START"}]},{"id":"13462b8b0f1607f7","type":"ui-button","z":"FFF0000000000001","g":"283e4560434b3d9d","group":"9beea4acdde08f57","name":"","label":"START","order":1,"width":"0","height":"0","emulateClick":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","iconPosition":"left","payload":"","payloadType":"str","topic":"topic","topicType":"msg","buttonColor":"green","textColor":"white","iconColor":"","enableClick":true,"enablePointerdown":false,"pointerdownPayload":"","pointerdownPayloadType":"str","enablePointerup":false,"pointerupPayload":"","pointerupPayloadType":"str","x":90,"y":260,"wires":[["51a994a919a9ef23"]]},{"id":"4e8b22877e33b496","type":"inject","z":"FFF0000000000001","g":"9aad63553d0d5812","name":"","props":[{"p":"payload"}],"repeat":"10","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"[]","payloadType":"json","x":110,"y":140,"wires":[["a0e5e90344e88702"]]},{"id":"a0e5e90344e88702","type":"odoo-xmlrpc-search-read","z":"FFF0000000000001","g":"9aad63553d0d5812","name":"","host":"18818bdefd1f27ce","model":"mrp.production","filter":"","offset":0,"limit":100,"x":350,"y":140,"wires":[["16744562f37152fd"]]},{"id":"16744562f37152fd","type":"function","z":"FFF0000000000001","g":"9aad63553d0d5812","name":"getActiveOrdersSummary","func":"const simplifiedOrders = msg.payload\n    .filter(order => order.state === \"confirmed\" || order.state === \"progress\")\n    .map(order => {\n        return {\n            id: order.id,\n            name: order.name,\n            product: order.product_id?.[1] || \"Unknown\",\n            quantity: order.product_qty,\n            state: order.state,\n            availability: order.components_availability || \"Unknown\"\n        };\n    });\n\nmsg.payload = simplifiedOrders;\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":590,"y":140,"wires":[["f44680e87cdce3ac"]]},{"id":"f44680e87cdce3ac","type":"ui-table","z":"FFF0000000000001","g":"9aad63553d0d5812","group":"9dc2b3b0074096ee","name":"","label":"","order":1,"width":0,"height":0,"maxrows":0,"passthru":false,"autocols":false,"showSearch":false,"deselect":true,"selectionType":"click","columns":[{"title":"ID","key":"id","keyType":"key","type":"text","width":"","align":"start"},{"title":"Ref No ","key":"name","keyType":"key","type":"text","width":"","align":"start"},{"title":"Production Item","key":"product","keyType":"key","type":"text","width":"","align":"start"},{"title":"Target Quantity","key":"quantity","keyType":"key","type":"text","width":"","align":"start"},{"title":"Order Status","key":"state","keyType":"key","type":"text","width":"","align":"start"}],"mobileBreakpoint":"sm","mobileBreakpointType":"defaults","action":"replace","x":870,"y":140,"wires":[["b04986985da9af6d"]]},{"id":"8a482fd274547e0f","type":"odoo-xmlrpc-update","z":"FFF0000000000001","g":"283e4560434b3d9d","name":"","host":"18818bdefd1f27ce","model":"mrp.production","filter":"","offset":0,"limit":100,"x":1160,"y":260,"wires":[[]]},{"id":"3efb1c1f34d51979","type":"change","z":"FFF0000000000001","g":"283e4560434b3d9d","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"[     [payload.id],     {\"state\": \"progress\"} ]","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":260,"wires":[["8a482fd274547e0f"]]},{"id":"41b87ca07226c044","type":"switch","z":"FFF0000000000001","g":"283e4560434b3d9d","name":"Does the MO have a material shortage?","property":"payload.availability","propertyType":"msg","rules":[{"t":"eq","v":"Not Available","vt":"str"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":640,"y":240,"wires":[["226fe05ccb3626e4"],["3efb1c1f34d51979","9df108ae0c62ee39"]]},{"id":"dda4ef8740ffb258","type":"ui-notification","z":"FFF0000000000001","g":"283e4560434b3d9d","ui":"127331d7913b7654","position":"center center","colorDefault":true,"color":"#000000","displayTime":"3","showCountdown":true,"outputs":1,"allowDismiss":true,"dismissText":"Close","allowConfirm":false,"confirmText":"Confirm","raw":false,"className":"","name":"","x":1150,"y":220,"wires":[[]]},{"id":"226fe05ccb3626e4","type":"change","z":"FFF0000000000001","g":"283e4560434b3d9d","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"Production cannot begin for this order, required materials are not available.","tot":"str"},{"t":"set","p":"orderSelected","pt":"flow","to":"{}","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":220,"wires":[["dda4ef8740ffb258"]]},{"id":"b04986985da9af6d","type":"change","z":"FFF0000000000001","g":"9aad63553d0d5812","name":"","rules":[{"t":"set","p":"orderSelected","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1160,"y":140,"wires":[[]]},{"id":"51a994a919a9ef23","type":"change","z":"FFF0000000000001","g":"283e4560434b3d9d","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"orderSelected","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":320,"y":260,"wires":[["41b87ca07226c044","4556a1575a3c8cf0"]]},{"id":"4556a1575a3c8cf0","type":"ui-template","z":"FFF0000000000001","g":"283e4560434b3d9d","group":"2aabe3e541e4ba61","page":"","ui":"","name":"Running Order Summary","order":1,"width":0,"height":0,"head":"","format":"<template>\n  <div class=\"kpi-row\">\n    <div class=\"kpi-box\">\n      <div class=\"kpi-title\">Reference</div>\n      <div class=\"kpi-value\">{{ data?.name || '--' }}</div>\n    </div>\n    <div class=\"kpi-box\">\n      <div class=\"kpi-title\">Product</div>\n      <div class=\"kpi-value\">{{ data?.product || '--' }}</div>\n    </div>\n    <div class=\"kpi-box\">\n      <div class=\"kpi-title\">Target</div>\n      <div class=\"kpi-value\">{{ data?.quantity ?? '--' }}</div>\n    </div>\n    <div class=\"kpi-box\">\n      <div class=\"kpi-title\">Produced</div>\n      <div class=\"kpi-value\">{{ data?.producedQuantity ?? '--' }}</div>\n    </div>\n  </div>\n</template>\n\n<script>\n  export default {\n  name: 'KpiDisplay',\n\n  props: {\n    id: {\n      type: String,\n      required: true\n    }\n  },\n\n  data() {\n    return {\n      data: {\n        name: '',\n        product: '',\n        quantity: null,\n        producedQuantity: null\n      }\n    };\n  },\n\n  mounted() {\n    const eventName = 'msg-input:' + this.id;\n    console.log('Listening to socket:', eventName);\n\n    this.$socket.on(eventName, (msg) => {\n      console.log('Message received:', msg);\n\n      // Merge payload with defaults to avoid missing fields\n      this.data = Object.assign({\n        name: '',\n        product: '',\n        quantity: null,\n        producedQuantity: null\n      }, msg.payload);\n    });\n  }\n};\n</script>\n\n<style scoped>\n  .kpi-row {\n    display: flex;\n    justify-content: space-between;\n    gap: 2rem;\n    margin: 1rem 0;\n  }\n\n  .kpi-box {\n    text-align: center;\n    flex: 1;\n  }\n\n  .kpi-title {\n    font-size: 1.3rem;\n    color: white;\n    margin-bottom: 0.5rem;\n  }\n\n  .kpi-value {\n    font-size: 1.3rem;\n    color: white;\n  }\n</style>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":590,"y":280,"wires":[[]]},{"id":"e23884a220043451","type":"s7 out","z":"FFF0000000000001","g":"283e4560434b3d9d","endpoint":"a75a1ee3b5119c06","variable":"Start","name":"","x":1110,"y":300,"wires":[]},{"id":"9df108ae0c62ee39","type":"change","z":"FFF0000000000001","g":"283e4560434b3d9d","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":300,"wires":[["e23884a220043451"]]},{"id":"0ce2a3c49003ca9f","type":"s7 in","z":"FFF0000000000001","g":"8df3544692ccd8d8","endpoint":"a75a1ee3b5119c06","mode":"single","variable":"Lid Counter","diff":true,"name":"","x":110,"y":400,"wires":[["b11dfaf019777940"]]},{"id":"b11dfaf019777940","type":"change","z":"FFF0000000000001","g":"8df3544692ccd8d8","name":"","rules":[{"t":"set","p":"orderSelected.producedQuantity","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":400,"y":400,"wires":[[]]},{"id":"e079fb2baac0a769","type":"inject","z":"FFF0000000000001","g":"0a5f467b0d3f15a9","name":"","props":[{"p":"payload"}],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"orderSelected","payloadType":"flow","x":150,"y":620,"wires":[["befaaf0dd824e0e9"]]},{"id":"91158f2206527fc0","type":"ui-template","z":"FFF0000000000001","group":"","page":"e70720e10a4d3490","ui":"","name":"CSS","order":0,"width":0,"height":0,"head":"","format":".v-card-title{\n    text-align:center;\n}\nth,td{\n    border: 1px solid white;\n}\n.nrdb-ui-led-bulb{\n    height:85px !important;\n    margin-left:auto;\n    margin-right:auto;\n}","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"page:style","className":"","x":90,"y":60,"wires":[[]]},{"id":"e8069c4a2b3f5457","type":"odoo-xmlrpc-update","z":"FFF0000000000001","g":"0a5f467b0d3f15a9","name":"","host":"18818bdefd1f27ce","model":"mrp.production","filter":"","offset":0,"limit":100,"x":800,"y":640,"wires":[[]]},{"id":"1f9227a4cad571bd","type":"change","z":"FFF0000000000001","g":"0a5f467b0d3f15a9","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"[     [data.id],     {\"state\": \"done\"} ]","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":640,"wires":[["e8069c4a2b3f5457"]]},{"id":"67598322bfa17031","type":"ui-button","z":"FFF0000000000001","g":"b9d1401e33f657a5","group":"9beea4acdde08f57","name":"","label":"STOP","order":2,"width":"0","height":"0","emulateClick":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","iconPosition":"left","payload":"","payloadType":"str","topic":"topic","topicType":"msg","buttonColor":"red","textColor":"white","iconColor":"","enableClick":true,"enablePointerdown":false,"pointerdownPayload":"","pointerdownPayloadType":"str","enablePointerup":false,"pointerupPayload":"","pointerupPayloadType":"str","x":90,"y":500,"wires":[["2c3da53c9785237d"]]},{"id":"2c3da53c9785237d","type":"s7 out","z":"FFF0000000000001","g":"b9d1401e33f657a5","endpoint":"a75a1ee3b5119c06","variable":"STOP","name":"","x":290,"y":500,"wires":[]},{"id":"c81b1fb4e1b78f64","type":"change","z":"FFF0000000000001","g":"0a5f467b0d3f15a9","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":600,"wires":[["8f4dbf296b38a3c3"]]},{"id":"befaaf0dd824e0e9","type":"function","z":"FFF0000000000001","g":"0a5f467b0d3f15a9","name":"checkIfOrderIsComplete","func":"let data = msg.payload;\nif (Number(data.quantity) === Number(data.producedQuantity)) {\n    msg.payload = true;\n    msg.data = data\n    return msg;\n}\nreturn null;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":370,"y":620,"wires":[["1f9227a4cad571bd","c81b1fb4e1b78f64"]]},{"id":"8f4dbf296b38a3c3","type":"s7 out","z":"FFF0000000000001","g":"0a5f467b0d3f15a9","endpoint":"a75a1ee3b5119c06","variable":"STOP","name":"","x":750,"y":600,"wires":[]}]
  ```
  :::

### Workflow Breakdown

```mermaid
sequenceDiagram
    participant Operator
    participant FlowFuse
    participant Odoo
    participant PLC
    Operator->>FlowFuse: Select MO
    FlowFuse->>Odoo: Fetch MO details
    Odoo-->>FlowFuse: Return MO + Material info
    alt Materials Available
        FlowFuse->>Odoo: Update MO to "In Progress"
        FlowFuse->>PLC: Start production
        loop While producing
            PLC-->>FlowFuse: Report produced quantity
        end
        FlowFuse->>PLC: Stop production
        FlowFuse->>Odoo: Update MO to "Done"
    else Materials Not Available
        FlowFuse-->>Operator: Notify: Cannot start
    end
```

1. **Fetch Manufacturing Orders**:br
   The system pulls a list of *confirmed* or *in progress* MOs from Odoo using HTTP requests with help of Odoo node.
2. **Check Raw Material Availability**:br
   When an operator selects an MO, FlowFuse checks if enough raw materials are available in Odoo.
3. **Start Production**:br
   If materials are available:
   - The MO status is updated to *In Progress*
   - The simulated line starts producing
4. **Track Quantity in Real Time**:br
   As the line runs, FlowFuse keeps track of the produced quantity.
5. **Stop and Complete the MO**:br
   When the produced quantity matches the MO target:
   - FlowFuse sends a stop command to the PLC
   - The MO status in Odoo is updated to *Done*

### Why This Matters for Business

This demo might seem simple, but it solves some of the most common and expensive problems on the shop floor. Think about the daily headaches: an operator starts a big job, only to find out halfway through that a key material is missing, forcing the entire line to stop. Or, they produce 10% more than the order required, creating waste that just sits in inventory.

This smart panel is designed to prevent those exact scenarios. By connecting your production line directly to your business systems, it:

- **Prevents material shortages** by automatically checking for raw materials before a job can even start.
- **Eliminates overproduction** by stopping the line the moment the target quantity is hit.
- **Gets rid of manual data entry** by instantly updating the order status in the ERP.

This means managers get a live, accurate view of what’s happening on the floor, not data from hours ago. The best part is that you don't need to overhaul your entire operation or buy a huge, complex system to get these benefits. A smart, focused integration like this can deliver real results, quickly.

## Ready to Connect Your Shop Floor?

This demo shows how even a small, targeted integration between your production line and ERP can eliminate manual errors, reduce waste, and improve visibility, without overhauling your entire system.

If you are exploring how to bring these kinds of improvements to your manufacturing operations, let’s talk.

We’d be happy to discuss how FlowFuse can help you build custom, scalable solutions tailored to your factory’s needs.

👉 [Get in touch with us](https://flowfuse.com/contact-us/)
::


# OPC UA Tutorial: Advanced Monitoring with Subscriptions, Alarms, and Historical Data

In our [previous tutorial](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/), we covered OPC UA basics, connecting to servers, reading tags, and writing values. Now it's time for the features that make OPC UA truly powerful in production.

Polling for data every few seconds works fine for demos, but real systems need better. They need instant updates when values change. They need alarms that fire immediately when something goes wrong. They need access to historical data for troubleshooting. And they need to trigger complex operations without juggling dozens of write commands.

This guide shows you how to build all of that using advanced OPC UA features in FlowFuse Node-RED.

## What You'll Learn

This guide covers four powerful OPC UA features:

- **Subscriptions**: Get real-time updates without constant polling
- **Events & Alarms**: Capture and handle equipment alerts as they happen
- **Historical Data**: Query past values for trending and analysis
- **Method Calls**: Execute functions directly on your equipment

## Prerequisites

To follow this guide, you'll need:

- FlowFuse running instance with the `node-red-contrib-opcua` nodes installed
- A working OPC UA server connection
- The basics from our [previous tutorial](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/)

> Managing and scaling Node-RED instances is easy with FlowFuse, offering DevOps pipelines, audit logs, snapshots, high availability, and much more. [Start your free trial today!](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}

Before proceeding, check which features your OPC UA server supports, most handle subscriptions and events, but historical data and methods vary by vendor.

Let's get started.

## Real-Time Monitoring with Subscriptions

OPC UA subscriptions monitor values on the server side and notify you only when they change. This is fundamentally different from polling, where you repeatedly ask for values whether they've changed or not.

Consider a pressure sensor that spikes from 5 to 20 bar and back to 5 bar in one second. With 2-second polling, you miss this critical event entirely. With subscriptions, the server captures it and notifies you immediately.

The efficiency gains are significant too. Monitoring 100 tags with polling means 100 requests every 2 seconds, consuming bandwidth even when nothing changes. Subscriptions send updates only when values actually change, reducing network traffic and server load.

### Setting Up Subscriptions

To create your first subscription:

1. Drag an Inject node onto your canvas. This will trigger the subscription to start.

> Note: This article uses Inject nodes for manual triggering to illustrate key concepts. In production, it is advisable to create interactive dashboards with FlowFuse Dashboard to enable effective monitoring and control. For more information on designing operator interfaces, please refer to [this article](https://flowfuse.com/blog/2023/07/how-to-build-a-opc-client-dashboard-in-node-red/).

2. Add an OpcUa-Item node. Double-click it and enter the NodeId of the tag you want to monitor, like `ns=2;i=2007`. Select the correct data type for your tag.
3. Place an OpcUa-Client node on the canvas. Open its Configuration, select your OPC UA server endpoint configuration, and change the Action dropdown to "SUBSCRIBE". Set the interval to how often you want updates.
4. Connect the Inject output to the OpcUa-Item input. Connect the OpcUa-Item output to the OpcUa-Client input. Add a Debug node and connect the OpcUa-Client output to the Debug input.
5. Deploy your flow and click the Inject button.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

::render-flow{:height='300'}
```json
[{"id":"c62e8dab346d62bb","type":"inject","z":"7008401a.b94db","name":"","props":[{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":490,"y":740,"wires":[["cce9159a656858b9"]]},{"id":"cce9159a656858b9","type":"OpcUa-Item","z":"7008401a.b94db","item":"ns=3;i=1003","datatype":"Int32","value":"","name":"","x":700,"y":740,"wires":[["042a5d016ce879c6"]]},{"id":"1c1d56834b8d3373","type":"debug","z":"7008401a.b94db","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1130,"y":720,"wires":[]},{"id":"bccca1356626f117","type":"debug","z":"7008401a.b94db","name":"Errors","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1130,"y":760,"wires":[]},{"id":"042a5d016ce879c6","type":"OpcUa-Client","z":"7008401a.b94db","endpoint":"","action":"subscribe","deadbandtype":"a","deadbandvalue":1,"time":"2","timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"setstatusandtime":false,"keepsessionalive":false,"name":"","x":940,"y":740,"wires":[["1c1d56834b8d3373"],["bccca1356626f117"],[]]}]
```
::

When clicked, the OpcUa-Item node sends the tag to the OpcUa-Client and creates the subscription. The node’s status will update to “subscribed” once the subscription is active. When values change, they appear in the debug panel. If no value changes occur within the interval time, the status will show “keep alive” to confirm that the connection is still active.

### Subscribing to Multiple Tags

To monitor multiple tags, simply create multiple OpcUa-Item nodes and connect them all to the OpcUa-Client node. Each item node should have its own NodeId configured. When you trigger the flow, all tags start updating simultaneously.

For many tags, you can also use a Function node to subscribe to multiple tags at once. Connect the Function node directly to the OpcUa-Client node (no OpcUa-Item node needed). Use the "multiple" topic with the following code:

```javascript
msg.topic = "multiple";
msg.payload = [
    { nodeId: "ns=3;i=1007" },
    { nodeId: "ns=3;i=1002" },
    { nodeId: "ns=3;i=1001" }
];
return msg;
```

Below is the complete flow monitoring multiple tags:

::render-flow{:height='300'}
```json
[{"id":"93d8a766.c57aa8","type":"function","z":"58b3ba58c45b22dd","name":"NodeId Array","func":"msg.payload = [];\nmsg.payload.push({ nodeId: \"ns=3;i=1001\"});\nmsg.payload.push({ nodeId: \"ns=3;i=1002\"});\nmsg.payload.push({ nodeId: \"ns=3;i=1003\"});\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":430,"y":400,"wires":[["ba45b808.7ff578"]]},{"id":"2d805dd3.473632","type":"inject","z":"58b3ba58c45b22dd","name":"Subscribe multiple","props":[{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"multiple","x":230,"y":400,"wires":[["93d8a766.c57aa8"]]},{"id":"ba45b808.7ff578","type":"OpcUa-Client","z":"58b3ba58c45b22dd","endpoint":"","action":"subscribe","deadbandtype":"a","deadbandvalue":1,"time":"2","timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":"","maxMessageSize":"","receiveBufferSize":"","sendBufferSize":"","setstatusandtime":false,"keepsessionalive":false,"name":"","x":620,"y":400,"wires":[["8d7ef05fbd80d2f9"],["591cb7f46dd507af"],[]]},{"id":"8d7ef05fbd80d2f9","type":"debug","z":"58b3ba58c45b22dd","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":790,"y":380,"wires":[]},{"id":"591cb7f46dd507af","type":"debug","z":"58b3ba58c45b22dd","name":"Errors","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":790,"y":420,"wires":[]}]
```
::

This subscribes to all tags in the array with a single request.

When using the "multiple" topic, each value update arrives in OPC UA's DataValue format. Here's what you'll see in the debug panel:

```text
{
    value: {
        dataType: "Double",
        value: 23.5
    },
    statusCode: {
        value: 0,  // 0 = Good
        description: "Good"
    },
    serverTimestamp: "2025-07-24T11:12:45.640Z",
    sourceTimestamp: "2025-07-24T10:33:17.697Z"
}
```

Subscribing to multiple tags with OpcUa-Item nodes returns just the value.

### Stopping Subscriptions

To stop receiving updates and free up server resources, you have two options:

**UNSUBSCRIBE**: Removes specific monitored items from the subscription but keeps the subscription alive. Use this when you want to stop monitoring certain tags while keeping others active.

**DELETESUBSCRIPTION**: Completely removes the subscription and all its monitored items. Use this when you're done monitoring and want to clean up all resources.

To use either action, change the OpcUa-Client node's Action dropdown to "unsubscribe" or "deletesubscription".

## Events and Alarms

OPC UA events and alarms go beyond simple value monitoring. While subscriptions tell you "the temperature is 95°C", events tell you "high temperature alarm triggered at 14:32:15 on Tank 3".

Events capture the full context of what happened, when it happened, and what needs attention. Alarms are a special type of event that requires acknowledgment - perfect for critical situations that need human intervention.

### Setting Up Event Monitoring

1. Add an Inject node to trigger the event subscription.
2. Add an OpcUa-Event node and configure the Source node to the event source. For server-wide events, use `ns=0;i=2253` (the Server object).
3. Add an OpcUa-Client node with Action set to "EVENTS".
4. Connect the Inject output to the OpcUa-Item node input. Connect the OpcUa-Item output to the OpcUa-Client input. Add a Debug node and connect the OpcUa-Client output to the Debug input.

Deploy and trigger the flow. The debug panel will show events as they occur on your server.

::render-flow{:height='300'}
```json
[{"id":"d72f52a6.35fa3","type":"OpcUa-Event","z":"5d665294.f65f14","root":"ns=0;i=2253","activatecustomevent":false,"eventtype":"i=2041","customeventtype":"","name":"All events","x":400,"y":120,"wires":[["ae628046.ca67c"]]},{"id":"96c3ea4c.7897e8","type":"inject","z":"5d665294.f65f14","name":"Subscribe events","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":"","topic":"","payload":"","payloadType":"str","x":220,"y":120,"wires":[["d72f52a6.35fa3"]]},{"id":"ae628046.ca67c","type":"OpcUa-Client","z":"5d665294.f65f14","endpoint":"","action":"events","deadbandvalue":"","time":"2","timeUnit":"s","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":"","maxMessageSize":"","receiveBufferSize":"","sendBufferSize":"","setstatusandtime":false,"keepsessionalive":false,"name":"Prosys events","x":580,"y":120,"wires":[["67203130.a7a05"],["1a7bf6600cc8bec0"],[]]},{"id":"67203130.a7a05","type":"debug","z":"5d665294.f65f14","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":100,"wires":[]},{"id":"1a7bf6600cc8bec0","type":"debug","z":"5d665294.f65f14","name":"Errrors","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":140,"wires":[]}]
```
::

### Acknowledging Events

When alarms trigger, operators often need to acknowledge them to indicate they've seen the issue. Here's how to send acknowledgments back to the OPC UA server:

1. Add an Inject node to manually trigger the acknowledgment.
2. Add a Function node to prepare the acknowledgment message.
3. In the Function node, add the following code. Comments within the code explain what needs to be replaced.

```javascript
msg.topic = "ns=6;s=MyLevel.Alarm";        // The alarm's NodeId
msg.conditionId = "ns=6;s=MyLevel.Alarm/0:EventId";  // NodeId + "/0:EventId"
msg.comment = "Acknowledged via Node-RED";  // Your acknowledgment message
return msg;
```

4. Add an OpcUa-Client node and configure it with your OPC UA server endpoint. Open the node’s configuration and set the Action dropdown to "ACKNOWLEDGE".
5. Connect the Inject output to the Function input. Connect the Function output to the OpcUa-Client input.

::render-flow{:height='300'}
```json
[{"id":"99a5c133.d9bdb","type":"inject","z":"58b3ba58c45b22dd","name":"Acknowledge event","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":"","topic":"","payload":"","payloadType":"str","x":210,"y":300,"wires":[["cf182b3.04017d8"]]},{"id":"cf182b3.04017d8","type":"function","z":"58b3ba58c45b22dd","name":"AlarmID and EventID","func":"msg.topic = \"ns=6;s=MyLevel.Alarm\";\nmsg.conditionId = \"ns=6;s=MyLevel.Alarm/0:EventId\";\nmsg.comment = \"Node-RED OPCUA Ack\";\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":430,"y":300,"wires":[["af39662a.1fd078"]]},{"id":"39a1c77b1fb33695","type":"debug","z":"58b3ba58c45b22dd","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":810,"y":280,"wires":[]},{"id":"e50779c74918b1b9","type":"debug","z":"58b3ba58c45b22dd","name":"Errrors","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":810,"y":320,"wires":[]},{"id":"af39662a.1fd078","type":"OpcUa-Client","z":"58b3ba58c45b22dd","endpoint":"","action":"acknowledge","deadbandtype":"a","deadbandvalue":"5","time":"1","timeUnit":"s","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":"","maxMessageSize":"","receiveBufferSize":"","sendBufferSize":"","setstatusandtime":false,"keepsessionalive":false,"name":"OPC UA Client","x":640,"y":300,"wires":[["39a1c77b1fb33695"],["e50779c74918b1b9"],[]]}]
```
::

Deploy the flow. When you click the Inject button, it sends the acknowledgment to the server. The alarm state changes to "Event: \<alarm's NodeId> Acknowledged" and operators know someone has seen the issue.

## Method Calls

OPC UA methods let you execute functions directly on your equipment. Instead of writing multiple values to trigger an action, you call a method with parameters, like calling a function in code.

Methods are ideal for complex operations like starting batch processes, resetting counters, or triggering calibration routines. They encapsulate the logic on the server side, making your Node-RED flows simpler and more reliable.

### Calling Methods

To call a method on your OPC UA server:

1. Add an Inject node to trigger the method call.
2. Add an OpcUa-Method node and double-click it. Select your OPC UA endpoint, then enter the Object ID (like `ns=6;s=MyDevice`) and Method ID (like `ns=6;s=MyMethod`).
3. In the Arguments section, enter each argument's name, type, and value. For example:
   - Name: `Operator`, Type: `String`, Value: "sin"
   - Name: `Value`, Type: `Double`, Value: `3.3`
4. Connect the Inject output to the OpcUa-Method input. Add a Debug node to see the result.

::render-flow{:height='300'}
```json
[{"id":"9b199c7f.82f47","type":"OpcUa-Method","z":"4d24eae5.3b9b24","endpoint":"","objectId":"ns=6;s=MyDevice","methodId":"ns=6;s=MyMethod","name":"Prosys MyMethod(sin, 3.3)","inputArguments":[],"arg0name":"Operator","arg0type":"String","arg0typeid":"","arg0value":"sin","arg1name":"Value","arg1type":"Double","arg1typeid":"","arg1value":"3.3","arg2name":"","arg2type":"","arg2typeid":"","arg2value":"","out0name":"","out0type":"","out0typeid":"","out0value":"","x":760,"y":120,"wires":[["aad9fc2a.a94b4"]]},{"id":"aad9fc2a.a94b4","type":"debug","z":"4d24eae5.3b9b24","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":970,"y":120,"wires":[]},{"id":"6188d1de770fbb95","type":"inject","z":"4d24eae5.3b9b24","name":"Call Method","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":530,"y":120,"wires":[["9b199c7f.82f47"]]}]
```
::

Deploy and click the Inject button. The method executes on the server and the node status changes to "Method Executed". The result appears in the debug panel.

## Historical Data Access

OPC UA Historical Access lets you query past values from your equipment. Instead of just seeing current temperature, you can ask "what was the temperature yesterday at 3 PM?" or "show me all pressure values from the last shift."

This is essential for troubleshooting, compliance reporting, and trend analysis. However, not all OPC UA servers support historical data, check your server documentation first. Also, not all tags are configured for history, verify that the "Historizing" attribute is set to true for your tag.

### Reading Historical Values

To query historical data from your server:

1. Add an Inject node to trigger the historical read.
2. Add a Function node to prepare the query parameters.
3. In the Function node, add this code:

```javascript
msg.topic = "NodeId ns=6;s=MyLevel"; // Replace with your NodeId
msg.aggregate = "raw"; // Or use: "min", "max", "ave", "interpolative"
msg.start = new Date(Date.now() - 60 * 60 * 1000); // 1 hour ago
msg.end = new Date(); // Now
return msg;
```

4. Add an OpcUa-Client node. Open its configuration and set the Action dropdown to "HISTORY".
5. Connect the Inject output to the Function input. Connect the Function output to the OpcUa-Client input. Add a Debug node to see the historical values.

::render-flow{:height='300'}
```json
[{"id":"0c43bd35230132af","type":"OpcUa-Client","z":"58b3ba58c45b22dd","endpoint":"","action":"history","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":"","maxMessageSize":"","receiveBufferSize":"","sendBufferSize":"","setstatusandtime":false,"keepsessionalive":false,"name":"","x":620,"y":140,"wires":[["532ae640b386e34e"],["24678e079b08c81d"],[]]},{"id":"5d8f9b5854a12919","type":"inject","z":"58b3ba58c45b22dd","name":"Get Historical Data","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":270,"y":140,"wires":[["9c071e5a8e543eba"]]},{"id":"9c071e5a8e543eba","type":"function","z":"58b3ba58c45b22dd","name":"","func":"msg.topic = \"ns=3;i=1001\";\nmsg.aggregate = \"ave\";  // Try: \"min\", \"max\", \"ave\", \"interpolative\"\nmsg.start = new Date(Date.now() - 60 * 60 * 1000); // 1 hour ago\nmsg.end = new Date(); // Now\nmsg.interval = 300000;  // Required for aggregates: 5-minute intervals\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":440,"y":140,"wires":[["0c43bd35230132af"]]},{"id":"532ae640b386e34e","type":"debug","z":"58b3ba58c45b22dd","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":790,"y":120,"wires":[]},{"id":"24678e079b08c81d","type":"debug","z":"58b3ba58c45b22dd","name":"Errrors","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":790,"y":160,"wires":[]}]
```
::

Deploy and click the Inject button. The debug panel shows all stored values for that tag within your time range.

### Advanced Historical Queries

While all historized tags support raw data, aggregate support varies by tag type. Analog values typically support aggregates like min, max, and ave, while discrete tags may only support raw.

**Working with Aggregates:**

```javascript
msg.topic = "ns=6;s=MyLevel";
msg.aggregate = "ave";  // Options: "min", "max", "ave", "interpolative"
msg.start = new Date(Date.now() - 60 * 60 * 1000); // 1 hour ago
msg.end = new Date(); // Now
msg.interval = 300000;  // Required for aggregates: 5-minute intervals
return msg;
```

**Hourly Averages for the Last Day:**

```javascript
msg.topic = "ns=3;s=Temperature";
msg.aggregate = "ave";
msg.start = new Date(Date.now() - 24*60*60*1000);  // 24 hours ago
msg.end = new Date();
msg.interval = 3600000;  // 1-hour intervals
return msg;
```

**Peak Detection:**

```javascript
// Find maximum values in 15-minute windows
msg.topic = "ns=3;s=Pressure";
msg.aggregate = "max";
msg.start = new Date().setHours(0,0,0,0);  // Midnight today
msg.end = new Date();
msg.interval = 900000;  // 15-minute intervals
return msg;
```

The historical data returns with timestamps and quality codes. Use this for shift reports, compliance documentation, or troubleshooting equipment issues that happened hours or days ago.

You've now mastered the advanced features that make OPC UA essential for industrial systems. With subscriptions, you're monitoring values in real-time without wasting bandwidth. With events and alarms, you're capturing critical alerts the moment they happen. With method calls, you're executing complex operations with a single command. And with historical access, you have the data trail needed for analysis and compliance.

## Scale Your OPC UA Implementation

Managing OPC UA flows across multiple sites? FlowFuse helps teams deploy Node-RED to hundreds of edge devices with one click, monitor everything from a central dashboard, and roll back instantly if something goes wrong. Built-in team collaboration, audit logs, and enterprise security keep your industrial data safe.

Following our managed MQTT broker, we've now added database services built right into the platform, plus new AI features that make building flows faster than ever.

Connecting PLCs beyond OPC UA? FlowFuse also supports Siemens S7, EtherNet/IP, Modbus TCP/RTU, and MQTT, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/) for all supported protocols and use cases.

[Get started free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and scale and manage your Node-RED deployments today.


# Save with FlowFuse Annual Billing – Now Available!

We're excited to announce that FlowFuse customers can now choose annual billing for their Starter and Pro plans! Starting today, when you choose to pay for a full year upfront, you'll get one month completely free.

:product-update-note

## How Annual Billing Works

Switching to annual billing is straightforward:

**New customers:** Select annual billing when signing up for Starter or Pro plans

**Existing customers:** To switch to annual billing, go to **Billing** → **Upgrade Team**. Enable the yearly billing toggle, then click Switch to Yearly Billing.

When you switch to annual billing, any unused time from your current bill will be applied as a credit on your new invoice. For example, if you paid for a month and you upgrade to annual billing halfway through the month, that remaining half of a month charge will be deducted from your next invoice.

As your applications grow with additional Node-RED instances, you may wonder what happens if you add or delete instances. Not a problem: additional instances beyond the basic allowance for your plan - one hosted instance for Starter, five instances for Pro - will be billed yearly as well, but if you remove instances the amount you have already paid will be prorated either toward the next yearly billing cycle or toward any new product subscriptions you add, whichever comes first.

Your annual subscription will automatically renew each year unless you choose to cancel, giving you continuous access to FlowFuse's comprehensive Node-RED hosting and development platform.

## Why Choose Annual Billing?

Beyond the immediate cost savings, annual billing offers several advantages for teams and individual developers:

**Financial Benefits:** Lock in current pricing for a full year and save money that can be invested back into your projects and development initiatives.

**Administrative Simplicity:** Reduce the overhead of monthly billing cycles and invoice processing, especially valuable for teams managing multiple subscriptions.

**Long-term Planning:** Annual commitments align well with project planning cycles and budget allocation, making it easier to plan your Node-RED development roadmap.

## Perfect for Growing Teams

Whether you're a solo developer working on IoT projects or part of a larger team building enterprise automation solutions, annual billing provides the stability and savings that support sustained growth and development.

Our Starter plan remains perfect for individual developers and small projects, while the Pro plan continues to offer the advanced features and scalability that growing teams need.

## Get Started Today

Ready to start saving with annual billing? Log into your FlowFuse account to make the switch, or sign up for a new annual plan today.

Questions about annual billing or need help choosing the right plan? Our support team is ready to help.

[Try FlowFuse free →](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}


# FlowFuse API for Industry: Automating Node-RED Instances, Devices, and CI/CD Tasks

FlowFuse includes an API that lets you manage Node-RED instances, edge devices, and deployments directly from your scripts or applications. While most people use the web interface, the API is a great option if you want to automate tasks or connect FlowFuse with other tools.

In this guide, you’ll learn the basics of the FlowFuse API, along with practical examples you can start using right away.

## What is the FlowFuse API and Why Use It?

The FlowFuse API is a **REST-based interface** fully described using the **OpenAPI 3.0 Specification**, allowing you to explore its capabilities, test endpoints, and even auto-generate client libraries in multiple programming languages. It provides programmatic control over everything available in the FlowFuse platform, so instead of navigating the dashboard, you can manage Node-RED instances, devices, and deployments directly from scripts or applications.

This is particularly useful when you want to:

- Manage **multiple Node-RED instances or devices** simultaneously.
- **Automate repetitive tasks** such as starting, stopping, or updating instances.
- Build **custom notifications or alerts**.
- Implement **CI/CD pipelines** for testing and deploying flows automatically.
- Integrate FlowFuse with **external systems** like monitoring, alerting, or scheduling tools.

In short, the API provides greater flexibility, simplifies automation, and allows FlowFuse to fit seamlessly into your existing workflows.

## Getting Started with the FlowFuse API

Before you can use the API, you need:

1. **Your FlowFuse account**:br
   You will need to authenticate using an API token, which you can generate from the FlowFuse platform.

### Generating an API Token

1. Log in to the FlowFuse platform.
2. Open **User Settings → Security**.
3. Switch to the **Tokens** tab and click **Add Token**.
4. In the form that opens:
   - Give the token a descriptive name (e.g., `automation-script`).
   - (Optional) Check **Add Expiry Date** and choose a date if you want the token to automatically expire.
   - Click **Create Token** to generate it.

![FlowFuse platform token creation form showing fields for token name, expiry date, and create button.](https://flowfuse.com/blog/2025/08/images/token-form.png){dataZoomable=""}&#x2A;FlowFuse platform token creation form showing fields for token name, expiry date, and create button.*

After creation, a dialog will open showing your **secret token**. :br
Click **Copy to Clipboard** and store this token securely. It will only be shown once and provides full access to your account.

![Dialog showing the generated FlowFuse API token with copy-to-clipboard option.](https://flowfuse.com/blog/2025/08/images/copy-token.png){dataZoomable=""}&#x2A;Dialog showing the generated FlowFuse API token with copy-to-clipboard option.*

### Exploring the FlowFuse API with Swagger

FlowFuse provides **Swagger/OpenAPI documentation** that gives you a complete overview of all available endpoints, along with request and response formats.

> **Note:** The Swagger UI is **read-only**. You cannot execute API calls directly from it. Its purpose is to **display all endpoints** after visiting the page, so you can plan and structure your API calls in Node-RED flows, scripts, or other applications.

:video{ariaLabel="FlowFuse Swagger/OpenAPI documentation interface displaying endpoints for users, Node-RED instances, devices, deployments, and much more." autoPlay="true" height="456" loop="true" muted="true" playsInline="true" preload="none" width="800"}&#x2A;FlowFuse Swagger/OpenAPI documentation interface displaying endpoints for users, Node-RED instances, devices, deployments, and much more.*

#### How to Use the Swagger Docs

1. Open the [FlowFuse API documentation](https://app.flowfuse.com/api/static/index.html){rel="&#x22;nofollow&#x22;"} in your browser.
2. Once loaded, you will see **all available endpoints**, organized by category:
   - **`/api/v1/user/`** – Retrieve user details
   - **`/api/v1/instances/`** – List and manage Node-RED instances
   - **`/api/v1/devices/`** – Manage edge devices
   - **`/api/v1/deployments/`** – Trigger or monitor deployments
3. **Click on each endpoint** to expand it and review the details, including:
   - Required parameters
   - Headers
   - Response schemas
4. Use this information to construct actual API requests in **Node-RED HTTP Request nodes**, `curl`, or other scripts.

### Making Your First API Call

Once you have your API token, you can start interacting with the FlowFuse API. Every request must include your token in the **Authorization** header.

#### Example: Get User Information

A good first step is to fetch your user details to verify that your token works. You can use `curl`, any HTTP client in your preferred programming language, or even do it directly within Node-RED using an **HTTP Request** node, as shown below.

**Steps in Node-RED:**

1. Drag an **Inject** node onto the canvas.
2. Drag an **HTTP Request** node and connect it to the Inject node.
3. Double-click the HTTP Request node and configure it:
   - Method: **GET**
   - URL: `https://app.flowfuse.com/api/v1/user/`
   - Check **Use authentication**, select **Bearer Authentication**, and enter your API token.
4. Connect a **Debug** node to the HTTP Request node to see the response.
5. Deploy the flow and click the Inject button.

> **Note:** When using API tokens in Node-RED flows, always store them in **environment variables** instead of directly in the node to prevent accidental exposure when sharing flows. See [FlowFuse Environment Variables](https://flowfuse.com/blog/2023/01/environment-variables-in-node-red/) for more details.

::render-flow{:height='300'}
```json
[{"id":"6fa44538b934438b","type":"inject","z":"5027784675bcf4ee","name":"Get User Details","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":180,"y":740,"wires":[["8c7f13373e29c907"]]},{"id":"8c7f13373e29c907","type":"http request","z":"5027784675bcf4ee","name":"","method":"GET","ret":"txt","paytoqs":"ignore","url":"https://app.flowfuse.com/api/v1/user/","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"bearer","senderr":false,"headers":[],"x":390,"y":740,"wires":[["3a54169dc737b475"]]},{"id":"3a54169dc737b475","type":"debug","z":"5027784675bcf4ee","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":570,"y":740,"wires":[]}]
```
::

Once triggered, the debug panel will show your user information as shown below with status code 200, confirming that your token works and your API connection is successful.

```json
{
  "email": "john.doe@example.com",
  "email_verified": true,
  "sso_enabled": true,
  "mfa_enabled": false,
  "tcs_accepted": "2024-01-01T00:00:00.000Z",
  "id": "john12345",
  "username": "johndoe",
  "name": "John Doe",
  "avatar": "https://app.flowfuse.com/avatar/john-avatar",
  "admin": false,
  "createdAt": "2024-01-01T00:00:00.000Z",
  "suspended": false
}
```

## Automating DevOps Pipelines with the FlowFuse API

One of the most powerful features of the FlowFuse API is its ability to integrate directly with CI/CD pipelines. This makes it possible to trigger builds, deployments, or pipeline stages automatically, either from scripts or directly within Node-RED flows, reducing manual effort and accelerating development cycles.

To trigger a pipeline stage, you will use the following endpoint:

```text
PUT /api/v1/pipelines/{pipelineId}/stages/{stageId}/deploy
```

This requires two pieces of information: the **pipeline ID** and the **stage ID**.
Before triggering a deployment, you first need to retrieve the list of pipelines for your application:

```text
GET /api/v1/applications/{applicationId}/pipelines
```

This request returns all pipelines for the given application, including their **pipelineId** and the stages associated with them. Once you identify the correct **pipelineId** and **stageId**, you can use them in the `deploy` request to trigger the stage automatically.

### API Steps

Before triggering a stage, we first need to retrieve the pipeline details for the application. This will give us both the pipeline ID and the stage ID required for deployment.

**Step 1: Get Your Application ID**

1. Navigate to your application in **FlowFuse**.
2. Open the **Settings** page.
3. Copy the **Application ID** (you will need this in later steps).

**Step 2: Retrieve Pipelines for an Application**

1. Drag an **Inject** node to manually trigger the request.
2. Add an **HTTP Request** node and configure it as follows:
   - **Method:** `GET`
   - **URL:**
     ```text
     /api/v1/applications/{applicationId}/pipelines
     ```
     :brReplace `{applicationId}` with the actual Application ID you copied in Step 1.
   - **Authentication:** Enable **Bearer Authentication** and set it to use your API token from the environment.
3. Connect the **Inject** node to the **HTTP Request** node, and then connect the **HTTP Request** node to a **Debug** node.
4. Deploy the flow and click the Inject button to retrieve the pipelines.

*The response will return a list of pipelines, each containing a unique **pipelineId**.*

::render-flow{:height='300'}
```json
[{"id":"7ad2c2d998c60b39","type":"inject","z":"5027784675bcf4ee","name":"Get Pipelines","props":[],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":240,"y":480,"wires":[["dda168427fc847df"]]},{"id":"dda168427fc847df","type":"http request","z":"5027784675bcf4ee","name":"","method":"GET","ret":"txt","paytoqs":"ignore","url":"https://app.flowfuse.com/api/v1/applications/{applicationID}/pipelines","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"bearer","senderr":false,"headers":[],"x":430,"y":480,"wires":[["4a8c8520e2d33e37"]]},{"id":"4a8c8520e2d33e37","type":"debug","z":"5027784675bcf4ee","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":590,"y":480,"wires":[]}]
```
::

**Step 3: Identify the Stage**

1. Review the pipeline details returned from Step 2.
2. Note the **pipelineId** and the **stageId** of the stage you want to trigger.

**Step 4: Trigger the Stage Deployment**

Once you have the `pipelineId` and `stageId`, you can trigger the deployment stage with a `PUT` request.

1. Add another **Inject** node to trigger the deployment.
2. Connect it to a new **HTTP Request** node and configure it as follows:
   - **Method:** `PUT`
   - **URL:**
     ```text
     /api/v1/pipelines/{pipelineId}/stages/{stageId}/deploy
     ```
     :brReplace `{pipelineId}` and `{stageId}` with the values from Step 3.
   - **Authentication:** Use **Bearer Authentication** with your API token.
3. Connect the HTTP Request node to a **Debug** node to view the response.
4. Deploy the flow and click Inject.

If successful, you will receive a JSON response confirming that the deployment stage has been triggered.

```json
{"status":"importing"}
```

The FlowFuse API allows you to deploy a specific stage of a pipeline. It does not automatically move to the next stage, but you can create a workflow that monitors the status of each stage and triggers the next one once the current stage is complete.
In the following flow, the development stage is deployed every day at 10 PM. After that, the workflow checks the status of the next stage, the staging instance, before proceeding.

::render-flow{:height='300'}
```json
[{"id":"1ab940eb2ef10760","type":"http request","z":"37326e20f2cf9fc5","name":"Deploy Development Stage","method":"PUT","ret":"txt","paytoqs":"ignore","url":"https://app.flowfuse.com/api/v1/pipelines/{pipelineId}/stages/{stageId}/deploy","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"bearer","senderr":false,"headers":[],"x":380,"y":260,"wires":[["1c13b0d508913f6d"]]},{"id":"293221e2fafef9ff","type":"http request","z":"37326e20f2cf9fc5","name":"Check Staging Instance Status","method":"GET","ret":"obj","paytoqs":"ignore","url":"https://app.flowfuse.com/api/v1/projects/${instanceId}/status","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"bearer","senderr":false,"headers":[],"x":370,"y":380,"wires":[["24192bf21e52edd2"]]},{"id":"6f94bfb0d3198597","type":"http request","z":"37326e20f2cf9fc5","name":"Deploy Staging Stage","method":"PUT","ret":"txt","paytoqs":"ignore","url":"https://app.flowfuse.com/api/v1/pipelines/{pipelineId}/stages/{stageId}/deploy","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"bearer","senderr":false,"headers":[],"x":800,"y":380,"wires":[["b267c3b0ecbbf0bd"]]},{"id":"24192bf21e52edd2","type":"switch","z":"37326e20f2cf9fc5","name":"Is Running?","property":"payload.meta.state","propertyType":"msg","rules":[{"t":"eq","v":"running","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":610,"y":380,"wires":[["6f94bfb0d3198597","9cf7ccb7e740b39e"]]},{"id":"7ace2bed48a14cda","type":"inject","z":"37326e20f2cf9fc5","name":"Trigger Pipeline","props":[],"repeat":"","crontab":"00 22 * * *","once":false,"onceDelay":"30","topic":"","x":240,"y":200,"wires":[["1ab940eb2ef10760"]]},{"id":"b267c3b0ecbbf0bd","type":"debug","z":"37326e20f2cf9fc5","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":440,"wires":[]},{"id":"1c13b0d508913f6d","type":"function","z":"37326e20f2cf9fc5","name":"Wait for Stage Complete","func":"// Clear any existing interval or timeout from context\nlet existingInterval = context.get(\"intervalId\");\nlet existingTimeout = context.get(\"timeoutId\");\n\nif (existingInterval) {\n    clearInterval(existingInterval);\n    context.set(\"intervalId\", null);\n}\nif (existingTimeout) {\n    clearTimeout(existingTimeout);\n    context.set(\"timeoutId\", null);\n}\n\n// If state = \"running\", stop polling completely\nif (msg.payload?.meta?.state === \"running\") {\n    node.status({ fill: \"green\", shape: \"dot\", text: \"Stage running\" });\n    return null; // stop completely\n}\n\n//  send the first message immediately\nnode.send(RED.util.cloneMessage(msg));\n\n// Start polling interval (send msg every 2 seconds)\nlet id = setInterval(() => {\n    node.send(RED.util.cloneMessage(msg)); // clone msg to avoid side effects\n}, 2000);\n\n// Auto-clear interval after 60 seconds to avoid leaks\nlet timeoutId = setTimeout(() => {\n    clearInterval(id);\n    context.set(\"intervalId\", null);\n    context.set(\"timeoutId\", null);\n    node.status({ fill: \"red\", shape: \"dot\", text: \"Polling stopped (timeout)\" });\n}, 60000);\n\n// Save interval and timeout IDs in context\ncontext.set(\"intervalId\", id);\ncontext.set(\"timeoutId\", timeoutId);\n\n// Update node status to indicate polling is active\nnode.status({ fill: \"yellow\", shape: \"ring\", text: \"Polling...\" });\n\n// Do not return any message immediately (already sent above)\nreturn null;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":410,"y":320,"wires":[["293221e2fafef9ff"]]},{"id":"9cf7ccb7e740b39e","type":"link out","z":"37326e20f2cf9fc5","name":"link out 1","mode":"link","links":["a58e64a12df0c55e"],"x":725,"y":340,"wires":[]},{"id":"a58e64a12df0c55e","type":"link in","z":"37326e20f2cf9fc5","name":"link in 1","links":["9cf7ccb7e740b39e"],"x":255,"y":320,"wires":[["1c13b0d508913f6d"]]}]
```
::

## Conclusion

The FlowFuse API puts you in control of your Node-RED infrastructure through code. Instead of managing instances manually, you can automate repetitive tasks, integrate with existing tools, and build custom workflows that fit your exact needs.

Whether you're managing a handful of instances or thousands of edge devices, the API scales with you. It's straightforward to get started, generate a token, make your first API call, and gradually automate more of your workflow as you go.

The real value comes from the time you save and the consistency you gain. Let the API handle the routine work while you focus on building great Node-RED applications.

Start today by generating your first API token and making a call, you’ll see how quickly FlowFuse can automate your Node-RED operations. [Sign up for free](https://app.flowfuse.com){rel="&#x22;nofollow&#x22;"} and put your industrial workflows on autopilot.


# FlowFuse 2.21: AI-Assisted SQL, Low-Code Custom Nodes, and Remote Instance Performance Insights

It's been a very busy release and we have many great new features available on FlowFuse that will provide a better Node-RED development experience, makes it easier to develop and interface with your Unified Namespace, provide more insight into Remote Instance performance and new low-code tooling for building your own custom Node-RED nodes.

:product-update-note

## Assistant Functionality in Tables Nodes

:video{ariaLabel="Video showing FlowFuse Expert in Tables" autoPlay="true" height="720" loop="true" muted="true" playsInline="true" preload="none" width="1364"}*FlowFuse Expert in Tables recognizes table schema and turns natural language prompts into SQL queries*

Building on our successful [Tables launch in 2.20](https://flowfuse.com/blog/2025/07/flowfuse-release-2-20/), we've now integrated AI assistance directly into our Tables nodes. This lowers the barrier for working with databases, reducing the dependency on SQL knowledge. With this, you can type a natural language prompt that will be interpreted in light of the structure of tables in your FlowFuse Tables, which enables an AI-supported autocomplete and assists with writing SQL specifically for connected FlowFuse tables.

This integration makes working with FlowFuse Tables even more accessible, allowing developers to leverage AI guidance for database operations without requiring deep SQL expertise.

## Summarize Snapshots

![Screenshot showing snapshot summarization feature](https://flowfuse.com/blog/2025/08/images/snapshot.png){dataZoomable=""}*New snapshot summarization provides clear, AI-generated descriptions of changes between versions*

Managing instance versions becomes more intuitive with our new Snapshot Summary feature. When creating snapshots, FlowFuse can now automatically generate intelligent summaries that describes the changes introduced. This saves you time, and makes it much easier for teams to understand project evolution and quickly identify the right version for deployment or rollback scenarios.

Available for Pro and Enterprise.

## Team Broker Nodes

Easily publish and subscribe to topics in the FlowFuse Broker using new Team Broker nodes. Send a message from a Node-RED flow directly into the FlowFuse Broker. These new nodes extend the Unified Namespace capabilities of FlowFuse and provide:

- **Publish Node**: Send messages to any topic on your team broker with configurable retention settings
- **Subscribe Node**: Receive messages from specified topics with flexible output formatting
- **Auto-Configuration**: Nodes automatically use your team's broker settings
- **TypedInput Support**: Dynamic topic configuration using message properties or static values

These nodes make working between Node-RED and the FlowFuse Broker much simpler and easier.

## Low-Code Custom Node Development

[Subflows](https://nodered.org/docs/user-guide/editor/workspace/subflows){rel="&#x22;nofollow&#x22;"} are a great way in Node-RED to build custom nodes, all within the Node-RED Editor, and without having to write any code. The limitation of Subflows though is that they're constrained to just one Instance of Node-RED, they cannot be shared across your whole team. That is no longer the case.

We've now introduced the Subflow exporter which provides a low-code and intuitive way to create and manage custom nodes.

From the sidebar in your Node-RED Editor, you can now very easily create and manage custom nodes, without writing code or having to create and manage your own version control infrastructure. Simply create a flow in Node-RED, convert it to a subflow, fill out the package details for your new custom node and hit "Publish". Now your new node is available for all to install across your FlowFuse team.

Available for Enterprise customers only.

## Remote Instance Observability

![Screenshot of remote instance monitoring interface](https://flowfuse.com/blog/2025/08/images/remote.png)*Remote Instance monitoring in the Performance view provides usage insights*

Following the success of our [Hosted Instance performance monitoring](https://flowfuse.com/blog/2025/06/flowfuse-release-2-18/#enhanced-observability-for-better-performance-management), we've extended observability capabilities to include Remote Instances too. This extension gives insight into CPU usage and memory usage for your remote instances.

This enhancement is particularly valuable for industrial deployments where remote instances run critical processes across multiple locations.

## Blueprint: Energy Monitoring Dashboard

![Screenshot of energy monitoring dashboard](https://flowfuse.com/blog/2025/08/images/energy-monitoring.png)*Energy Monitoring Dashboard provides realtime usage and cost insights*

This Blueprint provides a real-time energy monitoring dashboard template for industrial facilities. It features live consumption tracking, cost analytics, spike detection, and historical trending with an integrated energy rate display. Perfect for demonstrating IoT energy management capabilities, and with Node-RED, it is fully customizable.

## Annual Billing Option

![Screenshot of annual billing selection interface](https://flowfuse.com/blog/2025/08/images/annual-billing.png){dataZoomable=""}*New annual billing options provide cost savings and simplified budget planning*

FlowFuse Cloud customers on Starter and Pro plans can now choose to subscribe on a yearly basis and receive a free month for doing so. This allows teams to save money compared to a monthly subscription and lock in current pricing.

## What's Next?

For the next release, we're working on features that will enable you to connect your own AI models with Node-RED and FlowFuse, paving the way to create AI-supported automations in your applications. We're also planning on pushing a lot of performance updates to Dashboard, and to make it even easier to build your own applications on FlowFuse. We're excited about it -- stay tuned!

## What else is new?

For a complete list of everything included in our 2.21 release, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.21.0){rel="&#x22;nofollow&#x22;"}.

Your feedback continues to be invaluable in shaping FlowFuse's development. We'd love to hear your thoughts on these new features and any suggestions for future improvements. Please share your experiences or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Which of these new features are you most excited to try? Email me directly at <greg@flowfuse.com> - I'd love to hear from you!

## Try FlowFuse

### FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in the cloud within minutes.

### Self-Hosted

Get FlowFuse running locally in under 30 minutes using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# The Evolution of Business Automation: Why Pricing Models Matter

The automation landscape is evolving rapidly, and recent industry developments have sparked important conversations about how businesses should evaluate their automation platforms. N8N’s recent shift from workflow-based to execution-based pricing, positioned as removing limits, has received mixed reactions from the community, with many growing businesses finding the reality more complex. As pricing models change across the industry, now is the perfect time to reflect on what truly matters when choosing the right automation solution for your needs.

## The Current State of Automation Pricing

Many automation platforms are rethinking their pricing structures, moving from workflow-based models to execution-based billing. While this approach aims to provide more flexibility, it can create new challenges for businesses trying to predict costs and plan their automation strategies.

Execution-based pricing means each step or run of your workflow consumes credits or counts toward your usage limits. What initially appears straightforward can become complex when scaling automation across teams and departments.

## What Business Users Really Need

Based on conversations we're seeing in automation communities, business users are looking for:

- **Cost predictability**: The ability to forecast automation expenses as operations grow
- **Scalability confidence**: Knowing their platform can handle increased complexity without surprises
- **Team collaboration**: Tools that support multiple users working together effectively
- **Enterprise readiness**: Solutions built to handle business-critical operations from the start

## FlowFuse: Built for Business Automation

FlowFuse takes a different approach to business automation, focusing on what enterprises actually need rather than trying to retrofit consumer tools for business use.

### Industrial-Grade Foundation

FlowFuse is designed as an Industrial Application Platform that empowers teams to build, deploy and manage applications that optimize industrial operations. This isn't an add-on feature, it's fundamental to how we approach automation.

### The Power of Node-RED

At the heart of FlowFuse is Node-RED, the free and truly Open Source low-code programming tool of choice for industrial applications. With over 5,000 community-contributed nodes, Node-RED enables engineers to collect, transform, and integrate data through visualized dashboards. It's been proven in everything from home automation to massive industrial deployments.

### Transparent Business Model

Rather than complex execution counting, FlowFuse focuses on delivering reliable automation that scales with your business needs. Our approach eliminates the guesswork and lets you focus on building solutions rather than calculating usage; costs scale with how many Node-RED runtimes you need to manage.

## Key Advantages of the FlowFuse Approach

1. **Enterprise-First Design:**
   FlowFuse is built specifically for mission-critical business applications where reliability isn't optional.
2. **True Team Collaboration:**
   FlowFuse enables organizations to reliably deliver Node-RED applications in a continuous, collaborative and secure manner, supporting team-based development from the ground up.
3. **Flexible Deployment Options:**
   Whether you need cloud, on-premises, or hybrid deployment, FlowFuse adapts to your infrastructure requirements without artificial constraints.
4. **Mature, Battle-Tested Ecosystem:**
   Built on Node-RED's proven foundation, FlowFuse leverages years of community development and real-world industrial deployment experience.

## Evaluating Your Automation Strategy

As the automation landscape evolves, consider these key factors when choosing or re-evaluating your platform:

**Cost Transparency**: Can you clearly understand and predict your automation costs as you scale?

**Business Focus**: Is your platform designed for enterprise requirements, or adapted from simpler use cases?

**Team Support**: Does your solution enable effective collaboration across your organization?

**Long-term Stability**: Is your chosen platform built to handle the complexity and scale of business operations?

## The FlowFuse Advantage

FlowFuse stands out because we've built our platform specifically for business automation challenges:

- **Predictable, business-friendly pricing** that grows with your needs
- **Industrial-grade reliability** for mission-critical applications
- **Enterprise security and compliance** built in from day one
- **Professional support** that understands business requirements

## Ready to Experience the Difference?

While other platforms adapt consumer tools for business use, FlowFuse was designed from the ground up for enterprise automation needs.

A free trial is available for FlowFuse Cloud, and you can also run FlowFuse locally, docker-based, or in Kubernetes.

Experience automation without the complexity of execution counting or artificial limitations. Discover how FlowFuse can support your business's growth with transparent, scalable solutions.

---

*Ready to get started? [Explore FlowFuse today](https://flowfuse.com) and see why businesses choose purpose-built automation platforms.*


# FlowFuse's New Database: The Easiest Way to Store Industrial IoT Data

FlowFuse recently introduced a [beta release](https://flowfuse.com/handbook/engineering/releases/#beta-release) built-in database service to their platform, making it easier than ever to store Industrial IoT data. In a typical setup, you would need to provision a database, manage connection strings and credentials, configure nodes, and handle security settings. The goal of this new feature is to simplify or even eliminate those steps entirely. In this article, you will learn how it works and how to get started.

## Getting Started

FlowFuse Tables is available for Enterprise users. If you do not have an Enterprise FlowFuse account and are interested in trying it out, [contact us](https://flowfuse.com/contact-us/) to get started.

### Step 1: Enable the Database in Your Project

Once the database feature is active on your account, the first step is to create a database instance for your team to use.

1. Log in to your FlowFuse platform.
2. In the navigation menu on the left, select the Tables option.
3. On the next screen, you will be prompted to "Choose which Database you'd like to get started with."
4. Currently, only Managed PostgreSQL is available. Click on Managed PostgreSQL to proceed.

![FlowFuse Tables](https://flowfuse.com/blog/2025/08/images/tables.png){dataZoomable=""}*FlowFuse Tables*

After you make your selection, FlowFuse will begin provisioning your dedicated database in the background. This process typically takes only a few moments.

Once the provisioning is complete, you will see two tabs in the Tables section:

- **Explorer** – Allows you to manage your tables through the user interface. You can create tables, add columns, and view stored data.

![FlowFuse Tables: Explorer Tab](https://flowfuse.com/blog/2025/08/images/tables-explorer.png){dataZoomable=""}*FlowFuse Tables: Explorer Tab*

- **Credentials** – Provides the database connection details such as host, port, username, and password. These credentials allow you to access the FlowFuse-managed database from outside FlowFuse as well.

![FlowFuse Tables: Credentials Tab](https://flowfuse.com/blog/2025/08/images/tables-credentials.png){dataZoomable=""}*FlowFuse Tables: Credentials Tab*

### Step 2: Create Your First Table

With your database instance provisioned, you can now create a table to start storing data.

FlowFuse offers two ways to create a table:

#### Option 1: Using the Table Explorer (UI)

Navigate to the Explorer tab under the Tables section.

1. Click the &#x2A;*+** button.
2. A form will slide in from the right side of the screen.
3. In the first input field, enter the name of your table.
4. Click Add New Column to start defining the structure of your table:
   - Column Name: Enter the name of the column.
   - Type: Select the appropriate data type (e.g., text, bigint, boolean).
   - Default: Check this if you want to set a default value for the column and Once checked, enter the default value in the input field that appears next.
   - Nullable: Check this if the column can contain empty (null) values.

![Interface for creating FlowFuse tables](https://flowfuse.com/blog/2025/08/images/create-table.png){dataZoomable=""}*Interface for creating FlowFuse tables*

5. Click Save once your columns are defined.

#### Option 2: Using SQL via the Query Node

If you prefer writing raw SQL or need more control over your table structure, you can use the Query node in Node-RED.

1. Go to your FlowFuse instance where you plan to build the flow and use this table.
2. Once you're in the Node-RED editor, look at the left-side node palette. You will find the Query node under the FlowFuse category.

![FlowFuse Query Node](https://flowfuse.com/blog/2025/08/images/query-node.png){dataZoomable=""}*FlowFuse Query Node*

3. Drag the Query node into your flow.

> The Query node uses standard SQL syntax and is pre-configured to connect to your FlowFuse-managed database automatically, you do not need to manually enter any database credentials when working inside a FlowFuse Node-RED instance.

4. Double-click the Query node and write your SQL command in the Query field.

Note: Table names and column names are case-sensitive in SQL when using certain databases like PostgreSQL. To avoid unexpected errors, it is recommended to wrap them in double quotes in your queries.:

For example:

```sql
CREATE TABLE "maintenance_tasks" (
  "id" SERIAL PRIMARY KEY,
  "title" TEXT NOT NULL,
  "description" TEXT,
  "assigned_to" TEXT NOT NULL,
  "due_date" DATE NOT NULL,
  "status" TEXT NOT NULL CHECK ("status" IN ('pending', 'in_progress', 'completed')),
  "priority" TEXT NOT NULL CHECK ("priority" IN ('low', 'medium', 'high'))
);
```

> If you want to send the SQL query dynamically at runtime, you can pass it through `msg.query` instead of hardcoding it in the node configuration.

5. Add an Inject node to trigger the query and optionally connect a Debug node to see the output.
6. Deploy and click the inject button to create the table.

### Step 3: Performing Operations with Your Table

Once your table is ready, you can start interacting with it using the **Query** node. This node allows you to run SQL queries directly, whether it is inserting new data, retrieving records, updating rows, or deleting entries. You can perform all standard operations just as you would with the other database nodes. For this demonstration, you will see how to insert data into your table.

> For a complete walkthrough of CRUD operations, you can try out the flow provided at the end of this guide.

#### Inserting a New Record

1. In your Node-RED editor, drag a **Query** node from the FlowFuse category.
2. Add an **Inject** node.
3. Drag a Change node and place it between the Inject and **Query** nodes. Connect the Inject node to the Change node, and then connect the Change node to the Query node. Double-click the Change node and configure the following properties based on your SQL query requirements. For example:
   - `msg.title` = `"Check motor status"`
   - `msg.description` = `"Routine check of motor and related sensors"`
   - `msg.assigned_to` = `"technician_1"`
   - `msg.due_date` = `"2025-08-10"`
   - `msg.status` = `"pending"`
   - `msg.priority` = `"medium"`
4. Double-click the Query node and write the SQL command in the **Query** field, For example:

```mustache
INSERT INTO "maintenance_tasks" (
  "title",
  "description",
  "assigned_to",
  "due_date",
  "status",
  "priority"
) VALUES (
  {{{msg.title}}},
  {{{msg.description}}},
  {{{msg.assigned_to}}},
  {{{msg.due_date}}},
  {{{msg.status}}},
  {{{msg.priority}}}
);
```

> This node uses the [Mustache template system](https://github.com/janl/mustache.js){rel="&#x22;nofollow&#x22;"} to dynamically generate queries based on message properties, using the `{{{ msg.property }}}` syntax.
>
> While convenient for quick testing and prototyping, this method is **not recommended for production use**. For better reliability and maintainability, consider using parameterized queries, for that follow [Using Parameters in Your Queries](https://flowfuse.com/#using-parameters-in-your-queries).

5. Optionally, connect a **Debug** node to the output of the Query node to inspect the result.
6. Deploy the flow and click the **Inject** button to execute the query.

Upon a successful insert operation, the Query node will output a `msg.payload` containing an empty array, and a `msg.pgsql` object that includes the executed command and a `rowCount` indicating the number of rows affected.

For update or delete operations, the behavior is the same. For select operations, the `msg.payload` will contain an array of the returned rows.

### Using Parameters in Your Queries

As mentioned earlier, placing Mustache-style strings directly into SQL queries is not considered a best practice. Instead, you should use parameterized queries to keep your queries cleaner, more reliable, and easier to maintain while following best practices.

The FlowFuse Query node supports both **numbered parameters** and **named parameters**, making your SQL queries more flexible, secure, and reusable.

#### Option 1: Numbered Parameters

Numbered parameters let you define placeholders in the SQL string and then pass actual values through `msg.params` as an array.

1. Drag an **Inject** node.
2. Drag a **Change** node and set properties based on your SQL command requirements. For example:
   - Set `msg.payload.priority` to 'high'
   - Set `msg.payload.status` to 'pending'
3. Add a **Change** node and set `msg.params` to `[msg.payload.priority, msg.payload.status]`.
4. Add a **Query** node and write an SQL query with numbered parameters. For example:

```sql
SELECT * FROM "maintenance_tasks"
WHERE "priority" = $1 AND "status" = $2;
```

5. Optionally, add a **Debug** node to view the output.
6. Connect the Inject node to the Change node that sets the payload values, then connect it to another Change node that sets the query parameters. Next, connect it to the Query node, and finally connect the Query node to the Debug node.
7. Deploy the flow and trigger the Inject node.

This query will retrieve rows where `priority` and `status` match the specified values. When you click the Inject node, the actual values from `msg.params` will be passed into the placeholders `$1` and `$2`.

#### Option 2: Named Parameters

Named parameters allow you to reference values by name using a dollar prefix (e.g., `$status`) in your SQL query. The actual values are passed using `msg.queryParameters` as an object.

1. Drag an **Inject** node.
2. Drag a **Change** node and set properties based on your SQL command requirements. For example:
   - Set `msg.payload.id` to 1
   - Set `msg.payload.status` to "in\_progress"
3. Add another **Change** node and set `msg.queryParameters` to `{}`. Then add the following rules:
   - Set `msg.queryParameters.id` to `msg.payload.id`
   - Set `msg.queryParameters.status` to `msg.payload.status`
4. Add a **Query** node and write the SQL query using named parameters. For example:
   ```sql
   UPDATE "maintenance_tasks"
   SET "status" = $status
   WHERE "id" = $id;
   ```
5. Optionally, add a **Debug** node to view the output.
6. Connect the Inject node to the Change node that sets the payload values, then connect it to another Change node that sets the query parameters. Next, connect it to the Query node, and finally connect the Query node to the Debug node.
7. Deploy the flow and click the **Inject** button to trigger the update.

When the flow runs, the values in `msg.queryParameters` will replace `$status` and `$id` in the SQL statement, ensuring that your queries are dynamic, readable, and secure.

The Node-RED flow provided below demonstrates a complete set of database interactions. It covers table creation, all standard CRUD (Create, Read, Update, Delete) operations, and includes examples of how to use both numbered and named parameters.

::render-flow{:height='300'}
```json
[{"id":"1b32d4c878aae3be","type":"debug","z":"fa9da3f45f949067","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":470,"y":420,"wires":[]},{"id":"59e4b997235b486f","type":"group","z":"fa9da3f45f949067","name":"","style":{"label":true},"nodes":["891c7f50df99de42","6b0630c1101be59c","35eda0b6c690e85f","d638990b04e75f73","0e0bdc881d4ff5e9","8f66f27f4fe5a3b1","5c2da859792c16fa"],"x":54,"y":239,"w":532,"h":222},{"id":"891c7f50df99de42","type":"inject","z":"fa9da3f45f949067","g":"59e4b997235b486f","name":"","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":150,"y":320,"wires":[["6b0630c1101be59c"]]},{"id":"6b0630c1101be59c","type":"tables-query","z":"fa9da3f45f949067","g":"59e4b997235b486f","name":"Create Table","query":"CREATE TABLE \"maintenance_tasks\" (\n  \"id\" SERIAL PRIMARY KEY,\n  \"title\" TEXT NOT NULL,\n  \"description\" TEXT,\n  \"assigned_to\" TEXT NOT NULL,\n  \"due_date\" DATE NOT NULL,\n  \"status\" TEXT NOT NULL CHECK (\"status\" IN ('pending', 'in_progress', 'completed')),\n  \"priority\" TEXT NOT NULL CHECK (\"priority\" IN ('low', 'medium', 'high'))\n);\n\n","split":false,"rowsPerMsg":1,"x":310,"y":320,"wires":[["35eda0b6c690e85f"]]},{"id":"35eda0b6c690e85f","type":"debug","z":"fa9da3f45f949067","g":"59e4b997235b486f","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":490,"y":320,"wires":[]},{"id":"d638990b04e75f73","type":"comment","z":"fa9da3f45f949067","g":"59e4b997235b486f","name":"Hardcode query within node","info":"","x":200,"y":280,"wires":[]},{"id":"0e0bdc881d4ff5e9","type":"comment","z":"fa9da3f45f949067","g":"59e4b997235b486f","name":"Dynamically passing query","info":"","x":190,"y":380,"wires":[]},{"id":"8f66f27f4fe5a3b1","type":"inject","z":"fa9da3f45f949067","g":"59e4b997235b486f","name":"","props":[{"p":"query","v":"SELECT * FROM \"maintenance_tasks\";","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":150,"y":420,"wires":[["5c2da859792c16fa"]]},{"id":"5c2da859792c16fa","type":"tables-query","z":"fa9da3f45f949067","g":"59e4b997235b486f","name":"SELECT","query":"","split":false,"rowsPerMsg":1,"x":300,"y":420,"wires":[["1b32d4c878aae3be"]]},{"id":"98f1c134581e0cdc","type":"group","z":"fa9da3f45f949067","name":"CRUD with Named Parameters","style":{"label":true},"nodes":["a70b79e2d1963518","8a617977438aedd1","e725fca338bfc763","ef5cde3b2e4ae6e5","ae071cf83947c204","26de341301b5378b","d1c2458ddef51e8f","eb407128caea1c2f","0b192c85faaee996","8db1c228e1b464fd","0ad1449ee792b623","9a81c88433626bf7","67ad3eddd7920547","7b5e3e5014ba62cb","028bd98bdcf55a8a","d12e44a1eefb3f6e","7b7c3b3586c57b6d","a3f58edc29712b75","e5a71b865a80248c","d6cbc55c66a02e36","6bab0e344178ed4a"],"x":54,"y":479,"w":912,"h":262},{"id":"a70b79e2d1963518","type":"inject","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"Insert","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":150,"y":580,"wires":[["7b5e3e5014ba62cb"]]},{"id":"8a617977438aedd1","type":"tables-query","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"Insert","query":"INSERT INTO \"maintenance_tasks\" (\n  \"title\",\n  \"description\",\n  \"assigned_to\",\n  \"due_date\",\n  \"status\",\n  \"priority\"\n) VALUES (\n  $title,\n  $description,\n  $assigned_to,\n  $due_date,\n  $status,\n  $priority\n);\n","split":false,"rowsPerMsg":1,"x":730,"y":580,"wires":[["e725fca338bfc763"]]},{"id":"e725fca338bfc763","type":"debug","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":870,"y":580,"wires":[]},{"id":"ef5cde3b2e4ae6e5","type":"tables-query","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"Update","query":"UPDATE \"maintenance_tasks\"\nSET \"status\" = $status\nWHERE \"id\" = $id;\n","split":false,"rowsPerMsg":1,"x":740,"y":660,"wires":[["26de341301b5378b"]]},{"id":"ae071cf83947c204","type":"change","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"","rules":[{"t":"set","p":"queryParameters","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"queryParameters.id","pt":"msg","to":"payload.id","tot":"msg"},{"t":"set","p":"queryParameters.status","pt":"msg","to":"payload.status","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":660,"wires":[["ef5cde3b2e4ae6e5"]]},{"id":"26de341301b5378b","type":"debug","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":870,"y":660,"wires":[]},{"id":"d1c2458ddef51e8f","type":"inject","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"Update","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":150,"y":660,"wires":[["028bd98bdcf55a8a"]]},{"id":"eb407128caea1c2f","type":"tables-query","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"SELECT","query":"SELECT * FROM \"maintenance_tasks\"\nWHERE \"priority\" = $priority AND \"status\" = 'pending';\n","split":false,"rowsPerMsg":1,"x":740,"y":620,"wires":[["8db1c228e1b464fd"]]},{"id":"0b192c85faaee996","type":"change","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"","rules":[{"t":"set","p":"queryParameters","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"queryParameters.priority","pt":"msg","to":"payload.priority","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":620,"wires":[["eb407128caea1c2f"]]},{"id":"8db1c228e1b464fd","type":"debug","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":870,"y":620,"wires":[]},{"id":"0ad1449ee792b623","type":"inject","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"SELECT","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":160,"y":620,"wires":[["9a81c88433626bf7"]]},{"id":"9a81c88433626bf7","type":"change","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"","rules":[{"t":"set","p":"payload.priority","pt":"msg","to":"high","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":350,"y":620,"wires":[["0b192c85faaee996"]]},{"id":"67ad3eddd7920547","type":"change","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"","rules":[{"t":"set","p":"queryParameters","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"queryParameters.title","pt":"msg","to":"payload.title","tot":"msg"},{"t":"set","p":"queryParameters.description","pt":"msg","to":"payload.description","tot":"msg"},{"t":"set","p":"queryParameters.assigned_to","pt":"msg","to":"payload.assigned_to","tot":"msg"},{"t":"set","p":"queryParameters.due_date","pt":"msg","to":"payload.due_date","tot":"msg"},{"t":"set","p":"queryParameters.status","pt":"msg","to":"payload.status","tot":"msg"},{"t":"set","p":"queryParameters.priority","pt":"msg","to":"payload.priority","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":580,"wires":[["8a617977438aedd1"]]},{"id":"7b5e3e5014ba62cb","type":"change","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"","rules":[{"t":"set","p":"payload.title","pt":"msg","to":"Replace air conditioner filter","tot":"str"},{"t":"set","p":"payload.description","pt":"msg","to":"The air filter in the main office needs to be replaced to maintain air quality.","tot":"str"},{"t":"set","p":"payload.assigned_to","pt":"msg","to":"jdoe","tot":"str"},{"t":"set","p":"payload.due_date","pt":"msg","to":"2025-08-15","tot":"str"},{"t":"set","p":"payload.status","pt":"msg","to":"pending","tot":"str"},{"t":"set","p":"payload.priority","pt":"msg","to":"high","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":320,"y":580,"wires":[["67ad3eddd7920547"]]},{"id":"028bd98bdcf55a8a","type":"change","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"","rules":[{"t":"set","p":"payload.id","pt":"msg","to":"1","tot":"num"},{"t":"set","p":"payload.status","pt":"msg","to":"in_progress","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":320,"y":660,"wires":[["ae071cf83947c204"]]},{"id":"d12e44a1eefb3f6e","type":"tables-query","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"Delete","query":"DELETE FROM \"maintenance_tasks\"\nWHERE \"id\" = $id;\n","split":false,"rowsPerMsg":1,"x":730,"y":700,"wires":[["a3f58edc29712b75"]]},{"id":"7b7c3b3586c57b6d","type":"change","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"","rules":[{"t":"set","p":"queryParameters","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"queryParameters.id","pt":"msg","to":"payload.id","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":700,"wires":[["d12e44a1eefb3f6e"]]},{"id":"a3f58edc29712b75","type":"debug","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":870,"y":700,"wires":[]},{"id":"e5a71b865a80248c","type":"inject","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"DELETE","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":160,"y":700,"wires":[["d6cbc55c66a02e36"]]},{"id":"d6cbc55c66a02e36","type":"change","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"","rules":[{"t":"set","p":"payload.id","pt":"msg","to":"2","tot":"num"}],"action":"","property":"","from":"","to":"","reg":false,"x":330,"y":700,"wires":[["7b7c3b3586c57b6d"]]},{"id":"6bab0e344178ed4a","type":"comment","z":"fa9da3f45f949067","g":"98f1c134581e0cdc","name":"Named Parameters","info":"","x":170,"y":520,"wires":[]},{"id":"7d584a17652f6545","type":"group","z":"fa9da3f45f949067","name":"Example flow: numbered parameters","style":{"label":true},"nodes":["c68690d2546f65cf","eb65c1a44ae25dd7","f38fed90c8e1f2f6","2b9e486cca212636","f492d66aa25e20aa"],"x":54,"y":759,"w":672,"h":122},{"id":"c68690d2546f65cf","type":"comment","z":"fa9da3f45f949067","g":"7d584a17652f6545","name":"Numbered Parameters","info":"","x":180,"y":800,"wires":[]},{"id":"eb65c1a44ae25dd7","type":"function","z":"fa9da3f45f949067","g":"7d584a17652f6545","name":"function 3","func":"msg.params = {}\nmsg.params = [msg.payload.title, msg.payload.description, msg.payload.assigned_to, msg.payload.due_date, msg.payload.status, msg.payload.priority]\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":320,"y":840,"wires":[["2b9e486cca212636"]]},{"id":"f38fed90c8e1f2f6","type":"inject","z":"fa9da3f45f949067","g":"7d584a17652f6545","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"title\":\"Replace air conditioner filter\",\"description\":\"The air filter in the main office needs to be replaced to maintain air quality.\",\"assigned_to\":\"jdoe\",\"due_date\":\"2025-08-15\",\"status\":\"pending\",\"priority\":\"high\"}","payloadType":"json","x":150,"y":840,"wires":[["eb65c1a44ae25dd7"]]},{"id":"2b9e486cca212636","type":"tables-query","z":"fa9da3f45f949067","g":"7d584a17652f6545","name":"Insert","query":"INSERT INTO \"maintenance_tasks\" (\n  \"title\",\n  \"description\",\n  \"assigned_to\",\n  \"due_date\",\n  \"status\",\n  \"priority\"\n) VALUES (\n  $1, $2, $3, $4, $5, $6\n);\n","split":false,"rowsPerMsg":1,"x":490,"y":840,"wires":[["f492d66aa25e20aa"]]},{"id":"f492d66aa25e20aa","type":"debug","z":"fa9da3f45f949067","g":"7d584a17652f6545","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":630,"y":840,"wires":[]},{"id":"53b4963ef005eadf","type":"global-config","env":[],"modules":{"@flowfuse/nr-tables-nodes":"0.1.0"}}]
```
::

## Wrapping Up

You've now learned how to leverage FlowFuse Tables to simplify database management in your Industrial IoT projects. Here's what you've accomplished:

- **Provisioned** a managed PostgreSQL database with zero configuration overhead
- **Created tables** using both the intuitive UI and flexible SQL approach
- **Executed queries** safely using parameterized queries for production-ready flows
- **Performed CRUD operations** with the versatile Query node

The combination of FlowFuse Tables and the built-in [MQTT broker](https://flowfuse.com/blog/2024/10/announcement-mqtt-broker/) eliminates the complexity of managing external database and messaging infrastructure, letting you focus on building automation solutions rather than wrestling with DevOps.

Ready to see how FlowFuse Tables can accelerate your next industrial project? [Book a demo with our team](https://flowfuse.com/book-demo/) to explore the full platform capabilities.

*Next up: We'll dive into Query node advanced features including backpressure handling and streaming large datasets, essential techniques for high-volume industrial applications.*


# Winning Through Open-Source Software in Manufacturing Digitalization

The manufacturing sector is in an interesting situation. It's caught between a
future with immense promise and a present with high complexity. The promised ROI
of digital transformation (DX) is into the
[trillions of dollars](https://www.marketresearchfuture.com/reports/digital-transformation-in-manufacturing-market-32040){rel="&#x22;nofollow&#x22;"}
globally over the next decade. For manufacturers, this is more than just an
opportunity for incremental improvement; it is a fundamental shift to
competitiveness.

Yet, on the other hand, a starkly different narrative is heard from the factory
floor. Despite the commitment of many IT and OT teams, paired with colossal
investment, the path to digitalization is proving to be unexpectedly slow. About
70% of digital transformation projects are (self-reported!)
[considered failures](https://www.myhubintranet.com/digital-transformation-statistics/){rel="&#x22;nofollow&#x22;"}.
Falling short of their objectives and failing to deliver the promised return on
investment (ROI).

To break this impasse a strategic shift and pivot will be needed, industrial IT
and OT need a decisive pivot to open-source software (OSS). With its core
principles of collaboration, transparency, and interoperability, manufacturers
can systematically remove barriers that have slowed their DX. Open source
provides the tools and the philosophy necessary to acquire and transport data
more effectively, build powerful analytics and interaction applications that
deliver real ROI, and, most of all, escape vendor lock-in.

## The Digitalization Paradox in Manufacturing

The economic case for digital transformation in manufacturing is unequivocal and
immense. The global digital transformation market, valued at nearly [[]{.katex-mathml}[[[]{.strut style="height:1em;vertical-align:-0.25em;"}[1]{.mord}[t]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[i]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[i]{.mord.mathnormal}[o]{.mord.mathnormal}[nin]{.mord.mathnormal}[2020]{.mord}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[i]{.mord.mathnormal}[s]{.mord.mathnormal}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[or]{.mord.mathnormal style="margin-right:0.0278em;"}[ec]{.mord.mathnormal}[a]{.mord.mathnormal}[s]{.mord.mathnormal}[t]{.mord.mathnormal}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[t]{.mord.mathnormal}[o]{.mord.mathnormal}[b]{.mord.mathnormal}[e]{.mord.mathnormal}[\[]{.mopen}[o]{.mord.mathnormal}[v]{.mord.mathnormal style="margin-right:0.0359em;"}[er]{.mord.mathnormal style="margin-right:0.0278em;"}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 2.7 trillion by 2026]\(<https://www.themanufacturer.com/articles/digital-transformation-in-manufacturing-the-challenges/>{rel="&#x22;nofollow&#x22;"}).
This growth is driven by the operational benefits; the primary motivators for
these investments are to achieve greater operational efficiency (cited by 40% of
executives), a faster time-to-market for new products (36%), and an improved
customer experience (35%).

To understand the paradox, one must dissect why manufacturing initiatives fail.
These challenges are connected with one-another, and are symptom from more
systemic issues. Financial constraints and ROI, particularly high initial costs
for hardware, software, and integration, coupled with pressure for rapid ROI,
create a catch-22. DX is now viewed as a cost center rather than a source of
operational improvement and thus ROI. A lack of qualified workers and in-house
skills, especially in IT, is another roadblock. With manufacturing competing for
talent with tech and finance. Then there’s legacy systems, where factory floors
have old, incompatible machinery and systems, making upgrading or retrofitting
this "rigid infrastructure" costly and complex, often stalling or killing
projects. Finally, cybersecurity fears arise from increased connectivity in
factories, expanding the attack surface and making the implementation of robust
and costly cybersecurity solutions complex, especially for SMEs.

## The Iron Grip of Proprietary Systems and Vendor Lock-In

The challenges detailed in the earlier, stem from the same key issue – the
manufacturing industry's historical and continued reliance on a technological
paradigm built around closed, proprietary systems. This licensing model, which
was key in enabling the first wave of digital automation, has now become a
barrier. Its defining characteristic is vendor lock-in, a condition that
systematically stifles innovation, inflates licensing costs, and holds the
industrial sector as a whole back from progress.

Innovation has always driven industrial automation forward. The transition from
mechanical systems to electrical relay logic in the early 20th century, and then
to the maturing of Programmable Logic Controller (PLC) in the 1960s, transformed
the factory floor. PLCs, followed by Supervisory Control and Data Acquisition
(SCADA) and Distributed Control Systems (DCS), brought control, reliability, and
programmability to industrial processes. These technologies were the engines of
the Third Industrial Revolution. Industrial automation was leading the way in
what was possible with digital systems, and combining these systems with one
another in new ways. The manufacturers were driving innovation in the software
industry and gaining real momentous ROI.

Since the late seventies, software became a copywrightable good, and with a shift
happened mostly in traditional applications of the software – Vendor Lock-In.

Vendor lock-in is an economic and technical condition where a customer becomes
so dependent on a specific vendor's products and services that switching to an
alternative provider becomes prohibitively difficult or costly.

**With that, manufacturers used to lead the way three quarters into the 20th
century, now are stuck with their 21st-century digital ambitions.**

The traditional, vertically integrated model of industrial digitalization,
‘featuring’ vendor lock-in, is a critical hindrance currently. This paradigm now
showcases inflated costs, lack of innovation, interoperability issues, and a
skills gap. These issues have effectively made manufacturers followers rather
than leaders in the realm of software-aided business. To regain an edge a
fundamental shift is a requirement. This shift requires abandoning vertical
point-solutions and instead embracing a new technological foundation that is
inherently open, fostering interoperability, and freeing manufacturers from the
constraints of single-vendor control.

## DX with Open-Source Software

In contrast to the closed, proprietary software, the open-source variant offers
a fresh approach to creating and distributing software. Born from the need of
collaboration and transparency, open-source software (OSS) provides fundamentals
to break vendor lock-in once and for all.

In 1983, MIT programmer Richard Stallman, annoyed by the practice of withholding
source code, founded the Free Software Foundation. His goal was to create a
completely free (“Free” as in speech, and also “Free” as in beer) operating
system, establishing a philosophy built on the user's right to run, study,
modify, and redistribute software. In the late 1990s, this movement gained a
more pragmatic and business-friendly identity with the coining of the term "open
source".

The value proposition of OSS is great and shows up in four key points:

1. Cost-Effectiveness
2. High flexibility and extensibility
3. Cross-Industry collaboration
4. Stability and Strategic Control

To go over each, one by one.

The most immediate appeal of OSS is the absence of high upfront licensing fees.
OSS is not "free" when considering the total cost of ownership (TCO), which
includes implementation, integration, training, and support. The crucial
difference lies in where the money goes. With proprietary software, a large
portion of the budget is spent on license and maintenance fees that primarily
benefit the vendor. With OSS, that same capital can be reinvested into
activities that build direct value for the manufacturer.

Secondly, flexibility of software and freedom to extend it – the single most
powerful advantage of OSS. Because the source code is accessible, manufacturers
are no longer constrained by a vendor's limited feature set or development
roadmap. Anyone can propose changes that modify, adapt, and extend the software
to meet their operational needs. If a particular open-source tool doesn't
support a niche industrial protocol, the company has the option to build that
integration itself or hire a third party to do so. As these investments do not
provide an edge over competition, it’s almost always shared within the OSS
community – building libraries of open toolchains.

Extending on that; Cross-industry collaboration enables wildly different
use-cases with the same fundamental problems to resolve to apply their knowledge
and craft serving all other businesses. For example, database technology has
been perfected for decades by banking and trading companies to allow for atomic
transactions and durability of data of those transactions. These scalability
improvements have profound impact for manufacturing use-cases around the world,
helping out with compliance, track-and-trace, and more.

Finally, Long-Term Stability and Strategic Control is implicitly featured with
OSS. With proprietary software, a manufacturer is exposed to the business risks
of the vendor. If the vendor is acquired, goes out of business, or simply
decides to discontinue a product line, the manufacturer can be left with an
unsupported and obsolete system. With OSS, the code is publicly distributed and
cannot be withdrawn. Even if the original maintainers abandon a project, the
community, or the company itself, can "fork" the code and continue its
development. This provides a level of long-term stability and strategic control
over critical technology assets that is impossible to achieve in a
vendor-dependent relationship.

## Finale

The manufacturing industry faces a challenge with its digital transformation
efforts. A reliance on proprietary systems has contributed to an impasse where
investment does not always produce the expected results. This model,
characterized by vendor lock-in, can lead to higher costs and constraints on
innovation, causing manufacturers to lag in technology adoption.

To move forward, a different approach can be considered. Open-source software
(OSS) offers a model that addresses many of the barriers causing digital
transformation projects to fail. With OSS, companies can gain more strategic
control over their technology, redirect funds from licensing fees toward
in-house capabilities, and connect previously isolated systems. This allows a
manufacturer to shift from being a consumer of a vendor's technology to a
director of its own.

The conversation is therefore shifting from if manufacturing should adopt open
source, to how it can be implemented to improve operations and deliver a return
on investment. This transition presents new questions, but it is one that
companies do not have to approach on their own. At FlowFuse, we work with
manufacturers to navigate this change, and we would love to explain how an
open-source strategy can transform your factory of the future. Download our comprehensive whitepaper "[Open Source Software for Manufacturing](https://flowfuse.com/whitepaper/open-source-software-for-manufacturing/)," to learn how to transform your factory operations and secure a competitive edge.


# Orchestrating Virtual Power Plants: How Low-Code Platforms Bridge the Gap

Our electric grid is changing. For a century, it operated as a one-way street: large, centralized power plants generated electricity and pushed it downstream to homes and businesses. But today, that model is shifting. Rooftop solar panels, home batteries, and electric vehicles (EVs) are turning that one-way street into a dynamic, two-way intersection.

These technologies are known as &#x2A;*Distributed Energy Resources (DERs)**. They promise a cleaner, more resilient, and more flexible energy future. However, with that promise comes a challenge: how do we manage this growing web of distributed systems? How do we coordinate them to work seamlessly with the traditional grid? The answer lies in the concept of the &#x2A;*Virtual Power Plant (VPP).**

## What is a Virtual Power Plant?

A Virtual Power Plant isn’t a physical facility. It’s a **software-based system** that connects and orchestrates hundreds, sometimes thousands, of DERs into a unified energy asset. Think of it like a conductor of an orchestra: the conductor doesn’t play an instrument, but ensures that every musician plays at the right time and in harmony with the others.

Similarly, a VPP ensures that solar panels, batteries, EVs, and other devices respond to real-time energy conditions. It might tell a group of batteries to store excess solar power during the afternoon or instruct EVs to send power back to the grid during a peak evening demand spike. The goal is coordinated action that supports both local needs and broader grid stability.

## Why VPPs Have Been So Hard to Build

While the concept of a VPP is not new, the execution has long been a technical and operational struggle. At the heart of the problem is **integration**, getting disparate devices and systems to work together.

First, there's the **vendor lock-in problem**. You might buy a top-tier battery system, only to find it doesn't communicate with your solar inverter from another manufacturer. This limits functionality and undermines the value of your investment.

Second, there's the **manual integration nightmare**. Engineers often spend weeks writing custom code to onboard new devices, and they must do this over and over for each new asset. It’s time-consuming, expensive, and frustrating.

Third, the data you eventually collect typically comes in **inconsistent formats**, making it difficult to use without first cleaning and transforming it. Valuable time is lost in standardizing data before any control logic can be applied.

Finally, there's the **challenge of scale**. As the number and types of assets grow, so do the operational complexities. How do you securely update logic across thousands of devices? How do you ensure uptime and reliability? How do you onboard new assets without starting from scratch every time? Without a centralized management platform, these challenges quickly become overwhelming.

## Low-Code: The Universal Translator for the Grid

This is where **low-code platforms**, like **FlowFuse** built on **Node-RED**, come into play. They offer a powerful and accessible way to bridge the technical gap, without reinventing the wheel every time.

Using a low-code platform, an engineer can visually build flows and logic without needing to write large amounts of custom code. This approach dramatically accelerates development and reduces complexity.

For example, connecting to devices becomes as simple as dragging and dropping pre-built nodes. You can pull data from a solar panel using Modbus, a battery using a REST API, and even fetch weather forecasts, all within the same interface.

Once the data is collected, standardizing it is straightforward. JSON, CSV, Change, and function nodes allow you to reformat disparate data streams into a single, consistent structure that the VPP can understand.

Building logic is also visual. You can create rules like:
&#x2A;*“If the electricity price is high and the batteries are full, then send power to the grid.”**
Such logic is easy to build, read, and modify, even for teams that aren't deeply technical.

## FlowFuse: Scaling and Securing the VPP

Beyond integration, **FlowFuse** provides the centralized control and management layer that VPPs need to scale. It gives operators a **single dashboard** to deploy logic, monitor device health, and push updates, regardless of how large or geographically dispersed the device fleet is.

Need to onboard new assets? You can do it from the same platform, without custom scripts or separate tools. This is what makes it possible to scale from managing **100 devices to 10,000**, in a structured, reliable way.

FlowFuse is also designed with **industrial-grade security** and management capabilities, essential for critical infrastructure environments. Role-based access control, audit logs, and deployment workflows are all built in.

And importantly, FlowFuse supports **collaborative development**. No more siloed knowledge stuck with one engineer. Teams can work together in a controlled environment, making development faster and more sustainable.

This isn't just theoretical: [Energinet, Denmark's national transmission system operator, uses FlowFuse to govern real-time grid data pipelines across its energy network](https://flowfuse.com/customer-stories/energinet-streamlining-critical-infrastructure-data-management/), meeting the reliability standards required of critical infrastructure at national scale.

## Ready to Build Smarter Energy Systems?

Virtual Power Plants are the future of the energy grid, but building them without the right tools is slow, brittle, and expensive. Low-code platforms like **FlowFuse** change that. They offer a practical, scalable, and secure way to integrate DERs, manage fleet operations, and coordinate distributed energy like never before.

Ready to revolutionize your energy infrastructure? Start building your VPP with [FlowFuse's free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} or [Book a Demo](https://meetings-eu1.hubspot.com/michael-davis/round-robin-michael-omar-kasheef?utm_campa%5B%E2%80%A6%5D113138546=&utm_content=113138546&utm_source=hs_automation&uuid=67e4a958-c21e-4463-8eb4-647cc2386930){rel="&#x22;nofollow&#x22;"} to see how leading energy companies are orchestrating thousands of DERs with low-code automation.


# Pareto Chart & Diagram: What It Is, Formula & Examples

When defects, delays, downtime, and customer complaints all show up at once, most teams don't have the resources to fix everything, so they end up fixing whatever's loudest instead of whatever matters most. A Pareto chart fixes that: it sorts the noise from the handful of causes actually driving your losses.

## What Is a Pareto Chart?

A Pareto Chart is a decision-making tool that reveals which problems deserve immediate attention and which can wait. Based on the principle that roughly 80% of problems stem from 20% of causes, this visual tool transforms chaos into clarity. It shows manufacturing teams exactly where to focus their efforts for maximum impact.

Whether you call it a Pareto Chart, Pareto diagram, or Pareto analysis graph, this quality control tool serves the same purpose: helping you identify and prioritize the most impactful problems in your manufacturing process.

## What is the Pareto Principle ?

The Pareto Principle, discovered by Italian economist Vilfredo Pareto in 1896, reveals a universal truth: imbalance is the norm, not the exception. Pareto originally observed that 80% of Italy's land belonged to 20% of the population. This same pattern appears everywhere in manufacturing.

Think about your own facility. Chances are, most of your headaches come from a handful of root causes. A few machines cause most breakdowns. A small number of suppliers create most delays. A limited set of defect types generate most customer complaints. The Pareto Chart makes these hidden patterns visible, turning intuition into actionable data.

If you prefer video, watch this quick explainer to understand the Pareto Principle:

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: lsGwqk_agcQ
---
::

## Pareto Chart vs Pareto Diagram: What's the Difference?

You'll hear both terms used interchangeably in manufacturing, and they refer to the same tool. "Pareto Chart" is more common in North America, while "Pareto diagram" is frequently used in ISO standards and international quality documentation. Whether your team calls it a chart, diagram, or graph, the visualization combines bar charts with a cumulative line to reveal the vital few causes driving the majority of your problems.

### Pareto Chart Formula

Creating a Pareto diagram involves a straightforward calculation process. Here's the step-by-step formula approach:

**Step 1: Calculate Frequency or Impact**

First, count how many times each problem occurs (or calculate the cost/impact of each problem type).

```text
Frequency = Number of occurrences for each category
```

**Step 2: Calculate Total**

Add up all frequencies to get the total:

```text
Total = Sum of all frequencies
```

**Step 3: Calculate Individual Percentage**

For each category, calculate what percentage it represents of the total:

```text
Individual Percentage = (Category Frequency / Total) × 100
```

**Step 4: Calculate Cumulative Percentage**

Starting from the largest category, add percentages progressively:

```text
Cumulative Percentage = Sum of all previous percentages + Current percentage
```

:cta-image{alt="Arch Systems scales automation across complex manufacturing environments with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/arch-systems-book-demo.png"}

## What Does a Pareto Chart Show?

A Pareto diagram combines the best of both worlds, the immediate clarity of a bar graph with the cumulative insight of a line graph. Here's what makes it powerful:

- **The Bars Tell the Story**: Each vertical bar represents a problem category, arranged from tallest to shortest. The height shows frequency or impact. This simple arrangement immediately draws your eye to the biggest problems, no statistical knowledge required.
- **The Line Shows the Opportunity**: The cumulative percentage line climbs from left to right, showing the combined impact of addressing each problem. When this line starts to flatten, you've found your "vital few", the problems that, once solved, will transform your operation.
- **The Axes Frame the Decision**: The left axis measures actual occurrences, the right shows cumulative percentage, and the horizontal axis lists your problem categories. Together, they create a complete picture that anyone can understand and act upon.

## Pareto Real World Example

![Pareto diagram showing defect categories in manufacturing with bars for scratches, cracks, color issues, and other defects, alongside a cumulative percentage line.](https://flowfuse.com/blog/2025/08/images/pareto-chart-image.png){dataZoomable=""}&#x2A;Pareto diagram showing defect categories in manufacturing with bars for scratches, cracks, color issues, and other defects, alongside a cumulative percentage line.*

Look at this real Pareto diagram from a manufacturing facility. The bars show different types of defects found in one month, arranged from most common (scratches) to least common (other defects).

Here's the key insight: See where the orange line crosses the 80% mark? It happens after just three defect types, scratches, cracks, and color issues. This means:

- Fix these three problems → Eliminate 80% of all defects
- Ignore the other six for now → Save time and resources

Instead of trying to fix nine different problems, the team focuses on just three:

1. Why do scratches happen? (Maybe rough handling)
2. What causes cracks? (Could be temperature changes)
3. How to fix color issues? (Check supplier materials)

This simple focus typically cuts total defects by 60-70% in just a few months. That's the power of Pareto, work smarter, not harder.

## What is a Pareto chart (diagram) used for ?

1. **Quality Control**
   Smart manufacturers prioritize defects, not just track them. When teams break down defects into specific categories, particle contamination, dimensional variations, assembly errors, material flaws, each reveals different root causes requiring targeted solutions. An [Ishikawa (fishbone) diagram](https://flowfuse.com/blog/2026/07/ishikawa-fishbone-diagram/) is a quick way to surface those candidate causes before you rank them here.

The key is specificity. Generic "defect" tracking will not reveal actionable insights. Break them down into meaningful categories that point to specific improvement opportunities.

2. **Equipment Maintenance**
   Traditional maintenance schedules treat all equipment equally, but Pareto analysis reveals this approach wastes resources. Manufacturing studies show that bearing wear and sensor failures often account for nearly 50% of all equipment failure occurrences. By identifying which specific components cause the most downtime, teams can shift from time-based maintenance to condition monitoring on critical equipment.

The lesson: focus your predictive maintenance budget where failures hurt most.

3. **Supply Chain Intelligence**
   When supplier issues multiply, Pareto diagrams cut through the noise. Manufacturing teams tracking supplier-caused delays often discover that a small fraction of suppliers cause the majority of production stoppages. This data-driven insight enables targeted negotiations for backup agreements and buffer stock arrangements with critical suppliers.
4. **Safety Management**
   Safety teams using Pareto analysis on incident data typically find that specific operations or areas account for the majority of lost-time incidents. This focused view enables targeted ergonomic improvements and specialized training where they will prevent the most harm.

Safety resources are precious. Pareto diagrams ensure they go where they will have maximum impact.

5. **Cost Reduction**
   Not all problems cost the same. Frequency alone can mislead, a defect occurring frequently but costing little to fix might be less important than rare defects causing expensive customer line stops. Cost-weighted Pareto Charts often completely reverse improvement priorities, focusing teams on high-impact issues rather than high-frequency ones.

## Why Pareto Charts Matter Now More Than Ever

Manufacturing is more complex than ever, global supply chains, tight margins, and higher quality expectations mean every decision matters. Pareto charts cut analysis time from days to minutes: operators, engineers, and executives can read the same chart and reach the same conclusion without deep statistical knowledge.

Updated regularly, they also make progress visible and reveal longer-term strategy. If supplier-related problems keep topping the chart, it may signal the need to rethink sourcing. If equipment failures dominate month after month, that's your signal to invest in maintenance or automation before a small issue becomes a major disruption.

## Conclusion

In manufacturing, success isn't about solving every problem, it's about solving the right problems first. Pareto Charts cut through the noise to show you exactly where your efforts will deliver the greatest returns. By focusing on the vital few causes that drive the majority of your issues, you transform scattered firefighting into strategic improvement.

The beauty of Pareto analysis lies in its simplicity. No complex formulas, no statistical expertise required, just clear visual evidence that guides your team toward impact. Whether you're reducing defects, minimizing downtime, or cutting costs, the Pareto principle remains your compass: tackle the 20% that matters, and watch 80% of your problems disappear.

But knowing the principle and applying it in real-time are two different challenges. Modern manufacturing moves fast, and static charts built from monthly data reports can't keep pace. [FlowFuse](https://flowfuse.com) bridges this gap by connecting directly to your production systems, automatically collecting data, and generating dynamic Pareto diagrams that evolve as your operation does. See problems emerge before they escalate. Track improvements as they happen. Make decisions backed by live data, not outdated reports.

The first step is always the hardest, and the most important. Choose one persistent problem area this week. Gather the data. Build your first Pareto Chart. You'll be surprised how quickly priorities become obvious and how fast your team aligns around them.

Read next: [building interactive Pareto diagrams in FlowFuse](https://flowfuse.com/blog/2025/09/creating-pareto-chart/) that connect directly to your production systems.


# Building Historical Data Dashboard with FlowFuse Tables

In Industrial IoT, tracking data over time is crucial. Whether you’re monitoring temperature changes throughout the day, spotting machine downtime, or analyzing production trends across shifts, a historical data dashboard helps you see important patterns clearly.

This tutorial guides you through building such a dashboard using FlowFuse Tables. FlowFuse Tables currently provides a managed PostgreSQL database, a reliable and widely used system, which we will use throughout this tutorial to store time-series data.

## Why PostgreSQL for Time-Series Data?

You might wonder if PostgreSQL can efficiently handle large volumes of time-series data. The answer is yes, when configured properly. Without optimization, query performance can slow as data grows. However, by using techniques like batch inserts and smart indexing, PostgreSQL delivers fast and reliable access even at an industrial scale.

PostgreSQL is selected as the first database offering in FlowFuse Tables because it is flexible, reliable, and open source. It serves as a solid foundation for FlowFuse Tables. Whether your data comes from IIoT sensors or other sources, PostgreSQL is well equipped to handle it.

## Prerequisites

Before we begin, please ensure you have the following set up:

- A FlowFuse Enterprise account, as FlowFuse Tables is an exclusive Enterprise feature.
- The `@flowfuse/node-red-dashboard` package installed in your FlowFuse instance to create the user interface.
- The `node-red-contrib-moment` node installed for handling date and time operations within your flows.
- FlowFuse Tables configured for your FlowFuse Team with a managed PostgreSQL database.

If you are new to FlowFuse Tables, we highly recommend reading our [getting started guide](https://flowfuse.com/blog/2025/08/getting-started-with-flowfuse-tables/) to familiarize yourself with the basics.

## Creating an Optimized Database Schema

Our first step is to design a database table structured for both high-speed writes and efficient queries.

### Step 1: Design and Create the Table

We will create a single table to hold all our sensor data. The key is to use appropriate data types and indexes to ensure performance.

1. In your FlowFuse Node-RED instance, drag a **Query node** onto the canvas.
2. Configure the node with the following SQL statement to create the table and its indexes:

```sql
CREATE TABLE "sensor_readings" (
    "id" SERIAL PRIMARY KEY,
    "timestamp" TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    "sensor_id" VARCHAR(50) NOT NULL,
    "location" VARCHAR(100),
    "temperature" DECIMAL(5,2)
);

CREATE INDEX "idx_sensor_timestamp" ON "sensor_readings"("sensor_id", "timestamp" DESC);
```

**Schema Breakdown:**

- `TIMESTAMPTZ`: We use this data type to store timestamps with timezone information. This is critical for applications with sensors spread across different geographical locations, ensuring data is always consistent.
- **Index**: The composite index on `sensor_id` and `timestamp` (in descending order) is vital for query speed. It allows PostgreSQL to quickly locate and return results for a specific sensor while already ordering them from newest to oldest. This avoids expensive sorting when fetching the most recent readings for a given sensor.

> **Important:** The `DESC` in the composite index provides a significant performance boost for queries like:
>
> ```sql
> SELECT * 
> FROM sensor_readings
> WHERE sensor_id = 'sensor_01'
> ORDER BY timestamp DESC
> LIMIT 10;
> ```
>
> If you instead need results in chronological order, you could create an ascending index or let PostgreSQL reverse the order at query time.

3. To execute this one-time setup, connect an **Inject node** to the input of the **Query node** and a **Debug node** to its output.
4. Click **Deploy**, then click the button on the **Inject node** to create your table.

### Step 2: Storing Sensor Data Efficiently with Batch Inserts

Writing every single sensor reading to the database individually can create significant overhead and slow down performance. A much more efficient method is to "batch" readings together and write them in a single transaction.

Let's build a flow to simulate sensor data and batch-insert it.

1. Add an **Inject node** configured to repeat every **1 second** to simulate a continuous stream of data.
2. Connect it to a **Change node** that generates a simulated sensor reading. Configure it to set `msg.payload` using the following JSONata expression:

```json
    {
        "sensor_id": "sensor_01",
        "location": "Production Line A",
        "temperature": 20 + $random() * 5
    }
```

3. Add another **Change node** to add a precise timestamp to each reading.
   - Set `msg.payload.timestamp`
   - To the value type **timestamp**.
4. Add a **Function node*&#x2A; and name it &#x2A;*"Batch Accumulator"**. Paste the following JavaScript code into the node, it already includes inline comments explaining each step. This function will accumulate incoming readings in batches until the specified batch size is reached, and then creates the SQL query to perform batch inserts into the database.

```javascript
// Set the number of records to collect before triggering a batch insert
const batchSize = 100;

// Retrieve previously stored readings from context (or start with an empty array)
const readings = context.get('readings') || [];

// Add the new reading (from msg.payload) to the readings array
readings.push(msg.payload);

// Check if we have enough readings to perform a batch insert
if (readings.length >= batchSize) {

    // Generate parameter placeholders for each reading (4 fields per record)
    // Example: ($1, $2, $3, $4), ($5, $6, $7, $8), ...
    const values = readings.map((_, i) => 
        `($${i * 4 + 1}, $${i * 4 + 2}, $${i * 4 + 3}, $${i * 4 + 4})`
    ).join(',');

    // Build the SQL insert query with placeholders
    msg.query = `
        INSERT INTO sensor_readings
        (timestamp, sensor_id, location, temperature)
        VALUES ${values};
    `;

    // Flatten the readings into a single array of values matching the placeholders
    // For each reading, we pass: current timestamp, sensor_id, location, temperature
    msg.params = readings.flatMap(r => [
        new Date(),          // Or use r.timestamp if actual reading time is available
        r.sensor_id,
        r.location,
        r.temperature
    ]);

    // Clear stored readings in context now that they are being inserted
    context.set('readings', []);

    // Return the msg with the SQL query and parameters for execution
    return msg;
}

// If not enough readings collected yet, store them back into context
context.set('readings', readings);

// Do not send anything forward yet
return null;
```

5. Connect the output of the "Batch Accumulator" to a **Query node**. This node will receive the fully formed `msg.query` and execute the batch insert.
6. Deploy the flow. It will now collect 100 readings (over 100 seconds) and perform a single, highly efficient database write instead of 100 separate ones.

## Building the Interactive Dashboard

With data flowing into our database, let's create a user interface to query and visualize it.

### Step 3: Create an Interactive Time Range Selector

We'll start with a form that allows users to select a date, time, and duration to view.

1. Drag a **ui\_form** node onto the canvas. Create a new dashboard group for it and add the following form elements: :br![Form widget configuration showing date, time, and window duration fields](https://flowfuse.com/blog/2025/08/images/form-widget.png){dataZoomable=""}*Time Range Selector form configuration in Node-RED Dashboard*
2. Connect the output of the form to a **Change** node to format the input. Add the following rules in the Change node:
   - Set `msg.startDateTime` to the JSONata expression:
     ```json
     payload.start & "T" & payload.time & ":00"
     ```
   - Set `msg.windowMinutes` to the expression:
     ```json
     payload.window
     ```
3. Add a **Date/Time Formatter** node. This is crucial for handling timezones correctly. Configure it as follows:
   - **Input property:** `msg.startDateTime`
   - **Input timezone:** your local timezone, for example, `Asia/Kolkata`
   - **Output timezone:** `Etc/UTC` (to match the database `TIMESTAMPTZ` standard)
   - **Output property:** `msg.startDateTime`
   :br![Date/Time Formatter node configuration showing timezone conversion settings](https://flowfuse.com/blog/2025/08/images/moment.png){dataZoomable=""}*Configuring the Date/Time Formatter node to convert from local timezone to UTC*
4. Add another **Change** node to set the query parameters for the SQL query. Set `msg.params` to the following JSONata expression:
   ```text
   [
       msg.startDateTime,
       msg.windowMinutes & " minutes"
   ]
   ```
5. Connect this to a **Query** node with the following parameterized SQL, which fetches data for the selected time window:
   ```sql
   SELECT 
       "timestamp",
       "temperature"
   FROM "sensor_readings"
   WHERE "sensor_id" = 'sensor_01'
     AND "timestamp" >= $1::timestamptz
     AND "timestamp" < ($1::timestamptz + $2::interval) ORDER BY "timestamp" DESC;
   ```
6. Connect a **Debug** node after the Query node to test the flow.
7. Drag a **Switch** node onto the canvas and add a condition to check whether `msg.payload` is empty. Connect the output of the Query node to the Switch node.
8. Connect the output for the "empty" condition from the Switch node to a **Change** node that sets `msg.payload` to:
   ```text
   No data found for the selected time range.
   ```
9. Drag a **ui\_notification** node, select the appropriate UI group, and connect it to the output of the Change node.
10. Deploy the flow. On the dashboard, select a **date**, **time**, and **window** using the form. Verify in the debug panel that the correct data is returned, or that a notification appears if no data is found.

![Complete time range selector form](https://flowfuse.com/blog/2025/08/images/form-time-range-selector.png){dataZoomable=""}*Complete time range selector form*

### Step 4: Display the Data in a Chart

The final step is to visualize the query result.

1. Connect the output of the final **Query node** to a **ui\_chart** widget.
2. Configure the chart node:
   - Group: Create new group for chart.
   - Type: Line
   - X: Set to `timestamp` as a key.
   - Y: Set to `temperature` as a key.
   - Series: Set to "Temperature" as string.
3. Deploy the flow. Your complete historical data dashboard is now live, you can explore it and experiment with different time ranges to see the results.

:video{ariaLabel="historical data dashboard retrieving historical data nd displying it" autoPlay="true" height="1640" loop="true" muted="true" playsInline="true" preload="none" width="3024"}*Historical data dashboard retrieving and displaying historical data*

Below is the complete flow we built in this tutorial.

::render-flow{:height='300'}
```json
[{"id":"901337216b60b25a","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"e9a3b71d40addd8b","type":"group","z":"901337216b60b25a","name":"Create Table","style":{"label":true},"nodes":["48b1380ff7bfe716","44bb8750d961e415","4a3976e062b2ddd2"],"x":54,"y":59,"w":572,"h":82},{"id":"01137d02c4832962","type":"group","z":"901337216b60b25a","name":"Simulate Sensor and perform batch insert","style":{"label":true},"nodes":["e465d4328d9d42d9","50fb850e3e3db58e","b21d6dabf731e866","f8269cf412b4200f","96fdd4673919b0d2","04340ad3b984a2df"],"x":54,"y":159,"w":1092,"h":82},{"id":"89c860a27ff3db10","type":"group","z":"901337216b60b25a","name":"Historical data dashboard","style":{"label":true},"nodes":["f493229b28ac8c11","b9017676553dc100","322dee35a2d77015","f3ca555ef811453c","0cb8d32327a10533","b5dc2ed0fac07f02","f3bfdee87aab61f8","9481202eb7a507b6","159bd298de4a95d0"],"x":54,"y":259,"w":1612,"h":122},{"id":"68fbcdb03e3a5346","type":"group","z":"901337216b60b25a","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["4f24ab5b5628a1ba","fbf36a7b3c59461d"],"x":634,"y":59,"w":392,"h":82},{"id":"48b1380ff7bfe716","type":"inject","z":"901337216b60b25a","g":"e9a3b71d40addd8b","name":"","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":150,"y":100,"wires":[["44bb8750d961e415"]]},{"id":"44bb8750d961e415","type":"tables-query","z":"901337216b60b25a","g":"e9a3b71d40addd8b","name":"Create Table","query":"   CREATE TABLE \"sensor_readings\" (\n       \"id\" SERIAL PRIMARY KEY,\n       \"timestamp\" TIMESTAMPTZ NOT NULL DEFAULT NOW(),\n       \"sensor_id\" VARCHAR(50) NOT NULL,\n       \"location\" VARCHAR(100),\n       \"temperature\" DECIMAL(5,2)\n   );\n\n   CREATE INDEX \"idx_sensor_timestamp\" ON \"sensor_readings\"(\"sensor_id\", \"timestamp\" DESC);","split":false,"rowsPerMsg":1,"x":330,"y":100,"wires":[["4a3976e062b2ddd2"]]},{"id":"4a3976e062b2ddd2","type":"debug","z":"901337216b60b25a","g":"e9a3b71d40addd8b","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":520,"y":100,"wires":[]},{"id":"e465d4328d9d42d9","type":"inject","z":"901337216b60b25a","g":"01137d02c4832962","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":170,"y":200,"wires":[["96fdd4673919b0d2"]]},{"id":"50fb850e3e3db58e","type":"tables-query","z":"901337216b60b25a","g":"01137d02c4832962","name":"Query","query":"const batchSize = 100;\nconst readings = context.get('readings') || [];\n\nreadings.push(msg.payload);\n\nif (readings.length >= batchSize) {\n    // Prepare batch insert\n    const values = readings.map((_, i) => \n        `($${i*7+1}, $${i*7+2}, $${i*7+3}, $${i*7+4}, $${i*7+5}, $${i*7+6}, $${i*7+7})`\n    ).join(',');\n    \n    msg.query = `\n        INSERT INTO \"sensor_readings\"\n        (\"timestamp\", \"sensor_id\", \"location\", \"temperature\")\n        VALUES ${values}\n    `;\n    \n    msg.params = readings.flatMap(r => [\n        new Date(),\n        r.sensor_id,\n        r.location,\n        r.temperature,\n    ]);\n    \n    context.set('readings', []);\n    return msg;\n}\n\ncontext.set('readings', readings);\nreturn null;","split":false,"rowsPerMsg":1,"x":890,"y":200,"wires":[["f8269cf412b4200f"]]},{"id":"b21d6dabf731e866","type":"function","z":"901337216b60b25a","g":"01137d02c4832962","name":"Batch Accumulator","func":"// Set the number of records to collect before triggering a batch insert\nconst batchSize = 100;\n\n// Retrieve previously stored readings from context (or start with an empty array)\nconst readings = context.get('readings') || [];\n\n// Add the new reading (from msg.payload) to the readings array\nreadings.push(msg.payload);\n\n// Check if we have enough readings to perform a batch insert\nif (readings.length >= batchSize) {\n\n    // Generate parameter placeholders for each reading (4 fields per record)\n    // Example: ($1, $2, $3, $4), ($5, $6, $7, $8), ...\n    const values = readings.map((_, i) => \n        `($${i * 4 + 1}, $${i * 4 + 2}, $${i * 4 + 3}, $${i * 4 + 4})`\n    ).join(',');\n\n    // Build the SQL insert query with placeholders\n    msg.query = `\n        INSERT INTO sensor_readings\n        (timestamp, sensor_id, location, temperature)\n        VALUES ${values};\n    `;\n\n    // Flatten the readings into a single array of values matching the placeholders\n    // For each reading, we pass: current timestamp, sensor_id, location, temperature\n    msg.params = readings.flatMap(r => [\n        r.timestamp,\n        r.sensor_id,\n        r.location,\n        r.temperature\n    ]);\n\n    // Clear stored readings in context now that they are being inserted\n    context.set('readings', []);\n\n    // Return the msg with the SQL query and parameters for execution\n    return msg;\n}\n\n// If not enough readings collected yet, store them back into context\ncontext.set('readings', readings);\n\nreturn null;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":730,"y":200,"wires":[["50fb850e3e3db58e"]]},{"id":"f8269cf412b4200f","type":"debug","z":"901337216b60b25a","g":"01137d02c4832962","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1040,"y":200,"wires":[]},{"id":"96fdd4673919b0d2","type":"change","z":"901337216b60b25a","g":"01137d02c4832962","name":"Simulate Sensor","rules":[{"t":"set","p":"payload","pt":"msg","to":"{\t   \"sensor_id\": \"sensor_01\",\t   \"location\": \"Production Line A\",\t   \"temperature\": 20 + $random() * 5\t}","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":340,"y":200,"wires":[["04340ad3b984a2df"]]},{"id":"04340ad3b984a2df","type":"change","z":"901337216b60b25a","g":"01137d02c4832962","name":"Add timestamp","rules":[{"t":"set","p":"payload.timestamp","pt":"msg","to":"iso","tot":"date"}],"action":"","property":"","from":"","to":"","reg":false,"x":540,"y":200,"wires":[["b21d6dabf731e866"]]},{"id":"f493229b28ac8c11","type":"ui-chart","z":"901337216b60b25a","g":"89c860a27ff3db10","group":"92613690554d5bb9","name":"Historical Data Chart","label":"","order":1,"chartType":"line","category":"Temperature","categoryType":"str","xAxisLabel":"","xAxisProperty":"timestamp","xAxisPropertyType":"property","xAxisType":"time","xAxisFormat":"","xAxisFormatType":"ccc HH:mm","xmin":"","xmax":"","yAxisLabel":"","yAxisProperty":"temperature","yAxisPropertyType":"property","ymin":"","ymax":"","bins":10,"action":"replace","stackSeries":false,"pointShape":"circle","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"3600","removeOlderPoints":"","colors":["#0095ff","#ff0000","#ff7f0e","#2ca02c","#a347e1","#d62728","#ff9896","#9467bd","#c5b0d5"],"textColor":["#666666"],"textColorDefault":true,"gridColor":["#e5e5e5"],"gridColorDefault":true,"width":"12","height":8,"className":"","interpolation":"linear","x":1540,"y":300,"wires":[[]]},{"id":"b9017676553dc100","type":"ui-form","z":"901337216b60b25a","g":"89c860a27ff3db10","name":"","group":"b9e9762c81b55a05","label":"","order":1,"width":0,"height":0,"options":[{"label":"Start","key":"start","type":"date","required":true,"rows":null},{"label":"Time","key":"time","type":"time","required":true,"rows":null},{"label":"Window (minutes)","key":"window","type":"number","required":true,"rows":null}],"formValue":{"start":"","time":"","window":""},"payload":"","submit":"submit","cancel":"clear","resetOnSubmit":true,"topic":"topic","topicType":"msg","splitLayout":"","className":"","passthru":false,"dropdownOptions":[],"x":130,"y":300,"wires":[["322dee35a2d77015"]]},{"id":"322dee35a2d77015","type":"change","z":"901337216b60b25a","g":"89c860a27ff3db10","name":"","rules":[{"t":"set","p":"startDateTime","pt":"msg","to":"payload.start & \"T\" & payload.time & \":00\"","tot":"jsonata"},{"t":"set","p":"windowMinutes","pt":"msg","to":"payload.window","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":340,"y":300,"wires":[["0cb8d32327a10533"]]},{"id":"f3ca555ef811453c","type":"tables-query","z":"901337216b60b25a","g":"89c860a27ff3db10","name":"","query":"   SELECT \n       \"timestamp\",\n       \"temperature\"\n   FROM \"sensor_readings\"\n   WHERE \"sensor_id\" = 'sensor_01'\n     AND \"timestamp\" >= $1::timestamptz\n     AND \"timestamp\" < ($1::timestamptz + $2::interval) ORDER BY \"timestamp\" DESC;","split":false,"rowsPerMsg":1,"x":930,"y":300,"wires":[["f493229b28ac8c11","f3bfdee87aab61f8"]]},{"id":"0cb8d32327a10533","type":"moment","z":"901337216b60b25a","g":"89c860a27ff3db10","name":"","topic":"","input":"startDateTime","inputType":"msg","inTz":"Asia/Kolkata","adjAmount":0,"adjType":"days","adjDir":"add","format":"","locale":"en-US","output":"startDateTime","outputType":"msg","outTz":"ETC/UTC","x":540,"y":300,"wires":[["b5dc2ed0fac07f02"]]},{"id":"b5dc2ed0fac07f02","type":"change","z":"901337216b60b25a","g":"89c860a27ff3db10","name":"Set Params","rules":[{"t":"set","p":"params","pt":"msg","to":"[     msg.startDateTime,     msg.windowMinutes & \" minutes\"   ]","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":770,"y":300,"wires":[["f3ca555ef811453c"]]},{"id":"f3bfdee87aab61f8","type":"switch","z":"901337216b60b25a","g":"89c860a27ff3db10","name":"Is payload empty?","property":"payload","propertyType":"msg","rules":[{"t":"empty"}],"checkall":"true","repair":false,"outputs":1,"x":1110,"y":340,"wires":[["9481202eb7a507b6"]]},{"id":"9481202eb7a507b6","type":"change","z":"901337216b60b25a","g":"89c860a27ff3db10","name":"Notification Message","rules":[{"t":"set","p":"payload","pt":"msg","to":"No data found for the selected time range.","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":1320,"y":340,"wires":[["159bd298de4a95d0"]]},{"id":"159bd298de4a95d0","type":"ui-notification","z":"901337216b60b25a","g":"89c860a27ff3db10","ui":"afea04ce8735c0a6","position":"center center","colorDefault":true,"color":"#000000","displayTime":"3","showCountdown":true,"outputs":1,"allowDismiss":true,"dismissText":"Close","allowConfirm":false,"confirmText":"Confirm","raw":false,"className":"","name":"","x":1530,"y":340,"wires":[[]]},{"id":"4f24ab5b5628a1ba","type":"catch","z":"901337216b60b25a","g":"68fbcdb03e3a5346","name":"","scope":null,"uncaught":false,"x":720,"y":100,"wires":[["fbf36a7b3c59461d"]]},{"id":"fbf36a7b3c59461d","type":"debug","z":"901337216b60b25a","g":"68fbcdb03e3a5346","name":"debug 6","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":920,"y":100,"wires":[]},{"id":"92613690554d5bb9","type":"ui-group","name":"Historical Chart","page":"d03a38650bf3082f","width":"12","height":1,"order":2,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"b9e9762c81b55a05","type":"ui-group","name":"Form","page":"d03a38650bf3082f","width":"12","height":1,"order":1,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"afea04ce8735c0a6","type":"ui-base","name":"UI Name","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-control","ui-notification"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"icon","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":5,"showDisconnectNotification":true,"allowInstall":true},{"id":"d03a38650bf3082f","type":"ui-page","name":"Historical Data Dashboard","ui":"afea04ce8735c0a6","path":"/historical-data","icon":"home","layout":"grid","theme":"6d8bff5f3fded5c2","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":3,"className":"","visible":"true","disabled":"false"},{"id":"6d8bff5f3fded5c2","type":"ui-theme","name":"FF Theme","colors":{"surface":"#5046e5","primary":"#5046e5","bgPage":"#ffffff","groupBg":"#ffffff","groupOutline":"#d4d1ff"},"sizes":{"density":"default","pagePadding":"15px","groupGap":"15px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"a0dab2a5f9f4e3d2","type":"global-config","env":[],"modules":{"@flowfuse/nr-tables-nodes":"0.1.0","@flowfuse/node-red-dashboard":"1.26.0","node-red-contrib-moment":"5.0.0"}}]
```
::

## Conclusion

You have successfully built a historical data dashboard using FlowFuse Tables and Node-RED. By implementing efficient batch inserts and optimized query patterns, you have created a solution that is both powerful and scalable for demanding Industrial IoT environments.

With FlowFuse Tables now part of the platform, you can build complete industrial applications without juggling external databases or leaving the FlowFuse environment. FlowFuse is now a comprehensive data platform with the ability to collect, connect, transform, store, and visualize data. Combined with FlowFuse's enterprise features, team collaboration, version control, device management, and secure deployments, you have everything needed to take your IIoT projects from prototype to production within one integrated platform.

This means less complexity and faster time to value for your industrial data initiatives. Your historical dashboards, real-time monitoring, and OEE dashboards can all live in the same ecosystem, managed by the same team, with consistent security and governance controls. See where a historical view fits alongside the other [manufacturing dashboards](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/) running on the shop floor.

[Opto 22 customers already do this in the field](https://flowfuse.com/customer-stories/opto22-embraces-node-red/), collecting sensor data and control variables with Node-RED and storing it straight into a SQL database.

Ready to build your own time-series dashboard? [Get started with FlowFuse Tables](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} or [explore our industrial blueprints](https://flowfuse.com/blueprints/)


# Query Your Database with Natural Language Using FlowFuse Expert

Getting data from your database used to mean writing SQL queries. Not anymore. The FlowFuse Expert now lets you ask for what you want in plain English and automatically generates the SQL for you in query node.

## Removing Technical Barriers

Industrial operations generate massive amounts of valuable data from sensors, equipment, and PLCs. This data can drive optimization and cost savings, but extracting insights often requires SQL skills that not every team member possesses.

FlowFuse already makes it simple to connect to databases and build data flows using its Query nodes. However, the need to manually write SQL queries has remained a significant barrier for many users.

To address this, FlowFuse continues its mission of making industrial automation accessible to everyone, regardless of coding expertise. Features like the FlowFuse Expert have already reduced complexity by enabling users to create custom functions and UI components using natural language.

With FlowFuse [2.21](https://flowfuse.com/blog/2025/08/flowfuse-release-2-21/), this ease of use extends to database queries as well. Users can now ask questions in plain English and have SQL automatically generated, removing the last major hurdle and empowering a broader audience to gain actionable insights quickly and easily.

## Getting Started

Let's see how this works with a practical example. This feature combines two FlowFuse components:

- **FlowFuse Tables** provides the database connectivity and Query nodes
- **FlowFuse Expert** adds the natural language processing capability that converts plain English into SQL

Before you begin, make sure FlowFuse Tables is activated in your FlowFuse team. For more information, refer to [Getting Started with FlowFuse Tables](https://flowfuse.com/blog/2025/08/getting-started-with-flowfuse-tables/). Then, import the following flow and deploy it to create a `sensor_readings` table for practice:

::render-flow{:height='300'}
```json
[{"id":"e9a3b71d40addd8b","type":"group","z":"d74afda3e83a644e","name":"Create Table","style":{"label":true},"nodes":["48b1380ff7bfe716","44bb8750d961e415","4a3976e062b2ddd2"],"x":274,"y":419,"w":572,"h":82},{"id":"48b1380ff7bfe716","type":"inject","z":"d74afda3e83a644e","g":"e9a3b71d40addd8b","name":"","props":[],"repeat":"","crontab":"","once":true,"onceDelay":"1","topic":"","x":370,"y":460,"wires":[["44bb8750d961e415"]]},{"id":"44bb8750d961e415","type":"tables-query","z":"d74afda3e83a644e","g":"e9a3b71d40addd8b","name":"Create Table","query":"CREATE TABLE IF NOT EXISTS public.sensor_readings ( (\n    id SERIAL PRIMARY KEY,\n    timestamp TIMESTAMPTZ NOT NULL DEFAULT NOW(),\n    sensor_id VARCHAR(50) NOT NULL,\n    location VARCHAR(100),\n    temperature DECIMAL(5,2)\n);\n","split":false,"rowsPerMsg":1,"x":550,"y":460,"wires":[["4a3976e062b2ddd2"]]},{"id":"4a3976e062b2ddd2","type":"debug","z":"d74afda3e83a644e","g":"e9a3b71d40addd8b","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":740,"y":460,"wires":[]},{"id":"68fbcdb03e3a5346","type":"group","z":"d74afda3e83a644e","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["4f24ab5b5628a1ba","fbf36a7b3c59461d"],"x":854,"y":419,"w":392,"h":82},{"id":"4f24ab5b5628a1ba","type":"catch","z":"d74afda3e83a644e","g":"68fbcdb03e3a5346","name":"","scope":null,"uncaught":false,"x":940,"y":460,"wires":[["fbf36a7b3c59461d"]]},{"id":"fbf36a7b3c59461d","type":"debug","z":"d74afda3e83a644e","g":"68fbcdb03e3a5346","name":"debug 6","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1140,"y":460,"wires":[]},{"id":"01137d02c4832962","type":"group","z":"d74afda3e83a644e","name":"","style":{"label":true},"nodes":["e465d4328d9d42d9","f8269cf412b4200f","2ce801643e01510b","40d48ffb90e5674a"],"x":274,"y":519,"w":972,"h":82},{"id":"e465d4328d9d42d9","type":"inject","z":"d74afda3e83a644e","g":"01137d02c4832962","name":"Insert simulated Data","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":420,"y":560,"wires":[["40d48ffb90e5674a"]]},{"id":"f8269cf412b4200f","type":"debug","z":"d74afda3e83a644e","g":"01137d02c4832962","name":"debug 2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1140,"y":560,"wires":[]},{"id":"2ce801643e01510b","type":"tables-query","z":"d74afda3e83a644e","g":"01137d02c4832962","name":"","query":"INSERT INTO public.sensor_readings (sensor_id, timestamp, location, temperature) \nVALUES ($sensor_id, $timestamp, $location, $temperature);\n","split":false,"rowsPerMsg":1,"x":930,"y":560,"wires":[["f8269cf412b4200f"]]},{"id":"40d48ffb90e5674a","type":"function","z":"d74afda3e83a644e","g":"01137d02c4832962","name":"Generate last 7 days sensor data","func":"// Generate simulated sensor readings for the last 7 days, at every even hour\nlet now = new Date();\nlet start = new Date(now.getTime() - (7 * 24 * 60 * 60 * 1000)); // 7 days ago\nlet readings = [];\n\n// Collect all readings first\nfor (let ts = new Date(start); ts <= now; ts.setHours(ts.getHours() + 1)) {\n    if (ts.getHours() % 2 === 0) {\n        readings.push({\n            queryParameters: {\n                sensor_id: \"sensor-1\",\n                timestamp: new Date(ts), // clone timestamp\n                location: \"Lab A\",\n                temperature: Number((20 + Math.random() * 10).toFixed(2)) // Ensure number type\n            }\n        });\n    }\n}\n\n// Send them one by one with delay\nreadings.forEach((reading, i) => {\n    setTimeout(() => {\n        node.send(reading);\n    }, i * 200); // 200ms delay between messages\n});\n\nreturn null; // Prevent immediate msg sending\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":700,"y":560,"wires":[["2ce801643e01510b"]]},{"id":"89c52680263e6cba","type":"global-config","env":[],"modules":{"@flowfuse/nr-tables-nodes":"0.1.0"}}]
```
::

After deployment, press the "Insert simulated Data" inject button to populate your table with a week's worth of hourly sensor readings. This sample data will help you explore Query node capabilities.

> **Note:** FlowFuse Tables is currently available for Enterprise users only.

Now, let us test the natural language querying powered by the FlowFuse Expert:

1. Add an Inject node to your flow
2. Connect it to your Query node
3. Open the Query node and locate the new "Assistant" codelens
4. Enter: "Show me all readings from today"
5. Click **Ask the FlowFuse Expert**. The FlowFuse Expert will process your natural language request and automatically generate the corresponding SQL query in the Query node's SQL field. Click Done.
6. Connect a Debug node to see the results
7. Deploy the flow and click the Inject button to test it.

:video{ariaLabel="FlowFuse Expert in Query Node" autoPlay="true" height="1702" loop="true" muted="true" playsInline="true" preload="none" width="3024"}:br*FlowFuse Expert in Query Node*

## Practical Query Examples

With your sample data in place, here are some immediately useful queries to try:

### Performance Analysis

**Track temperature averages:**:br
Prompt: "What's the average temperature for this week?"

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: MZxrI9SEegE
---
::

**Identify peak readings:**:br
Prompt: "Find the highest temperature reading this month"

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: jDIRH2i_1Uk
---
::

### Time-Based Analysis

**Hourly patterns:**:br
Prompt: "Average temperature per hour today"

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: m4L9ZHE6tdI
---
::

## Advanced Query Capabilities

Beyond basic queries, the FlowFuse Expert can handle sophisticated analysis:

**Complex filtering:**:br
Prompt: "Show readings where temperature > 20, temperature < 25, and temperature ≠ 22"

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: MtzcbmFg1-4
---
::

**Statistical operations:**:br
Prompt: "Calculate standard deviation of temperature readings this month"

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: aJ8znXOn9Hc
---
::

These examples demonstrate how the FlowFuse Expert simplifies advanced analysis, turning complex database operations into easy, natural-language requests.

## What's Next

The FlowFuse Expert now brings natural language capabilities to database queries in FlowFuse Tables. This removes the complexity of SQL, allowing industrial teams to extract insights using simple conversational commands.

FlowFuse's mission has always been to democratize industrial automation and reduce complexity for engineers and operational teams. As part of this commitment, more AI-powered features are on the roadmap to simplify industrial workflows even further.

Ready to transform how your team works with data? [Book a demo](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and see how FlowFuse makes building industrial applications simple and accessible.


# How to Create a Pareto Chart for Manufacturing Data

In the [first part of this series](https://flowfuse.com/blog/2025/08/pareto-chart-manufacturing-guide/), we explored the foundational principles of the Pareto Chart, understanding how this powerful tool can help manufacturing teams quickly identify and focus on the "vital few" problems that have the biggest impact. We learned that by combining a bar graph and a cumulative percentage line, a Pareto Chart provides a clear visual roadmap to prioritize quality issues, equipment downtime, or other key performance indicators.

Now, it's time to move from theory to practice. This guide will show you how to create a Pareto Chart using modern industrial data tools. You will learn how to connect to your production data, calculate frequencies and format data, and visualize the results in a chart that helps your team make data-driven decisions.

![Pareto Chart showing defect categories in manufacturing with bars for scratches, cracks, color issues, and other defects, alongside a cumulative percentage line.](https://flowfuse.com/blog/2025/09/images/pareto-chart.png){dataZoomable=""}&#x2A;Pareto Chart showing defect categories in manufacturing with bars for scratches, cracks, color issues, and other defects, alongside a cumulative percentage line.*

## Getting Started

To create a Pareto Chart for manufacturing data, you'll need access to industrial data platforms that can connect to your production systems. This guide uses FlowFuse, a low-code platform that simplifies industrial data workflows. If you don't have an account yet, you can [sign up for a 30-day free trial](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"}.

### Step 1: Connect to Your Data Source

The first step to create a Pareto Chart is accessing the data you want to analyze. In industrial environments, machine or process data is commonly collected via [industrial protocols](https://flowfuse.com/node-red/protocol/) such as [OPC-UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/), [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/), or direct [database](https://flowfuse.com/node-red/database/) queries. Modern industrial platforms support nearly all industrial protocols and databases, making it easy to connect to your existing systems.

To connect your data:

1. Drag the appropriate input node into your flow (e.g., an OPC-UA Read node).
2. Enter the connection details for your industrial system.
3. Test the connection to confirm that live data is flowing correctly.

If a live PLC or factory dataset is not available, you can use a simple Inject node to simulate production data and learn how to make a Pareto Chart with sample data.

### Step 2: Format and Aggregate the Data

Once data is flowing, the next step to create a Pareto Chart is to **organize it into types or categories and count how often each occurs**. A Pareto Chart is most useful when you can clearly see, for example, defect data like:

*"Scratch on Surface – 20 occurrences, Misaligned Parts – 10 occurrences, Loose Screws – 5 occurrences."*

When you make a Pareto Chart, this can be done in three steps:

1. **Format the data** – Use a JSON, CSV, or Change node to clean or convert incoming data if needed.
2. **Aggregate in a Function node** – Map each data point to a type (e.g., machine type, process step, defect category) and keep a running count of occurrences.
   > **Tip:** You do not need to know JavaScript. Simply describe the desired outcome and provide a sample dataset, the **FlowFuse Expert** will generate the Function node for you. [Learn more](https://flowfuse.com/blog/2025/07/flowfuse-ai-assistant-better-node-red-manufacturing/).
3. **Sort the results** – Use a Sort node to arrange categories so the most frequent appear first.

At the end of this step, your data should be transformed into a structure like this, which is the **required format to create a Pareto Chart** in Step 3:

```json
[
  { "type": "Paint Defect", "count": 8 },
  { "type": "Faulty Electronics", "count": 6 },
  { "type": "Scratch on Surface", "count": 5 },
  { "type": "Misaligned Parts", "count": 3 },
  { "type": "Loose Screws", "count": 2 },
  { "type": "Cracked Housing", "count": 1 }
]
```

### Step 3: Visualizing the Chart

Before you can create a Pareto Chart visualization, ensure that you have installed the &#x2A;*`@flowfuse/node-red-dashboard`** node. This library provides the essential user interface components needed to create a real-time dashboard.

1. Open the Editor and click on the **hamburger menu** (☰) in the top-right corner.
2. Select **Manage palette**.
3. Navigate to the **Install** tab.
4. Search for &#x2A;*`@flowfuse/node-red-dashboard`** and click **Install**.

After installation, new UI nodes, such as **UI Chart**, **UI Gauge**, **UI Template**, and others, will appear in your palette. These nodes provide the building blocks to make a Pareto Chart and other interactive dashboard components for industrial applications.

While the standard **UI Chart** node supports most common chart types, it does not include a native **Pareto chart**. To create a Pareto Chart with advanced features, the **UI Template** node can be used, allowing you to embed custom components for fully tailored visualizations.

Below is an example showing how to create a Pareto Chart using the **UI Template** node. You can copy and import this flow directly into your editor to start using it immediately.

::render-flow{:height='300'}
```json
[{"id":"fef40951758bc433","type":"ui-template","z":"fd8e1f4dd4a1bb0b","group":"5a4c5fe0a49298d4","page":"","ui":"","name":"Pareto Chart","order":1,"width":0,"height":0,"head":"","format":"<template>\n    <canvas ref=\"chart\" />\n</template>\n\n<script src=\"https://cdn.jsdelivr.net/npm/chart.js@4\"></script>\n<script>\n    export default {\n        mounted() {\n            this.draw();\n            // Register a listener for incoming data from Node-RED\n            this.$socket.on('msg-input:' + this.id, this.onInput);\n        },\n        methods: {\n            draw() {\n                // Get the canvas element to draw the chart on\n                const ctx = this.$refs.chart;\n                \n                // Initialize the chart with no data\n                const chart = new Chart(ctx, {\n                    type: 'bar', // This is the default type\n                    data: {\n                        labels: [],\n                        datasets: []\n                    },\n                    options: {\n                        responsive: true,\n                        interaction: {\n                            mode: 'index',\n                            intersect: false,\n                        },\n                        scales: {\n                            // Left Y-axis for the bars (counts)\n                            y: {\n                                type: 'linear',\n                                display: true,\n                                position: 'left',\n                                title: {\n                                    display: true,\n                                    text: 'Frequency'\n                                },\n                                beginAtZero: true\n                            },\n                            // Right Y-axis for the cumulative line (percentages)\n                            y1: {\n                                type: 'linear',\n                                display: true,\n                                position: 'right',\n                                title: {\n                                    display: true,\n                                    text: 'Cumulative %'\n                                },\n                                // Do not display grid lines for this axis\n                                grid: {\n                                    drawOnChartArea: false,\n                                },\n                                // Ensure the percentage scale goes to 100%\n                                max: 100\n                            }\n                        }\n                    }\n                });\n                \n                // Make the chart object accessible to other methods\n                this.chart = chart;\n            },\n            onInput(msg) {\n                // Get the raw data from the incoming message payload\n                const rawData = msg.payload;\n\n                let cumulativeSum = 0;\n                const total = rawData.reduce((sum, item) => sum + item.count, 0);\n\n                const labels = [];\n                const barData = [];\n                const lineData = [];\n\n                // Process the data to build chart datasets\n                rawData.forEach(item => {\n                    labels.push(item.type);\n                    barData.push(item.count);\n\n                    // Calculate cumulative sum and percentage\n                    cumulativeSum += item.count;\n                    const cumulativePercentage = (cumulativeSum / total) * 100;\n                    lineData.push(cumulativePercentage);\n                });\n\n                // Update the chart's data and labels\n                this.chart.data.labels = labels;\n                this.chart.data.datasets = [\n                    {\n                        type: 'bar',\n                        label: 'Frequency',\n                        data: barData,\n                        backgroundColor: 'rgba(54, 162, 235, 0.6)',\n                        yAxisID: 'y'\n                    },\n                    {\n                        type: 'line',\n                        label: 'Cumulative Percentage',\n                        data: lineData,\n                        borderColor: 'rgb(255, 99, 132)',\n                        backgroundColor: 'rgba(255, 99, 132, 0.4)',\n                        fill: false,\n                        yAxisID: 'y1'\n                    },\n                    // -- START OF MODIFICATIONS --\n                    {\n                        type: 'line',\n                        label: '80% Threshold',\n                        data: labels.map(() => 80), // Creates a horizontal line at 80\n                        borderColor: 'rgba(75, 192, 192, 1)',\n                        borderWidth: 2,\n                        borderDash: [5, 5], // This property creates a dotted line\n                        fill: false,\n                        pointRadius: 0, // Hides data points\n                        yAxisID: 'y1'\n                    }\n                ];\n\n                // Redraw the chart to show the new data\n                this.chart.update();\n            }\n        }\n    }\n</script>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1030,"y":260,"wires":[[]]},{"id":"5a4c5fe0a49298d4","type":"ui-group","name":"Pareto Chart Group","page":"74853f680cb16c6c","width":"12","height":1,"order":1,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"74853f680cb16c6c","type":"ui-page","name":"Home","ui":"d7fb2be4d7cb92b9","path":"/","icon":"home","layout":"grid","theme":"faac104f34962f3e","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"d7fb2be4d7cb92b9","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":true},{"id":"faac104f34962f3e","type":"ui-theme","name":"Default Theme","colors":{"surface":"#8ec8f3","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"2ebdb042b8d72fd5","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.26.0"}}]
```
::

### Connecting Your Real Production Data

1. Ensure your upstream data flow (from OPC-UA, MQTT, or database nodes) is cleaned and aggregated into the JSON format described in Step 2.
2. Connect the output of that flow to the &#x2A;*Pareto Chart (UI Template)** node you imported, then deploy the flow.
3. Whenever new data arrives, the chart will automatically update, displaying both the bars (frequency) and the cumulative percentage line.

To view the dashboard, click the **Open Dashboard** button in the top-right corner of the Dashboard 2.0 sidebar. Your newly created Pareto Chart will appear, complete with bars, the cumulative line, and the 80% threshold.

![Pareto Chart showing defect categories in manufacturing with bars for scratches, cracks, color issues, and other defects, alongside a cumulative percentage line.](https://flowfuse.com/blog/2025/09/images/pareto-chart.png){dataZoomable=""}&#x2A;Pareto Chart showing defect categories in manufacturing with bars for scratches, cracks, color issues, and other defects, alongside a cumulative percentage line.*

The chart visualizes defect types using bars. The cumulative line and the 80% threshold indicate the cutoff point: bars to the left of this intersection represent the vital few defects that contribute most to the total, and these are the areas where you should focus your improvement efforts.

![Pareto Chart showing defect categories in manufacturing. The bars on the left, highlighted with a red box, represent the vital few defects](https://flowfuse.com/blog/2025/09/images/pareto-chart-decoded.png){dataZoomable=""}*Pareto Chart showing defect categories in manufacturing. The bars on the left, highlighted with a red box, represent the vital few defects*

## Takeaways

By following the steps outlined above, you have successfully learned how to create a Pareto Chart that transforms raw production data into clear, actionable insights. This visualization helps manufacturing teams focus their limited time and resources on the problems that matter most.

### Why This Matters for Your Business

The real power when you create a Pareto Chart isn't just in identifying problems, it's in changing how your team makes decisions. Instead of trying to fix everything at once or relying on gut feelings, you now have **data-driven clarity** on where to focus. This translates into:

- **Less firefighting, more strategic improvement:** Teams can stop chasing every small issue and concentrate on the critical few that truly impact production.
- **Faster problem resolution:** When everyone can see which issues dominate, alignment happens quickly and solutions get implemented faster.
- **Better conversations with management:** Visual data makes it easier to justify resource allocation and demonstrate the impact of improvement initiatives.
- **Continuous learning:** As the top issues are resolved, new patterns emerge, creating a cycle of ongoing improvement.

### Building on Your Success

With your ability to create a Pareto Chart established, you've built a foundation for **data-driven decision-making**. The same approach to make a Pareto Chart can be applied to other areas of operations:

- Track equipment downtime reasons to optimize maintenance schedules.
- Analyze customer feedback to prioritize product improvements.
- Monitor supplier performance to strengthen the supply chain.
- Identify training gaps by analyzing operator errors.

A Pareto chart also rarely stands alone. It usually sits inside a broader [quality or production dashboard](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/) next to defect trends, first-pass yield, and downtime, so the cause breakdown is read in context rather than on its own.

FowFuse makes it simple to replicate this success across your organization. The same flow can be deployed to multiple lines, shared with other teams, and adapted for different use cases, while maintaining security and control through enterprise-grade features.

Ready to see how FlowFuse can help your team make better decisions with production data? [Book a demo](https://flowfuse.com/book-demo/) to discover how manufacturers are using visual analytics to drive continuous improvement and operational excellence.


# FlowFuse 2.22: FlowFuse Expert for node editing, FlowFuse Broker schema autodetection, Improved Snapshots Interface, eCharts enablement, and FlowFuse Dashboard Updates

FlowFuse 2.22 provides more powerful development by bringing the FlowFuse Assistant to more nodes, supports operational maturity with automatic FlowFuse Broker schema detection, and enhances the developer experience with an improved Snapshots interface, support for more powerful visualizations, a better Device Agent Installer experience, Dashboard updates, and more! Take a look:

## AI Expert for Node Editing

:video{ariaLabel="Video showing FlowFuse Expert in Function node" autoPlay="true" height="789" loop="true" muted="true" playsInline="true" preload="none" width="1106"}*FlowFuse Expert at work*

We've enhanced the capabilities of the FlowFuse Expert, which now provides automatic suggestions to draft and edit your code that extends to Tables nodes, Dashboard Template nodes (ui-template), and Function nodes. You can now simply start typing, and the FlowFuse Assistant will provide code for you based on your context, making the FlowFuse Assistant your AI copilot in Node-RED.

With this change, the FlowFuse assistant can now write HTML, CSS, SQL, Javascript, and JSON, all based on your words, and with awareness of your FlowFuse environment (like your Tables structure), cursor position, and where in your code you are editing.

## FlowFuse Team Broker Automatic Schema Detection

![Image showing schema detection](https://flowfuse.com/blog/2025/09/images/schema-autodetect.png)*Enable schema autodetection for FlowFuse Broker*

Documenting a broker schema can be a challenging and time-consuming task, which is why we've provided schema autodetection for the FlowFuse Broker. With the click of a button, our broker will now listen for topics and provide suggestions for the topic schema that you can accept or revise, and these will be added to documentation for your broker.

This will keep your team aligned on message format and serve as a single source of truth for maintaining your Unified Namespace.

## Enablement for Apache eCharts

With this release, we are now positioned to enable much more powerful and visually-compelling charts to FlowFuse Dashboard, and have significantly increased chart performance.

We've enabled the use of Apache eCharts. It used to take 8.3 seconds to render 1,000 data points, and now it takes 75 milliseconds -- that is about 111 times faster performance!

While the primary work for Apache eCharts has been to enable the addition of new chart types, we did add one new type of chart: categorical line charts.

Which charts would you like to see added first? [Check out these examples of what is now possible](https://echarts.apache.org/examples/en/index.html){rel="&#x22;nofollow&#x22;"}, and reach out on [GitHub](https://github.com/flowfuse/node-red-dashboard){rel="&#x22;nofollow&#x22;"}!

## Updated Snapshots UI

![Image of updated Snapshots user interface](https://flowfuse.com/blog/2025/09/images/snapshots-ui.png)*Manage Snapshots in the new panel*

Snapshots are now much easier to manage and interact with.

The Snapshots user interface now provides a centralized place to manage your snapshots, providing a preview of the snapshot, download options, restore, edit name and description, and compare to other snapshots, all in one easy-to-manage location in the right side of the interface.

While the features available for managing Snapshots remain, this update brings those features to the surface in a much cleaner and more intuitive way.

## Remote Instance Snapshot Summaries

Speaking of Snapshots: until this release, our automatic snapshot summary feature only worked with hosted instances. As of today, you can now get AI-generated summaries of snapshots of your remote instances as well.

This is especially important for users with large remote instance deployments, and provides an important step forward in enabling FlowFuse users to manage and scale their deployments.

## SAML Group Assertions for Dashboard Development

Managing Dashboard permissions when building flows just got easier for Enterprise teams using SSO.

We've added an new option so that a users SSO Group memberships can be included in the `user` object Dashboard flows receive when a user is logged in. This makes it much easier to build custom permissions into your FlowFuse Dashboard applications, giving you far more flexibility.

## Device Agent Installer handles Multiple Remote Instances

We're continuing to work on making the process for installing the Device Agent as simple, easy, fast, and reliable as possible. With this release, the Device Agent Installer can install multiple Device Agents on a single remote device, by allowing you to install the Device Agent in a non-default directory and specify a non-default port. In addition, clearer installation summaries, documentation links, and improved installer output have improved the overall usability of the installer.

## Dashboard Fixes

Finally, we've made a number of small fixes that overall improve the Dashboard experience. These include:

- Changeable colors on the X-axis
- Significantly decreased loading time for ui-chart
- Categorical line chart option
- Number inputs can be set to decimals
- Fixed some display bugs with the display when the sidebar is collapsed or uncollapsed

# Sneak Peek

We're excited about a few more features that are just on the verge of being ready to ship! Here's a preview:

## Detailed Access Control

Until now, all user permissions in FlowFuse are set at the team level, where each user is either an Owner, Admin, Viewer, or Dashboard-only user, for everything in the team. If you wanted to set different permissions for different applications, you needed to put your application under a team where you had set the permissions you wanted: this made visibility difficult and increased the hassle of managing permissions.

Now, permissions can be set at the application level. If you're a team running many different applications and need to organize who can access what, you are able to do that for each individual appication, significantly increasing the security and management abilities of FlowFuse.

This feature will be available in the next few days - keep an eye on our [ChangeLog](https://flowfuse.com/changelog/) for updates on when its available.

## AI and Machine Vision

Be on the lookout for some very cool applications of AI to machine vision!

## What's Next?

In the next release, we'll provide support for building AI agents, real-time streaming protocol, a far more flexible Dashboard, bringing the FlowFuse Assistant to all self-hosted customers, and more! Stay tuned!

## What else is new?

For a complete list of everything included in our 2.22 release, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.22.0){rel="&#x22;nofollow&#x22;"}.

Your feedback continues to be invaluable in shaping FlowFuse's development. We'd love to hear your thoughts on these new features and any suggestions for future improvements. Please share your experiences or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Which of these new features are you most excited to try? Email me directly at <greg@flowfuse.com> - I'd love to hear from you!

## Try FlowFuse

### FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in the cloud within minutes.

### Self-Hosted

Get FlowFuse running locally in under 30 minutes using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# Download Node-RED for Production: Windows, Mac, Linux, Raspberry Pi (2026)

Installing Node-RED is straightforward. Install Node.js, run a command, and you're ready for visual programming in industrial automation. The real challenge begins when it must run across production lines, connect to PLCs, and stay operational 24/7.

## Download Node-RED for Production Use

Standalone Node-RED works great for testing, but production is different. When your flows control PLCs and critical equipment, downtime costs thousands per minute.

Hardware fails. Networks drop. Power cuts out. Your Node-RED instance must restart automatically, handle connectivity issues, and keep production running without manual intervention. Deploying, managing and scaling must be easy and quick in such environments.

Managing dozens of industrial PCs running Node-RED? You need centralized updates, secure remote access, proper backups, and role-based permissions. Your engineering team's months of flow development can't be lost to a hardware failure.

Production Node-RED needs enterprise reliability, security, and management capabilities that the basic installation simply can't provide.

## FlowFuse for Production: Built by Node-RED’s Creator

FlowFuse was co-founded by [Nick O'Leary](https://knolleary.net/about/){rel="&#x22;nofollow&#x22;"}, the creator and project lead of Node-RED. Since creating Node-RED at IBM in 2013, Nick has led its evolution from an internal IoT tool into one of the most widely used low-code platforms for industrial automation, with millions of downloads each year. You can read the history of Node-RED written by Nick [here](https://flowfuse.com/blog/2024/02/history-of-nodered/).

After more than a decade of working directly with enterprise users deploying Node-RED in production environments, Nick and the FlowFuse team built FlowFuse to address the operational challenges that standalone Node-RED cannot solve at scale.

FlowFuse makes Node-RED production-ready through centralized management across industrial infrastructure, incorporating years of real-world deployment experience from the creator of Node-RED himself.

:cta-image{alt="Power Workplace relies on FlowFuse for scalability, reliability and security audits - book a demo" cta="demo" src="https://flowfuse.com/images/cta/power-workplace-book-demo.png"}

### Enterprise Reliability from Node-RED Experts

When hardware fails, FlowFuse keeps operations running through High Availability mode that distributes processing across multiple instances. Device Agents monitor system health and provide secure remote access for engineering teams, features designed by the same team that built and maintains Node-RED's core architecture.

Engineering teams get proper DevOps workflows that move flows through development, testing, and production with automated deployments. Device grouping makes updates reach thousands of devices possible while version control and rapid rollbacks keep projects on track.

Enterprise security comes built-in with single sign-on, role-based access control, comprehensive audit logging, and encrypted communications. Automated snapshots protect engineering work with rapid recovery when needed.

These core capabilities are just the foundation, FlowFuse includes dozens of additional features designed specifically for industrial environments, refined through direct experience deploying Node-RED across Fortune 500 manufacturers and critical infrastructure.

### Trusted by Industry Leaders

FlowFuse is deployed in production environments across manufacturing, energy, and infrastructure sectors where Node-RED reliability is mission-critical. The platform's architecture reflects over 12 years of Node-RED development expertise and direct feedback from thousands of industrial deployments.

As the official enterprise solution developed by Node-RED's creator, FlowFuse represents the authoritative approach to production Node-RED deployments, backed by the team with the deepest expertise in the technology.

## Setting Up FlowFuse

Sign up for the [30-day trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} at FlowFuse, and you can get started immediately.

### Step 1: Add Remote Instance

Once the platform opens:

1. Click on **Remote Instances** from the left sidebar

![FlowFuse Platform Dashboard](https://flowfuse.com/blog/2025/09/images/add-remote-instance.png){dataZoomable=""}*FlowFuse platform dashboard showing Remote Instances option*

2. Click **Add Remote Instance**

![Add Remote Instance Button](https://flowfuse.com/blog/2025/09/images/platform-ff.png){dataZoomable=""}*Button to add a new remote Node-RED instance*

3. Give it a name and select the device type

![Device Instance Configuration](https://flowfuse.com/blog/2025/09/images/trail-add-instance.png){dataZoomable=""}*Configuring the remote device instance with name and type*

4. Select your application and click **Add**

### Step 2: Install Device Agent

FlowFuse shows you a device configuration window with two options. The **One-Line Install** handles everything automatically. It installs Node.js if missing, installs the device agent, and registers your device with the platform.

The **NPM Installation** method provides manual instructions for Windows, Mac, or Linux.

:video{ariaLabel="FlowFuse Device Configuration Window" autoPlay="true" height="1644" loop="true" muted="true" playsInline="true" preload="none" width="3024"}*Device configuration window showing installation options for the FlowFuse Device Agent*

Follow the steps given within the window, which takes less than a minute to connect your device.

### Step 3: Manage Your Device

Once registered, you get complete control over your remote Node-RED instance through FlowFuse's management interface:

:video{ariaLabel="FlowFuse Device Management Tools" autoPlay="true" height="1644" loop="true" muted="true" playsInline="true" preload="none" width="3024"}*Tools for managing Node-RED instance remotely via FlowFuse*

There are even more features available at the application level and team level that you can explore. To remove infrastructure management complexity of required services such as MQTT and PostgreSQL, they are built-in and available for use.

### Step 4: Start Building

To start building flows:

1. Enable **Developer Mode** from the top right

![Developer Mode Option](https://flowfuse.com/blog/2025/09/images/developer-mode.png){dataZoomable=""}*Developer Mode Option*

2. Click **Open Editor**

![Developer Mode Option](https://flowfuse.com/blog/2025/09/images/open-editor.png){dataZoomable=""}*Open Editor Option*

Your automation flows now run with production reliability. Remote access works securely, and your team can collaborate while production continues running.

![Developer Mode Option](https://flowfuse.com/blog/2025/09/images/node-red-editor.png){dataZoomable=""}*Node-RED Editor*

## Up Next

FlowFuse bridges the gap between Node-RED's simplicity and production reliability requirements, built by the people who created Node-RED and understand its production needs better than anyone.

Ready to see FlowFuse in action? [Book a demo](https://flowfuse.com/book-demo/) and we'll show you how it works with your setup.


# Integrating LoRaWAN with FlowFuse

LoRaWAN (Long Range Wide Area Network) is a low-power wireless protocol designed for IoT devices that need to transmit small amounts of data over long distances. FlowFuse is a platform that provides a visual programming interface for connecting IoT devices and services.

By combining LoRaWAN with FlowFuse, you can easily collect data from remote sensors, process it, and integrate it with other systems or dashboards, all without writing complex code. In this article, we will guide you through setting up the integration and creating your first data processing flows.

## What is LoRaWAN and How Does It Work?

LoRaWAN is designed for devices that need to send small amounts of data over long distances while using very little battery power. Your sensors can communicate up to 15 kilometers away and run for years on a single battery.

The system has three main parts:

- End devices - Your sensors that collect and send data
- Gateways - These receive data from your sensors and pass it along
- Network server - Manages everything and sends your data to applications

[The Things Network (TTN)](https://www.thethingsnetwork.org/){rel="&#x22;nofollow&#x22;"} is a free, global LoRaWAN network with thousands of gateways around the world. It's perfect for getting started with LoRaWAN projects and provides easy-to-use tools for managing your devices.

We'll show you how to connect TTN to FlowFuse for monitoring sensor data and building scalable industrial applications.

## Getting Started

Now that we understand the basics of LoRaWAN, let's set up the integration with FlowFuse.

### Prerequisites

Before we begin, make sure you have the following components ready:

1. Node-RED instance – Ensure you have a running Node-RED instance. The quickest way to set one up is through FlowFuse. [Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}, create your instance, and you will be able to manage, deploy, scale, and secure your flows with ease. FlowFuse also provides enterprise-ready features out of the box.
2. LoRaWAN device and gateway registered on TTN – You need a sensor or device connected to TTN and a gateway that can receive its uplinks.

If you do not have a LoRaWAN device, you can simulate one using available tools. For this article, I am using the [LWN-Simulator](https://github.com/UniCT-ARSLab/LWN-Simulator){rel="&#x22;nofollow&#x22;"}.

## Setting Up TTN MQTT Connection

TTN provides MQTT integration that allows external applications to receive uplink messages from your devices. We'll use this to connect TTN with FlowFuse.

### Getting TTN Connection Details

1. Log into your TTN Console (<https://console.thethingsnetwork.org>{rel="&#x22;nofollow&#x22;"})
2. Navigate to your application
3. Go to the Other Integrations tab and select MQTT
4. Note down the following connection details:
   - Server Address: Depends on your cluster, for example: `nam1.cloud.thethings.network`
   - Port: 1883 (for non-TLS) or 8883 (for TLS)
   - Username: Your application ID
   - Password: Your API key

![Screenshot of TTN console showing MQTT integration details including server address, port, username, and API key](https://flowfuse.com/blog/2025/09/images/mqtt-connection-details.png){dataZoomable=""}*Screenshot of TTN console showing MQTT integration details including server address, port, username, and API key*

### Configure MQTT Node and Receiving Uplink Messages

Uplink messages are data transmissions sent from your LoRaWAN sensors and devices to Network and then forwarded to your applications. These messages contain sensor readings, status updates, or any other data your devices collect. Let's configure FlowFuse to receive these uplink messages.

1. Open your FlowFuse instance Editor.
2. Drag an MQTT In node from the palette onto your workspace
3. Double-click the node to configure it:
   - Server: Add a new MQTT broker configuration
   - Host: Enter your TTN server address (e.g., nam1.cloud.thethings.network)
   - Port: 1883 or 8883 (if using TLS)
   - Username: Your TTN application ID
   - Password: Your TTN API key
   - Topic: `v3/{application-id}/devices/{device-id}/up` (replace with your actual application and device IDs)
4. Click Done to save the configuration
5. Connect a Debug node to the output of your MQTT In node
6. Deploy the flow by clicking the Deploy button
7. Open the Debug panel to see incoming messages from your LoRaWAN device

The messages you receive will be in JSON format and contain various fields as following:

| Field                            | Description                                                     |
| -------------------------------- | --------------------------------------------------------------- |
| end\_device\_ids.device\_id      | Unique identifier of the device in TTN                          |
| end\_device\_ids.dev\_eui        | Globally unique hardware identifier (EUI) of the device         |
| end\_device\_ids.join\_eui       | Identifier used during device activation (JoinEUI/AppEUI)       |
| end\_device\_ids.dev\_addr       | Device address assigned by the network                          |
| received\_at                     | Timestamp when TTN received the message                         |
| uplink\_message.f\_port          | LoRaWAN port number (used to separate types of payloads)        |
| uplink\_message.f\_cnt           | Frame counter for tracking uplinks                              |
| uplink\_message.frm\_payload     | Raw payload                                                     |
| uplink\_message.decoded\_payload | Decoded values (requires a payload formatter in TTN)            |
| uplink\_message.rx\_metadata     | Metadata per gateway (includes RSSI, SNR, gateway ID, etc.)     |
| uplink\_message.settings         | Radio parameters (frequency, data rate, spreading factor, etc.) |
| uplink\_message.received\_at     | Timestamp when TTN processed the uplink                         |
| correlation\_ids                 | IDs used internally to correlate events across the TTN stack    |

## Processing Data

Let's add some processing to extract and format the received data. This approach uses community-contributed nodes and requires minimal coding. Install the `node-red-node-base64` and `node-red-contrib-buffer-parser` nodes.

1. Drag a Change node and set `msg.payload` to `msg.payload.uplink_message.frm_payload`
2. Drag a base64 node and set the action to "Decode" (converts Base64 string to Buffer)
3. Drag the buffer parser node and configure elements based on your data format
4. Click the "+" button to add each element and fill in the following fields for each data point you want to extract:

**Example Configuration for Temperature/Humidity Sensor:**

| Element | Type    | Name        | Length | Offset | Scale |
| ------- | ------- | ----------- | ------ | ------ | ----- |
| 1       | int16be | temperature | 2      | 0      | 0.01  |
| 2       | int16be | humidity    | 2      | 2      | 0.01  |

**Quick Parameter Guide:**

- Type: How to read the bytes (int16be = 2-byte big-endian signed integer, uint8 = 1-byte unsigned integer)
- Name: What to call it in your output (becomes msg.payload.temperature)
- Length: Number of bytes to read (2 for int16be, 1 for uint8)
- Offset: Where to start reading (0 = first byte, 2 = third byte, etc.)
- Scale: Math to apply (0.01 = divide by 100, 1 = no scaling)

5. Connect the MQTT in node to the input of change node, change node output to base64 node and base64 node output to the input of buffer parser and add the debug node at the end to see the output.
6. Deploy the flow.

Now you will see the object with the parsed sensor data in the debug panel. The output will show something like:

```json
{
  "temperature": 21.5,
  "humidity": 57.2
}
```

As you can see in the image below, TTN console shows live data with uplink message on the left side, and FlowFuse successfully reads and processes it on the right side.

:video{ariaLabel="Video showing TTN console with live uplink messages on the left and FlowFuse debug panel with processed sensor data on the right" autoPlay="true" height="1312" loop="true" muted="true" playsInline="true" preload="none" width="3024"}*Video showing TTN console with live uplink messages on the left and FlowFuse debug panel with processed sensor data on the right*

## Sending Commands to Devices (Downlink)

Downlink messages are commands sent from your application back to LoRaWAN devices through the network. These messages allow you to remotely control your devices, update their configuration, trigger specific actions, or send firmware updates. LoRaWAN devices can only receive downlink messages during their receive windows after sending an uplink, making this communication asynchronous but highly power-efficient.

1. Drag the Inject node onto the canvas.
2. Drag a Function node and add JavaScript to format the downlink message with the data you want to send. Alternatively, you can use a Change node with a Base64 node for a low-code approach.

```javascript
// Example: Send a command to turn on LED or change sensor interval
const downlinkMessage = {
    downlinks: [{
        f_port: 1, // Port number (1-223)
        frm_payload: Buffer.from([0x01, 0x0A]).toString('base64'), // Command bytes
        priority: "NORMAL"
    }]
};

msg.payload = JSON.stringify(downlinkMessage);
return msg;
```

**Downlink Properties Explanation:**

- `f_port`: The LoRaWAN port number (1-223) used to differentiate message types
- `frm_payload`: Your command data encoded as Base64 string
- `priority`: Message priority ("LOWEST", "LOW", "BELOW\_NORMAL", "NORMAL", "ABOVE\_NORMAL", "HIGH", "HIGHEST")

3. Add an MQTT Out node to your workspace
4. Configure it with the same TTN broker settings as your MQTT In node
5. Set the topic to: `v3/{application-id}/devices/{device-id}/down/push` (replace with your actual application and device IDs)
6. Connect the Inject node to Function node and Function node to MQTT out node.
7. Deploy the flow.

In the image below, you can see FlowFuse sending and processing the downlink message, while TTN console displays the live data on the left.

:video{ariaLabel="Video showing TTN console with live Downlink messages on the left and FlowFuse debug panel with processed sensor data on the right" autoPlay="true" height="1332" loop="true" muted="true" playsInline="true" preload="none" width="3024"}*Video showing TTN console with live Downlink messages on the left and FlowFuse debug panel with processed sensor data on the right*

## Next Steps

Next, you can store this data in a database. With FlowFuse, a managed PostgreSQL database is already provided, so you do not need to install or configure one manually. FlowFuse also offers a Query node that is automatically configured for your instance. Inside the Query node, you can use FlowFuse Expert, which allows you to write natural language prompts instead of SQL queries. The assistant will generate SQL automatically based on your table schema.

For a complete guide on storing and visualizing data, see the article on [Building Historical Data Dashboards with FlowFuse Tables](https://flowfuse.com/blog/2025/08/time-series-dashboard-flowfuse-postgresql/). It also includes step-by-step instructions for creating dashboards using [FlowFuse Dashboard](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"}, a low-code way to build powerful industrial dashboards that also allows you to send downlink data to devices interactively.

With FlowFuse, you get a complete enterprise-grade platform built around visual programming, perfect for production-ready IoT deployments. It adds powerful capabilities like centralized management of Node-RED instances, DevOps tools, snapshots, real-time team collaboration, audit logs, RBAC, SSO, Built mqtt broker and database service and more, all designed to help you scale and manage your applications with ease.

If you're interested in exploring FlowFuse further for your industrial IoT applications, come visit us at our booth at upcoming TTN conferences to see live manufacturing demos. You can also [book a demo](https://flowfuse.com/book-demo/) to see how FlowFuse can streamline your development and deployment workflows, or [start your free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and build your first LoRaWAN-enabled dashboard today.


# IT vs OT: Key Differences, OT Cybersecurity, and IT/OT Convergence

**Operational Technology (OT)** is the hardware and software that monitors and controls physical equipment and processes: PLCs, SCADA, DCS, and machinery on the plant floor. &#x2A;*Information Technology (IT)** is the systems that run the business: email, ERP, databases, and cloud applications. IT vs OT comes down to managing information versus controlling physical processes, and that one difference drives everything else: security priorities, update cycles, equipment lifespan, and downtime tolerance.

Connecting the two (IT/OT convergence) is central to Industry 4.0, but it only works once you understand where these systems differ and why.

## What is OT (Operational Technology)?

OT is the umbrella term for the systems that directly run production: [Programmable Logic Controllers (PLCs)](https://flowfuse.com/blog/2025/10/plc-to-mqtt-using-flowfuse/) that execute real-time control logic, [SCADA](https://flowfuse.com/use-cases/scada/) systems that provide centralized monitoring across distributed sites, Distributed Control Systems (DCS) for complex continuous processes, and [Human-Machine Interfaces (HMI)](https://flowfuse.com/blog/2025/11/building-hmi-for-equipment-control/) that give operators visualization and control. Safety Instrumented Systems, Building Management Systems, and [Manufacturing Execution Systems (MES)](https://flowfuse.com/use-cases/mes/) round out the OT landscape. Collectively, these are known as Industrial Control Systems (ICS).

OT prioritizes safety, availability, and reliability above everything else. These systems were historically air-gapped, receive updates rarely (often only during planned shutdowns), and communicate over industrial protocols like [Modbus](https://flowfuse.com/node-red/protocol/modbus/), Profibus, [OPC-UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/), and [EtherNet/IP](https://flowfuse.com/blog/2025/10/using-ethernet-ip-with-flowfuse/) rather than standard internet protocols. Equipment stays in service for 15-25+ years, runs on millisecond timing, and has essentially zero tolerance for downtime: every stopped minute costs money.

## What is IT (Information Technology)?

IT covers the systems, software, and infrastructure that manage business data and enable enterprise operations: [email](https://flowfuse.com/node-red/notification/email/) and [databases](https://flowfuse.com/node-red/database/), ERP and CRM platforms, business intelligence, and increasingly cloud and SaaS applications.

IT prioritizes data confidentiality and integrity, stays connected to the internet by default, and receives patches on monthly or quarterly cycles over standardized protocols like TCP/IP, HTTP, and HTTPS. Equipment typically cycles out every 3-5 years, and businesses can usually tolerate minutes-to-hours of downtime for maintenance.

## IT vs OT: Key Differences

IT manages information; OT controls physical processes. IT systems support finance, planning, and analytics, while OT systems directly run machines, production lines, and safety-critical infrastructure. Because OT interacts with the physical world, its requirements for reliability, timing, and safety are far stricter than IT's.

| Dimension                      | Information Technology (IT)                         | Operational Technology (OT)                         |
| ------------------------------ | --------------------------------------------------- | --------------------------------------------------- |
| **Primary Role**               | Manage business data and digital workflows          | Control and monitor physical equipment              |
| **Main Priority**              | Efficiency, data integrity, and confidentiality     | Safety, availability, and reliability               |
| **Operating Environment**      | Offices, data centers, cloud platforms              | Factory floors, plants, field locations             |
| **Typical Systems**            | ERP, CRM, email, databases, cloud apps              | PLCs, SCADA, DCS, HMIs, SIS, MES                    |
| **Impact of Downtime**         | Reduced productivity and service disruption         | Production stoppage and safety risk                 |
| **Downtime Tolerance**         | Minutes to hours                                    | Near zero                                           |
| **Response Time Requirements** | Seconds to minutes                                  | Milliseconds to seconds                             |
| **System Lifecycle**           | 3-5 years                                           | 15-25+ years                                        |
| **Patch & Update Frequency**   | Regular and frequent                                | Rare and carefully scheduled                        |
| **Connectivity Model**         | Internet and cloud by default                       | Historically isolated, now selectively connected    |
| **Protocols Used**             | TCP/IP, HTTP/HTTPS, REST, SQL                       | Modbus, OPC-UA, Profibus, EtherNet/IP               |
| **Security Priority Model**    | **CIA**: Confidentiality → Integrity → Availability | **AIC**: Availability → Integrity → Confidentiality |
| **Failure Consequences**       | Data loss or system outage                          | Equipment damage, safety incidents                  |
| **Regulatory Emphasis**        | Data protection and compliance                      | Safety and critical infrastructure protection       |
| **Typical Skill Sets**         | IT, networking, cybersecurity                       | Automation, electrical, mechanical engineering      |

## IT/OT Convergence

Historically, IT and OT operated in complete isolation: factory floor systems never touched the corporate network, and business systems had no visibility into production. Industry 4.0, the Industrial Internet of Things (IIoT), and smart manufacturing are now driving IT/OT convergence: connecting production equipment to business systems for real-time monitoring, predictive maintenance, quality feedback loops, energy optimization, and automated supply chain integration.

Done well, convergence delivers concrete results: real-time dashboards instead of end-of-shift reports, condition-based maintenance that catches failures before they happen, immediate quality feedback that cuts scrap and rework, and inventory and logistics systems that react to actual consumption instead of forecasts.

Making it work takes more than connectivity, though. Start with clear business objectives and a handful of high-ROI use cases rather than a big-bang integration project. Design security in from the start (see below), and don't skip the organizational side: IT teams are used to iterating fast and patching often, while OT teams prioritize stability and uptime above all else, so successful projects build cross-functional teams and shared goals rather than treating convergence as a pure IT initiative. The most common failure mode is treating convergence as a technology project instead of a business one: without clear objectives, executive sponsorship, and OT involvement from day one, projects deliver connectivity without value.

## OT Cybersecurity

Connecting OT to business networks, and potentially the internet, exposes production systems to threats they were never designed to withstand. Traditional IT security assumptions break down in OT environments for a few structural reasons: OT systems often can't be patched without a production stoppage, and some legacy equipment can't be patched at all; OT flips the IT security priority model from confidentiality-first (**CIA**) to availability-first (**AIC**), since stopping a line can cost more, and be more dangerous, than the threat it prevents; and OT's millisecond timing requirements mean standard IT tools like network scanners can crash a PLC that was never built to handle that traffic.

The threats are real and growing: ransomware that specifically targets manufacturers because downtime pressure makes them more likely to pay, nation-state actors probing critical infrastructure, insider access being misused, compromised vendor and supply-chain access, and, ironically, well-meaning IT security scans that take down OT equipment by accident.

Effective OT security centers on a handful of practices: network segmentation with industrial DMZs (never connect OT directly to the internet), full asset inventories (you can't secure equipment you don't know exists), role-based access with multi-factor authentication for remote sessions, OT-specific monitoring tools that understand industrial protocols instead of generating false positives, tightly scoped and logged vendor access, tested offline backups of PLC and HMI configurations, and cross-training so IT and OT teams understand each other's constraints. Standards like IEC 62443 and NERC-CIP provide a structured baseline to build against.


# Poka-Yoke (Mistake-Proofing): Definition, Types & Examples

Every day, skilled operators make small mistakes: a component installed backwards, a step skipped during a rush order, a measurement misread at the end of a shift. The usual response is more training, more warning signs, more reminders to slow down and pay attention. It rarely works for long, because the mistake was never really a training problem.

Poka yoke is the alternative: instead of asking people to be perfect, you design the process so the mistake becomes physically impossible, or impossible to miss the moment it happens. Toyota built this into its production system decades ago, and manufacturers that adopt it consistently cut defect rates without adding inspection headcount.

## What Does Poka Yoke (Often Misspelled as Bokayoke or Poke Yoke) Mean and Where Did It Come From?

Poka yoke (pronounced "POH-kah YOH-kay") is a Japanese term that means "mistake-proofing" or "error prevention." The phrase comes from &#x2A;*"poka o yokeru" (ポカを避ける)**, literally, avoiding an unthinkably bad move in the game of shogi. While it's sometimes misspelled as bokayoke or poke yoke, and formally written as poka-yoke with a hyphen, the correct term is **poka yoke**.

In 1961, a Japanese electronics plant faced a staggering 25% defect rate. Workers kept missing tiny springs in switch assemblies, not due to carelessness, but because the repetitive handling of microscopic components made mistakes inevitable.

Toyota engineer [Shigeo Shingo](https://en.wikipedia.org/wiki/Shigeo_Shingo){rel="&#x22;nofollow&#x22;"} introduced a simple but revolutionary solution: a fixture holding exactly two springs for each assembly. Workers had to remove both springs before starting their task, instantly highlighting any incomplete assembly. As a result, defects dropped to zero overnight, without additional training, a case Shingo later documented himself in [*Zero Quality Control: Source Inspection and the Poka-Yoke System*](https://www.routledge.com/Zero-Quality-Control-Source-Inspection-and-the-Poka-Yoke-System/Shingo/p/book/9780915299072){rel="&#x22;nofollow&#x22;"} (Productivity Press, 1986).

Originally called &#x2A;*"baka-yoke" (idiot-proofing)**, the technique was renamed **poka yoke** after a worker objected, emphasizing that human errors are natural, not a reflection of intelligence.

Shingo made a key distinction between human mistakes and production defects. Mistakes happen, they're part of being human. Defects occur when those mistakes reach the customer. Poka yoke focuses on designing processes so mistakes are immediately detected and corrected, eliminating defects at the source. This philosophy, which Toyota traces in its own account of the system, [*Toyota Production System: Beyond Large-Scale Production*](https://www.routledge.com/Toyota-Production-System-Beyond-Large-Scale-Production/Ohno/p/book/9780915299140){rel="&#x22;nofollow&#x22;"} (Productivity Press, 1988), and which Jeffrey Liker later analyzed in [*The Toyota Way*](https://en.wikipedia.org/wiki/The_Toyota_Way){rel="&#x22;nofollow&#x22;"} (McGraw-Hill, 2004), shifts manufacturing focus: rather than trying to perfect human behavior, perfect the systems in which humans work.

## Poka Yoke Definition?

Poka yoke is a systematic approach that uses automatic devices or methods to either make errors impossible or make them immediately obvious once they occur. It's any mechanism that helps equipment operators avoid mistakes by preventing, correcting, or drawing attention to human errors as they happen.

:cta-image{alt="Arch Systems scales automation across complex manufacturing environments with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/arch-systems-book-demo.png"}

The poka yoke meaning extends beyond simple error prevention. Rather than treating errors as moral failures or training deficiencies, it treats them as design problems, the lean manufacturing approach James Womack and Daniel Jones frame in [*Lean Thinking*](https://www.lean.org/store/book/lean-thinking-2nd-edition/){rel="&#x22;nofollow&#x22;"} (Free Press, 2003), which recognizes that even the most skilled workers experience moments of distraction, fatigue, or cognitive overload.

Traditional quality control detects defects after they occur, requiring inspection, rework, and often scrapping of materials, the approach outlined in the [ASQ's *Certified Quality Engineer Handbook*](https://asq.org/quality-press){rel="&#x22;nofollow&#x22;"} (American Society for Quality, 2013). The poka yoke approach instead prevents defects during production by making errors physically impossible or immediately visible. This prevention-first approach creates a cascading effect: quality control teams focus on complex issues rather than basic errors, workers gain confidence in their processes, customer satisfaction improves through consistent product quality, and excellence becomes the natural outcome rather than a heroic achievement.

## Why Is Poka Yoke Important for Manufacturers?

The impact of mistake-proofing extends far beyond just catching errors. By designing assembly processes that are mistake-proof, poka yoke prevents defects from occurring in the first place rather than inspecting quality issues later. Companies achieve defect rates measured in parts per million rather than percentages.

Errors in manual assembly lead to increased scrap rates, rework, and delays, all contributing to higher production costs. By eliminating errors at the source, the cost of mistakes within a company is reduced significantly. Companies implementing poka yoke techniques saw a 25% increase in productivity, with time previously spent correcting errors now available for value-added activities.

Mistake-proofing creates safer processes by eliminating conditions that lead to accidents. When errors can literally mean life or death (as in pharmaceutical manufacturing), poka yoke becomes mission-critical. Workers experience less frustration from rework and greater confidence in their processes, leading to improved morale and a 20% improvement in customer satisfaction through consistent product quality.

## Poka Yoke Types?

Understanding the types of poka yoke helps you choose the right approach for your specific error prevention needs.

The **contact method** identifies product defects by testing the product's shape, size, color, or other physical attributes. This uses physical design features to make mistakes impossible. Diesel fuel nozzles are sized larger than gasoline tank openings, you literally can't put diesel in a gas car. USB-C connectors only fit one way, preventing incorrect insertion. Parts with unique shapes only fit correctly in assembly fixtures, and machine guards prevent equipment operation until properly closed. This is the most effective mistake-proofing method because it makes errors physically impossible.

**Fixed-value methods** often involve measurement devices such as scales or counters to prevent or identify nonconformances. These build the right limits directly into your tools. Torque wrenches automatically stop at correct force. Parts trays hold exactly the number of components needed, leftovers indicate a missing part. Automated pill dispensers count exact doses, weight verification systems ensure complete assemblies, and digital counters track the number of operations performed. If there are leftover parts or incorrect counts, something's wrong, and you know immediately.

**Motion-step methods** focus on ensuring operators perform the right steps in the correct sequence. These force the correct sequence of operations. Lockout/tagout systems prevent equipment access until safety steps are complete. CNC machines require tool verification before program execution. Assembly stations physically prevent advancement until the current step is finished, sequential interlocks ensure proper startup and shutdown procedures, and guided work instructions must be completed in order. These turn complex procedures into foolproof, step-by-step processes.

These detection principles aren't limited to physical manufacturing either, Harry Robinson documented the same techniques applied to early defect detection in software testing, in his paper ["Using Poka-Yoke Techniques for Early Defect Detection"](https://www.semanticscholar.org/paper/Using-Poka-Yoke-Techniques-for-Early-Defect-Robinson/606988be74e39106b4ef3ed30472045bdc2b25b4){rel="&#x22;nofollow&#x22;"} presented at the Sixth International Conference on Software Testing, Analysis and Review (STAR'97). Beyond these three detection methods, poka yoke systems function in two fundamental ways: control-based and warning-based. Control poka yoke actually prevents the mistake from being made, making it mechanically or electronically impossible for errors to occur. Think of a car transmission requiring "Park" or "Neutral" to start, or computer forms that won't submit until all required fields are filled. Use this when errors must be prevented entirely, especially for safety-critical operations. Warning-based poka yoke alerts operators to occurring or soon-to-occur defects, relying on human intervention to stop and correct errors. Examples include backup sensors beeping when you're too close to an obstacle, warning lights indicating missing components, or Outlook reminding you about missing attachments. The key difference: control systems stop the process automatically; warning systems rely on human response.

## What Are the 6 Steps of Poka Yoke Mistake-Proofing?

Implementing poka yoke follows a systematic six-step process that ensures effective error prevention.

**Step 1: Identify the Problem.** Create a detailed process flowchart mapping every operation, no matter how small. Review each step to determine where human errors are likely to occur, which can involve using the 5 Whys technique. Where do defects occur most frequently? Which errors have the highest impact? Use a [Pareto chart](https://flowfuse.com/blog/2025/08/pareto-chart-manufacturing-guide/) to prioritize, typically 80% of defects come from 20% of causes, so you focus your poka yoke efforts where they'll have maximum impact.

**Step 2: Analyze Root Causes.** Once every potential error is found, work through the process to find the root cause. Don't just identify when errors occur, understand why they happen. Use techniques like 5 Whys analysis, fishbone diagrams, process mapping, Failure Mode and Effects Analysis (FMEA), and gemba walks (go see where work happens). Understanding root causes prevents implementing complex solutions for simple problems.

**Step 3: Design the Solution.** Design solutions in the process to eliminate the risk of the error ever happening, which can include eliminating the step or replacing it with a mistake-proof step. The solution hierarchy from most to least effective, detailed in Thomas Pyzdek and Paul Keller's [*The Six Sigma Handbook*](https://accessengineeringlibrary.com/browse/six-sigma-handbook-fourth-edition){rel="&#x22;nofollow&#x22;"} (McGraw-Hill Education, 2014), includes elimination (remove the error-prone step entirely), replacement (substitute with an error-proof alternative), facilitation (make correct actions significantly easier than errors), detection (identify errors immediately when they occur), and mitigation (minimize effects if errors reach this point). The four key principles are elimination, prevention, detection, and mitigation.

**Step 4: Choose the Implementation Method.** Select the appropriate mistake-proofing technique based on your specific situation. Consider inspection methods like source inspection (checks before the process step occurs), self-inspection (workers check their own work immediately), or successive inspection (next worker verifies previous step). Choose setting functions such as contact/physical checks, fixed-value counting or weighing, motion-step sequence verification, or information enhancement for visibility. Decide on regulatory functions including warning signals (lights, buzzers, colors) or control mechanisms (preventing advancement).

**Step 5: Test the Poka Yoke.** A poka yoke pilot project will help you iron out any issues with the process before introducing it to your shop floor. Does it prevent or detect the target error? Does it slow down production unacceptably? Can it create new safety hazards? Does it introduce new failure modes? Do operators understand and accept it? Is it cost-effective? Start small, validate effectiveness, then scale up.

**Step 6: Implement and Monitor.** Roll out the solution with proper training and documentation. But implementation isn't the end, it's the beginning of continuous improvement. Monitor error rates before and after implementation, track effectiveness metrics, gather operator feedback, make adjustments as needed, apply successful solutions to similar processes, and update FMEA documentation. Remember: poka yoke is about continuous improvement, not one-time fixes.

## Poka Yoke Examples

The automobile industry showcases poka yoke transformative applications across assembly lines and production processes. Toyota's implementation includes fixtures that physically prevent incorrect part installation and sensors that detect missing components before products advance to subsequent stations. These systems have helped achieve defect rates measured in parts per million rather than percentages, setting industry standards for quality excellence.

Electronics manufacturing demonstrates sophisticated applications in high-precision environments. Component placement machines verify correct parts before PCB assembly, preventing costly defects that would be difficult or impossible to correct later. Color-coded component storage and automated inventory systems ensure operators select correct parts while maintaining production speed and efficiency.

Pharmaceutical production represents perhaps the most critical mistake-proofing applications, where errors can literally mean life or death. Automated dosing systems prevent medication errors, while segregated production lines eliminate cross-contamination risks. Barcode scanning and weight verification create multiple checkpoints that ensure accurate formulations without slowing production processes.

You encounter mistake-proofing daily in everyday life, often without noticing. In your car, manual transmissions require clutch depression to start, automatic transmissions require "Park" or "Neutral" to start, seat belt warnings sound until buckled, and keys must be in the ignition to remove from "Park." Technology examples include USB connectors that only fit one orientation, spell-check catching errors as you type, email reminders about missing attachments, forms preventing submission until all fields are complete, and phone warnings before deleting photos. Around your home and office, overflow drains prevent bathtub floods, three-prong plugs ensure proper grounding, microwave doors stop operation when opened, hotel room keycards control energy consumption, and pen clips retract tips to prevent pocket damage.

## Is Poka Yoke Right for You?

Poka yoke is particularly valuable when you're experiencing repetitive defects that training alone can't fix, high-volume production where small error rates create massive waste, safety-critical operations where mistakes could cause injury, complex assemblies with multiple potential error points, or processes where inspection after production is too late or too expensive.

However, poka yoke isn't always the answer. For truly unique, one-off custom work, the investment in mistake-proofing devices may not be justified. When processes change frequently, rigid mistake-proofing systems can become obstacles. In highly creative work where "mistakes" sometimes lead to innovation, too much control can stifle breakthroughs.

The key question: Are errors systematic or random? If the same mistakes happen repeatedly, poka yoke is your solution. If every error is unique and unpredictable, focus on training and skill development instead.

Getting this right in practice comes down to two things the six steps above don't fully capture: involve the operators who'll use the system while you're still designing it, since their buy-in is what turns a new mistake-proofing device from resistance into adoption; and start with your highest-impact, simplest problem rather than your most complex one, so you build confidence and momentum before tackling harder cases.

## Modern Digital Poka Yoke: Engineering Mistake-Proof Systems

The future of poka yoke increasingly incorporates Industry 4.0 technologies that expand traditional concepts. IoT sensors provide real-time capabilities that detect deviations instantly, while machine learning algorithms identify subtle patterns that predict potential failures before they occur. These advanced digital tools complement rather than replace fundamental poka yoke principles.

Modern smart manufacturing systems integrate digital work instructions that guide operators through complex procedures step-by-step, ensuring consistency while accommodating process variations. Adaptive tooling automatically adjusts parameters based on real-time measurements, preventing specification deviations while maintaining production efficiency.

FlowFuse enables sophisticated poka yoke implementations by connecting IoT sensors, machine data, and quality control systems in real-time workflows. Manufacturing teams can build automated solutions that trigger immediate alerts, stop processes when deviations occur, and guide operators through corrective actions, all without complex programming or expensive custom solutions.

## Conclusion

The poka yoke technique represents more than a quality improvement method, it embodies a fundamental shift toward designing human error out of manufacturing processes. By accepting human fallibility and engineering around it, manufacturers achieve consistent quality while reducing costs and improving employee satisfaction.

The method's enduring relevance in an era of smart manufacturing demonstrates that the most powerful solutions often combine simple principles with sophisticated execution. Whether you're implementing basic mistake-proofing devices or advanced IoT-enabled systems, the core philosophy remains unchanged: make errors impossible, or make them immediately obvious.

The question isn't whether poka yoke works, decades of success across industries prove it does. The question is: which errors in your process are you ready to eliminate forever?


# Preventive Maintenance in Manufacturing: Avoid Multi-Million Dollar Equipment Failures

At 2:47 AM on a Tuesday, a [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[15]{.mord}[b]{.mord.mathnormal}[e]{.mord.mathnormal}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[b]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[ug]{.mord.mathnormal style="margin-right:0.0359em;"}[h]{.mord.mathnormal}[t]{.mord.mathnormal}[d]{.mord.mathnormal}[o]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[na]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 2 million production line.

While this specific incident is illustrative, the failure pattern it represents is all too real and systemic. According to recent industry research, unplanned downtime outages last an average of four hours and cost an average of [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[2]{.mord}[mi]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[i]{.mord.mathnormal}[o]{.mord.mathnormal}[n]{.mord.mathnormal}[p]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[in]{.mord.mathnormal}[c]{.mord.mathnormal}[i]{.mord.mathnormal}[d]{.mord.mathnormal}[e]{.mord.mathnormal}[n]{.mord.mathnormal}[t]{.mord.mathnormal}[.]{.mord}[T]{.mord.mathnormal style="margin-right:0.1389em;"}[h]{.mord.mathnormal}[ese]{.mord.mathnormal}[b]{.mord.mathnormal}[e]{.mord.mathnormal}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[ai]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[u]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[es]{.mord.mathnormal}[ha]{.mord.mathnormal}[pp]{.mord.mathnormal}[e]{.mord.mathnormal}[na]{.mord.mathnormal}[cr]{.mord.mathnormal style="margin-right:0.0278em;"}[oss]{.mord.mathnormal}[man]{.mord.mathnormal}[u]{.mord.mathnormal}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[a]{.mord.mathnormal}[c]{.mord.mathnormal}[t]{.mord.mathnormal}[u]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[a]{.mord.mathnormal}[c]{.mord.mathnormal}[i]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[i]{.mord.mathnormal}[t]{.mord.mathnormal}[i]{.mord.mathnormal}[es]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[or]{.mord.mathnormal style="margin-right:0.0278em;"}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[d]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[i]{.mord.mathnormal}[d]{.mord.mathnormal}[e]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[i]{.mord.mathnormal}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[p]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[i]{.mord.mathnormal}[c]{.mord.mathnormal}[t]{.mord.mathnormal}[ab]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[eco]{.mord.mathnormal}[n]{.mord.mathnormal}[s]{.mord.mathnormal}[i]{.mord.mathnormal}[s]{.mord.mathnormal}[t]{.mord.mathnormal}[e]{.mord.mathnormal}[n]{.mord.mathnormal}[cy]{.mord.mathnormal style="margin-right:0.0359em;"}[]{.mspace style="margin-right:0.2778em;"}[:]{.mrel}[]{.mspace style="margin-right:0.2778em;"}]{.base}[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[e]{.mord.mathnormal}[m]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[e]{.mord.mathnormal}[n]{.mord.mathnormal}[cy]{.mord.mathnormal style="margin-right:0.0359em;"}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[p]{.mord.mathnormal}[ai]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[s]{.mord.mathnormal}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[o]{.mord.mathnormal}[v]{.mord.mathnormal style="margin-right:0.0359em;"}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[t]{.mord.mathnormal}[im]{.mord.mathnormal}[e]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[ab]{.mord.mathnormal}[or]{.mord.mathnormal style="margin-right:0.0278em;"}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[e]{.mord.mathnormal}[x]{.mord.mathnormal}[p]{.mord.mathnormal}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[i]{.mord.mathnormal}[t]{.mord.mathnormal}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[p]{.mord.mathnormal}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[t]{.mord.mathnormal}[s]{.mord.mathnormal}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[d]{.mord.mathnormal}[e]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[a]{.mord.mathnormal}[y]{.mord.mathnormal style="margin-right:0.0359em;"}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[c]{.mord.mathnormal}[u]{.mord.mathnormal}[s]{.mord.mathnormal}[t]{.mord.mathnormal}[o]{.mord.mathnormal}[m]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[or]{.mord.mathnormal style="margin-right:0.0278em;"}[d]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[s]{.mord.mathnormal}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[an]{.mord.mathnormal}[d]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[a]{.mord.mathnormal}[t]{.mord.mathnormal}[i]{.mord.mathnormal}[o]{.mord.mathnormal}[n]{.mord.mathnormal}[s]{.mord.mathnormal}[hi]{.mord.mathnormal}[p]{.mord.mathnormal}[d]{.mord.mathnormal}[ama]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[e]{.mord.mathnormal}[.]{.mord}[A]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[ma]{.mord.mathnormal}[co]{.mord.mathnormal}[m]{.mord.mathnormal}[p]{.mord.mathnormal}[o]{.mord.mathnormal}[n]{.mord.mathnormal}[e]{.mord.mathnormal}[n]{.mord.mathnormal}[tt]{.mord.mathnormal}[ha]{.mord.mathnormal}[t]{.mord.mathnormal}[co]{.mord.mathnormal}[u]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[d]{.mord.mathnormal}[ha]{.mord.mathnormal}[v]{.mord.mathnormal style="margin-right:0.0359em;"}[e]{.mord.mathnormal}[b]{.mord.mathnormal}[ee]{.mord.mathnormal}[n]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[pl]{.mord.mathnormal style="margin-right:0.0197em;"}[a]{.mord.mathnormal}[ce]{.mord.mathnormal}[dd]{.mord.mathnormal}[u]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[sc]{.mord.mathnormal}[h]{.mord.mathnormal}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[u]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[e]{.mord.mathnormal}[dd]{.mord.mathnormal}[o]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[n]{.mord.mathnormal}[t]{.mord.mathnormal}[im]{.mord.mathnormal}[e]{.mord.mathnormal}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[or]{.mord.mathnormal style="margin-right:0.0278em;"}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 800.

The real tragedy? Every signal was there. Vibration readings had climbed 40% over six weeks. Temperature spikes occurred during peak loads. Acoustic signatures screamed impending failure. But without systematic monitoring, these warnings vanished into the noise of daily operations.

This isn't a maintenance story, it's a data story. And it's playing out in manufacturing facilities worldwide every day. According to Forbes, unplanned downtime can cost manufacturing companies a whopping [[]{.katex-mathml}[[[]{.strut style="height:0.9463em;vertical-align:-0.1944em;"}[50]{.mord}[bi]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[i]{.mord.mathnormal}[o]{.mord.mathnormal}[n]{.mord.mathnormal}[p]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[y]{.mord.mathnormal style="margin-right:0.0359em;"}[e]{.mord.mathnormal}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[.]{.mord}[S]{.mord.mathnormal style="margin-right:0.0576em;"}[i]{.mord.mathnormal}[e]{.mord.mathnormal}[m]{.mord.mathnormal}[e]{.mord.mathnormal}[n]{.mord.mathnormal}[[s]{.mord.mathnormal}[[[[[[]{.pstrut style="height:2.7em;"}[[[′]{.mord.mtight}]{.mord.mtight}]{.sizing.reset-size6.size3.mtight}]{style="top:-3.063em;margin-right:0.05em;"}]{.vlist style="height:0.7519em;"}]{.vlist-r}]{.vlist-t}]{.msupsub}]{.mord}[2024]{.mord}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[p]{.mord.mathnormal}[or]{.mord.mathnormal style="margin-right:0.0278em;"}[t]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[v]{.mord.mathnormal style="margin-right:0.0359em;"}[e]{.mord.mathnormal}[a]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[s]{.mord.mathnormal}[t]{.mord.mathnormal}[ha]{.mord.mathnormal}[t]{.mord.mathnormal}[u]{.mord.mathnormal}[n]{.mord.mathnormal}[pl]{.mord.mathnormal style="margin-right:0.0197em;"}[ann]{.mord.mathnormal}[e]{.mord.mathnormal}[dd]{.mord.mathnormal}[o]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[n]{.mord.mathnormal}[t]{.mord.mathnormal}[im]{.mord.mathnormal}[e]{.mord.mathnormal}[n]{.mord.mathnormal}[o]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[cos]{.mord.mathnormal}[t]{.mord.mathnormal}[s]{.mord.mathnormal}[F]{.mord.mathnormal style="margin-right:0.1389em;"}[or]{.mord.mathnormal style="margin-right:0.0278em;"}[t]{.mord.mathnormal}[u]{.mord.mathnormal}[n]{.mord.mathnormal}[e]{.mord.mathnormal}[Gl]{.mord.mathnormal style="margin-right:0.0197em;"}[o]{.mord.mathnormal}[ba]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[500]{.mord}[co]{.mord.mathnormal}[m]{.mord.mathnormal}[p]{.mord.mathnormal}[ani]{.mord.mathnormal}[es]{.mord.mathnormal}[11]{.mord}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 1.5 trillion, up from $864 billion two years ago.

## The Predictable Science of Equipment Death

Equipment failures aren't random disasters, they're predictable processes that unfold over weeks or months, leaving digital breadcrumbs that reveal exactly when intervention will be most cost-effective.

Reliability engineers call this the P-F curve: the measurable interval between when a potential failure (P) becomes detectable and functional failure (F) occurs. For rotating equipment like motors and pumps, this window typically spans 6-12 weeks. For hydraulic systems, 2-8 weeks. For electronic components, days to months.

![P-F Curve.](https://flowfuse.com/blog/2025/09/images/pf-curve.jpg){dataZoomable=""}&#x2A;P-F Curve.*

During this P-F interval, equipment broadcasts its distress through dozens of measurable parameters:

- **Vibration patterns** shift as bearings wear and alignments drift
- **Power consumption** increases as friction rises and efficiency drops
- **Temperature profiles** change as lubricants degrade and clearances widen
- **Acoustic signatures** evolve as mechanical tolerances exceed design limits
- **Process variables** drift as equipment performance degrades

The math is brutal. According to research by Eptura, on-demand work orders generally take twice as long as preventive maintenance, cutting associated labor costs in half through proactive approaches. A comprehensive study by JLL (Jones Lang LaSalle) analyzing 14 million square feet of mixed building types found that preventive maintenance produces an astounding 545% return on investment.

## Why Over Half of Manufacturers Still Play Failure Roulette

Despite overwhelming evidence favoring preventive approaches, many facilities still operate critical equipment on run-to-failure strategies. The reason isn't ignorance, it's infrastructure complexity and historical implementation challenges.

Traditional preventive maintenance software promised comprehensive monitoring but delivered integration nightmares. Each device required custom programming, proprietary gateways, and specialized expertise. Implementation projects stretched 12-18 months, cost hundreds of thousands of dollars, and often failed to deliver promised capabilities.

Meanwhile, production environments grew increasingly complex. A single line now might include:

- 1990s CNC machines speaking serial protocols
- 2000s PLCs using Modbus communication
- 2010s robots on Ethernet/IP networks
- 2024 sensors transmitting via MQTT and other IoT protocols

Each system operates in isolation, generating valuable data that remains trapped behind incompatible interfaces.

## The Platform Revolution: Universal Data, Unified Insights

Modern industrial data platforms are eliminating these barriers by treating connectivity as a solved problem rather than a custom project.

Instead of requiring expensive integration for each device type, these platforms provide universal connectivity out of the box. Legacy equipment, modern sensors, and everything in between can communicate through a single interface without gateways, converters, or custom programming.

This fundamental shift changes the economics of comprehensive monitoring. Instead of monitoring a few critical machines with dedicated systems, manufacturers can monitor everything, from primary production equipment to auxiliary systems like compressed air, HVAC, and power distribution.

Research indicates that 95% of predictive maintenance adopters reported a positive ROI, with 27% of these reporting amortization in less than a year.

## Evidence-Based Results from Leading Manufacturers

The transformation from reactive to predictive maintenance is delivering measurable results across industries:

**Automotive Manufacturing:** Major automotive suppliers have achieved 50% reduction in unplanned downtime after implementing comprehensive equipment monitoring across their facilities. The key wasn't just monitoring critical assets, it was monitoring everything, creating a complete picture of facility health.

**Electronics Production:** Leading electronics manufacturers report 25% reduction in maintenance costs by connecting previously isolated systems on unified data platforms. Maintenance teams can finally see relationships between equipment performance and environmental factors.

**Industrial Equipment:** According to the U.S. Department of Energy, predictive maintenance helps enterprises gain remarkable results such as a tenfold increase in ROI, 70-75% decrease in breakdowns, 25-30% reduction in costs, and 35-45% reduction in downtime.

## FlowFuse: The Open, Scalable, and Flexible Industrial Data Platform

FlowFuse represents the next evolution in industrial data platforms, designed by engineers who understand both the promise and frustrations of traditional systems.

Built on Node-RED, the open-source standard for industrial connectivity, FlowFuse eliminates integration barriers that have historically made comprehensive monitoring expensive and complex. Native support for almost all industrial protocols and systems means any device that communicates digitally can connect without custom development.

But connectivity is just the foundation. FlowFuse's visual programming environment enables engineers to build sophisticated monitoring applications using drag-and-drop interfaces. Need to correlate motor vibration with production load? Create custom dashboards for different user roles? Set up automated alerts based on complex conditions? All possible without writing code.

The platform's AI-powered editor goes further by reducing the development effort for engineers.

For enterprise users, FlowFuse provides several essential features to support large-scale, collaborative, and secure industrial data operations. This includes DevOps tools and Remote Device Management, which streamline the deployment of applications and allow teams to remotely monitor and update their connected devices. To facilitate teamwork and project management, the platform incorporates Snapshot & Version Control and Real-Time Team Collaboration, enabling multiple people to work together on projects and easily track changes. For system reliability, FlowFuse offers High Availability, and to simplify user access while boosting security, it provides Single Sign-On (SSO). Additionally, Role-Based Access Control is a key security feature that lets administrators manage and restrict data access for different users.

Most importantly, FlowFuse uses transparent pricing that encourages comprehensive data collection. No per-tag penalties, no volume restrictions, just straightforward costs that scale with business value rather than data points monitored.

## The New Maintenance Economics

Companies implementing comprehensive equipment monitoring through modern data platforms are rewriting the economics of manufacturing operations. The financial picture changes almost immediately: emergency repairs drop by as much as &#x2A;*60–80%** as failures shift from unexpected crises to planned interventions. Overall maintenance spending falls by &#x2A;*12–18%** as teams allocate resources more efficiently, while spare parts inventories shrink by &#x2A;*30–50%** because demand becomes predictable rather than chaotic.

The impact extends well beyond cost savings. Equipment life stretches by &#x2A;*20–40%** when replacement is driven by condition rather than arbitrary schedules. Overall Equipment Effectiveness (OEE) climbs by &#x2A;*10–20%** as downtime disappears from production schedules, and energy consumption drops by &#x2A;*5–15%** as machines run closer to their designed efficiency.

Operational excellence amplifies across the board. Companies see on-time delivery rates climb past &#x2A;*95%**, far outpacing the industry average of 75% in reactive environments. Customer satisfaction rises in parallel, supported by the reliability of consistent delivery. Workforce safety also improves as proactive monitoring identifies hazards before they escalate.

According to research by **McKinsey & Company**, the cumulative effect of these improvements is profound: organizations that adopt data-driven decision making are on average **5% more productive** and **6% more profitable** than competitors who remain locked in reactive cycles.

## The Implementation Reality

The path from reactive to proactive maintenance is clearer than ever, but success requires more than software selection, it requires cultural transformation.

Start with pain point identification. Which equipment failures cause the most disruption? Where are emergency repair costs highest? What assets have the longest replacement lead times? These become your monitoring priorities.

Focus on quick wins that build organizational confidence. Monitor 3-5 critical assets that represent different failure modes and equipment types. Establish baselines, implement basic condition monitoring, and measure results rigorously.

The US Department of Energy reports a projected ROI of ten times the investment for organizations implementing predictive maintenance strategies.

Most importantly, treat this as a capability-building exercise, not a technology project. The goal isn't just preventing failures, it's developing organizational competencies in data-driven decision making that enable continuous operational improvement.

## Taking Action

The business case is overwhelming. The technology barriers are eliminated. The competitive advantages are clear and measurable.

The question isn't whether to implement comprehensive equipment monitoring, it's how quickly you can build capabilities that deliver sustainable competitive advantages.

Calculate your current failure costs honestly. Include not just repair expenses but lost production, customer impact, and opportunity costs. Identify your most critical assets and pain points. Evaluate platforms that provide universal connectivity without integration complexity.

The manufacturers moving decisively are gaining first-mover advantages in operational excellence that their competitors will struggle to match. Those delaying risk permanent disadvantage in an increasingly data-driven industry.

**Ready to transform equipment failures from crisis events into predictable costs?** [Discover how FlowFuse enables comprehensive equipment monitoring](https://flowfuse.com/book-demo/) that delivers measurable competitive advantages from day one.

## References

1. TeamSense (2024). *High Cost of Downtime in Manufacturing & How to Reduce It*.
2. IIoT World (2023). *The Actual Cost of Downtime in Manufacturing*.
3. Evocon (2024). *Cost of Downtime in Manufacturing: Insights & Implications*.
4. IDS Data (2025). *The Real Cost of Downtime in Manufacturing*.
5. Eptura (2025). *Workplace Index: Preventive Maintenance ROI*.
6. IoT Analytics (2024). *Predictive Maintenance Market: 5 Highlights*.
7. Polaris Market Research (2024). *Predictive Maintenance Market Report, 2024–2032*.
8. MoldStud (2024). *ROI Benefits of Predictive Maintenance*.
9. Sensorfy (2023). *How to Calculate Predictive Maintenance ROI*.
10. MicroMain (2024). &#x2A;Preventive Maintenance ROI of 545%*.
11. ScienceDirect (2025). *Systematic Review of Predictive Maintenance Practices*.
12. IIoT World (2024). *Predictive Maintenance: Hidden ROI Driver*.

*Additional references: U.S. Department of Energy (predictive maintenance effectiveness), McKinsey & Company (productivity studies), Siemens (True Cost of Downtime reports).*


# Modbus RTU (RS485/RS422/RS232) Communications with FlowFuse

Modbus RTU is one of the most widely used communication protocols in industrial automation. It allows you to read sensor data, monitor equipment status, and control devices through a simple master-slave architecture. This guide will walk you through everything you need to know to start reading and writing industrial data with FlowFuse (a platform built around Node-RED with enterprise-level capabilities).

Whether you're connecting a single sensor or building a comprehensive industrial monitoring system, this step-by-step guide will show you how to leverage FlowFuse's powerful capabilities to bridge the gap between legacy industrial devices and modern data systems.

## Understanding Modbus RTU Basics

Modbus RTU operates on a **master–slave system**. Unlike its TCP counterpart, it runs over serial connections (RS485/RS422/RS232), making it extremely reliable in environments where network connectivity may be unstable. The protocol has been battle-tested in harsh conditions for decades, which is why it is still used in everything from simple temperature sensors to complex PLCs.

In a FlowFuse setup, the instance acts as the master, initiating all communication. Devices such as sensors, meters, and controllers act as slaves, responding only when addressed. Each slave has a unique address from 1 to 247, with 0 reserved for broadcast messages. Communication follows a simple pattern: the master sends a request, the addressed slave responds, and the master processes the response before moving to the next device.

### Device Data Types

Devices organize data into four main types, each with a specific purpose:

- **Coils (Digital Outputs)** – Remote switches you can turn on/off from FlowFuse, used for motors, pumps, relays, or alarms.
- **Discrete Inputs (Digital Inputs)** – Read-only status points that indicate the state of buttons, doors, or alarms.
- **Input Registers (Analog Inputs)** – Read-only values representing measurements such as temperature, pressure, or flow.
- **Holding Registers (Analog Outputs/Settings)** – Read/write values for setpoints, timers, and configuration parameters.

**Note:** Coils and discrete inputs are single-bit (ON/OFF), while registers store 16-bit values that may require scaling depending on the device.

### Register Addressing

Addressing can be confusing because manufacturers document it differently:

- **Zero-based** – Modbus standard (first register = 0).
- **One-based** – Some manuals start counting at 1 (subtract 1 in FlowFuse).
- **Offset-based** – Registers like 40001 or 30001 require subtracting the base number to get the actual address.

**Example:** If a manual shows “Temperature = 40001,” FlowFuse should use address **0**. Always refer to the device’s “Register Map” for clarity.

By understanding the **master-slave control, data types, and addressing**, you can reliably communicate with your devices and make the most of Modbus RTU in FlowFuse.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

## Getting Started

Let’s start by setting up the basics before connecting Modbus RTU devices to FlowFuse.

### Prerequisites

Before diving in, make sure you have the following ready:

- **Node-RED instance** – A running Node-RED instance. The quickest way to get one ready for production is with FlowFuse. Simply [sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and [create and set up a remote instance](https://flowfuse.com/blog/2025/09/installing-node-red/), and you’ll have a managed Node-RED environment running in minutes.
- **Node-RED Modbus nodes** – Installable via the Palette Manager (`node-red-contrib-modbus`).
- **Modbus-enabled device** – Such as a sensor, PLC, or meter, along with its register map documentation.
- **Serial interface** – For example, a USB-to-RS485 converter to physically connect your Modbus devices. Connect the &#x2A;*A (+)** and &#x2A;*B (–)** terminals of the RS485 adapter to the device, add termination resistors if the line is long or has multiple devices, and note the serial port path (e.g., `/dev/ttyUSB0` on Linux or `COM1` on Windows).

## Reading Data

Reading data from Modbus slaves in FlowFuse is straightforward. The process is the same regardless of which data type you want to read.

1. Drag the **Modbus Read** node onto the FlowFuse canvas. Double-click it to open the configuration. Enter the **Unit ID** (slave address), select the **data type** you want to read, specify the **starting address**, set the **quantity** of values to read, and define the **poll rate** (how often data should be read).

![Modbus Read node configured to read data from a slave device.](https://flowfuse.com/blog/2025/09/images/modbus-read.png){dataZoomable=""}&#x2A;Modbus Read node configured to read data from a slave device.*

2. Click the &#x2A;*+** icon next to the *Server* field to add Modbus connection details.
3. In the server configuration window:
   - Set **Type** to *Serial*.
   - In the **Serial Port** field, use the dropdown or search option to see all available ports (e.g., `/dev/ttyUSB0` on Linux or `COM1` on Windows). Select the port to which your Modbus device is connected.
   - Configure the communication settings to match your device:
     - **Baud Rate**
     - **Data Bits**
     - **Stop Bits**
     - **Parity**
   :brThese values must match exactly with the Modbus device’s configuration; otherwise, the communication will fail.

![Serial port and communication settings for the Modbus device.](https://flowfuse.com/blog/2025/09/images/modbus-configuration.png){dataZoomable=""}&#x2A;Serial port and communication settings for the Modbus device.*

4. Connect the Modbus Read node to a **Debug** node and deploy your flow. If everything is set up correctly, you will start seeing live data from your Modbus device in the debug sidebar.

## Writing Data

Modbus RTU allows you to **write data back to devices**, enabling control of motors, relays, setpoints, and other outputs directly from FlowFuse.

Follow these steps to configure and test writing:

1. Drag the **Modbus Write** node onto the canvas. This node will send data to your Modbus device.
2. Double-click the node and set:
   - **Unit ID** – the slave address of your device.
   - **Data type** – choose one of:
     - *Force Single Coil* – write one digital output.
     - *Force Multiple Coils* – write several digital outputs at once.
     - *Preset Single Register* – write one analog/config value.
     - *Force Multiple Registers* – write several analog values at once.
   - **Address** – the target coil or register.
   - **Quantity** – only for multiple writes, set the number of values you will send.
   :br![Writing a single coil using the Modbus Write node.](https://flowfuse.com/blog/2025/09/images/write-single-coil.png){dataZoomable=""}&#x2A;Writing a single coil using the Modbus Write node.*:br![Writing multiple coils using the Modbus Write node.](https://flowfuse.com/blog/2025/09/images/write-multi-coils.png){dataZoomable=""}&#x2A;Writing multiple coils using the Modbus Write node.*
3. Connect an **Inject** node to the Modbus Write node to send values:
   - **Single Coil/Register:** send a boolean (`true`/`false`) for coils or a number for registers.
   - **Multiple Coils/Registers:** send an array corresponding to each value.
   :br&#x2A;*Examples:**
   - `[true, false, true]` → Coils 0, 1, 2
   - `[25, 50, 75]` → Holding Registers 0, 1, 2
4. Deploy the flow and press **Inject**. The Modbus device should update immediately.

**Tip:** Use a &#x2A;*UI input (slider, switch, or numeric box)** from the [FlowFuse Dashboard](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"} instead of an Inject node for real-time control via a web interface.

## Scaling and Interpreting Values

Raw Modbus values often don’t make sense until you apply **scaling factors** or unit conversions.

- A temperature register might return `235`, which actually means **23.5 °C**.
- An energy meter might output `12345`, representing **12.345 kWh**.
- A pressure sensor could use two consecutive registers (32-bit values) that need decoding.

You can handle these conversions with simple **Function nodes** or **Change nodes** in FlowFuse.

**Example Function Node:**

```javascript
// Convert raw register value to temperature in °C
let raw = msg.payload[0];
msg.payload = raw / 10;
return msg;
```

This takes the raw register, divides it by 10, and gives you a clean, human-readable temperature.

**Tip:** You do not need to know JavaScript, simply use the **FlowFuse Expert**, which can generate a Function node for you from plain English instructions. For the most accurate results, provide sample data along with the scaling you want to achieve. You can learn more in this article: [FlowFuse Expert for Manufacturing](https://flowfuse.com/blog/2025/07/flowfuse-ai-assistant-better-node-red-manufacturing/).

**Best Practice:** Always keep a copy of the device’s **Register Map documentation** handy. It tells you which addresses map to which variables, and how to interpret them.

## Troubleshooting Tips

If things do not work on the first attempt, avoid frustration. Modbus is straightforward, but even small configuration mismatches can disrupt communication.

- Verify the **serial port** is correct and not already in use.
- Double-check **baud rate, data bits, stop bits, and parity**. Even a single mismatch will block communication.
- Ensure the **Unit ID** matches your device’s slave address.
- Keep your wiring neat. For longer cables, use **termination resistors** and twisted-pair shielded cables.
- Use a Modbus simulator or diagnostic tool to test the setup if the hardware isn’t responding.

## Conclusion

Modbus RTU has stood the test of time in industrial automation because it’s simple, reliable, and built for harsh environments. With FlowFuse, you can take this legacy protocol and give it **modern superpowers**:

- Collect real-time data from sensors and machines.
- Control devices directly from a web dashboard.
- Combine Modbus with MQTT, REST APIs, or databases to share data across your entire organization.
- Scale from a single sensor to a **factory-wide monitoring and control system**.

The real value comes when you stop treating Modbus as just a communication protocol and start using FlowFuse as the **bridge between industrial devices and enterprise systems**. From dashboards to alerts, from analytics to cloud integration, the possibilities are endless once the data is in your hands.

Modbus is one of several protocols FlowFuse uses to connect PLCs, see [how FlowFuse connects any PLC to MQTT, cloud, and enterprise systems](https://flowfuse.com/landing/plc/) for the full picture.


# What is 5S Checklist: Definition, Benefits, Implementation, and Template

Manufacturing environments face increasing pressure to eliminate waste, improve safety, and maintain quality standards. Disorganized workspaces contribute to production delays, safety incidents, and quality defects that directly impact operational performance. The 5S methodology addresses these challenges through systematic work area organization, but implementation requires consistent evaluation and measurement. A 5S checklist provides the structured framework necessary to assess, maintain, and improve work area organization standards across manufacturing operations.

## Understanding 5S Methodology

The 5S methodology originated in Japanese manufacturing and has become the gold standard for work area organization worldwide. The name comes from five Japanese words that each begin with 'S', representing a systematic approach to creating efficient, safe workspaces:

- **Sort (Seiri)** means removing everything that doesn't belong in your workspace. This involves ruthlessly eliminating "just in case" items that create clutter and reduce efficiency.
- **Set in Order (Seiton)** gives everything that remains a logical, designated home based on frequency of use and workflow patterns.
- **Shine (Seiso)** focuses on cleanliness that reveals problems early. Oil leaks, wear patterns, and safety hazards become immediately visible in clean environments.
- **Standardize (Seiketsu)** creates consistent procedures so everyone follows identical organizational principles across shifts and departments.
- **Sustain (Shitsuke)** builds the culture and accountability systems needed to maintain improvements permanently.

The challenge isn’t just understanding these concepts; it’s implementing them consistently across different operations.

## What Makes a 5S Checklist Essential

A 5S checklist transforms abstract organizational principles into concrete, measurable actions with specific evaluation criteria. Instead of subjective opinions about workspace organization, teams get objective standards: Is every tool in its designated shadow board outline? Are walkways completely obstacle-free? Can someone new find required materials within two minutes?

Beyond simple evaluation, these checklists serve as training tools for new employees, communication devices between shifts, historical records showing improvement trends, and accountability systems that prevent 5S from becoming another forgotten initiative.

## Essential 5S Checklist Items Every work area Needs

While each work environment requires specific evaluation criteria, certain fundamental items should be included in every 5S checklist. Here is a practical framework of 25 questions that you can adapt for your operations.

### Sort

- Are workstations free of unnecessary materials, tools, and equipment?
- Have outdated documents and reference materials been removed?
- Are broken or obsolete items properly tagged for disposal?
- Do storage areas contain only frequently used items?

### Set in Order

- Is every tool in its designated location with clear identification?
- Are frequently used items positioned within easy reach?
- Are visual management systems (labels, shadow boards, floor markings) clearly visible?
- Can workers retrieve needed items without searching or moving obstacles?

### Shine

- Are all surfaces, equipment, and floors properly cleaned?
- Are maintenance schedules current and inspection logs up-to-date?
- Are cleaning supplies readily available and properly stored?
- Are leaks, spills, and abnormal conditions immediately visible?

### Standardize

- Are work instructions current, accessible, and consistently followed?
- Do similar workstations follow identical organizational principles?
- Are all team members trained on current 5S standards?
- Are procedures regularly reviewed and updated?

### Sustain

- Do workers maintain organizational standards without constant supervision?
- Are team members actively identifying improvement opportunities?
- Do supervisors regularly participate in evaluations and improvements?
- Are 5S achievements recognized and celebrated?

## The Real Impact on Your Operations

Companies that implement 5S checklists consistently report dramatic improvements that go far beyond having a tidy workspace. Workers typically spend less time searching for tools and materials once proper organization takes hold. This isn't just about efficiency, it's about frustration levels and job satisfaction too.

Safety improvements often exceed expectations. When everything has a proper place and workspaces stay clean, accident rates can drop. Spills get noticed and cleaned immediately instead of becoming slip hazards. Tools don't get left in walkways where someone might trip.

Quality improvements follow naturally from better organization. Clean, well-organized environments make it easier to spot problems before they become defects. When workers aren't rushed or frustrated from searching for materials, they make fewer mistakes. The predictability of well-organized processes reduces variability in outcomes.

Perhaps surprisingly, employee engagement often increases significantly. Teams take pride in maintaining organized workspaces, especially when they participate in regular evaluations and see their scores improve over time. The checklist process gives everyone a voice in work area improvement.

## Making Implementation Work

Starting a successful 5S checklist program requires more than distributing forms. Begin with leadership commitment and comprehensive training so everyone understands both the evaluation process and its connection to their daily work experience.

Create area-specific checklists rather than generic ones. A machine shop needs different evaluation criteria than an assembly line or office environment. While core 5S principles remain constant, specific items should reflect each workspace's unique requirements.

Establish regular evaluation cycles: daily quick checks for immediate problems, weekly detailed reviews for improvement planning, and monthly comprehensive evaluations for trend analysis. The crucial element many programs miss is systematic follow-through. Identifying problems only creates value when those problems get solved with assigned responsibility and completion tracking.

That same daily/weekly/monthly cadence, run by different levels of management, is the structure behind a [layered process audit](https://flowfuse.com/blog/2026/08/layered-process-audit/). 5S checks workplace organization; an LPA checks whether the process itself is being run to standard. Many plants run both from the same tablet-based checklist workflow.

## The Digital Advantage with FlowFuse

Traditional paper checklists have inherent limitations. Results get lost, data analysis becomes time-consuming, and accessing information from multiple locations proves challenging. Digital solutions eliminate these problems while adding capabilities that paper cannot match.

FlowFuse's low-code Node-RED interface makes building sophisticated 5S checklist applications accessible without extensive programming backgrounds. You can create custom evaluation forms capturing exactly the information your operation needs. Simple yes/no questions, numerical scores, or detailed condition comments.

As an industrial data platform, FlowFuse enables seamless integration of 5S checklists into broader operational workflows, connecting work area organization efforts with real-time factory data for comprehensive improvement insights.

Mobile access transforms team interaction with the evaluation process. Workers complete checklists on tablets or smartphones directly in work areas, take photos documenting conditions, and immediately see how current scores compare to previous evaluations. This real-time feedback creates engagement impossible with paper forms.

[Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} for FlowFuse now and get started building your individual 5S checklist.

## Up next

If you want to start immediately without creating a checklist from scratch, FlowFuse’s pre-built 5S Checklist Blueprint is ready to use. It includes 25 evaluation questions to assess work area organization, scoring to measure compliance, and follow-up tracking to ensure issues are resolved. The dashboard provides a clear view of improvements over time, and the entire system is fully customizable to match the unique needs of your operations.


# Takt Time: Definition, Formula & How to Calculate It

Most factories that struggle with takt time aren't failing at the math, they're treating it as a theoretical number instead of an operational control. The result is the same either way: overproduction during low demand, missed deliveries during peak demand, and constant firefighting on the shop floor.

**Takt time is not a KPI, it's a design constraint.** It defines the exact pace at which a production system must operate to meet real customer demand using the available working time. Applied correctly, it becomes the backbone of flow, line balancing, capacity planning, and continuous improvement. Applied incorrectly, it creates false confidence and hidden bottlenecks.

This guide covers the correct definition of takt time, how to calculate it (including what time to exclude and why), how it differs from cycle time and lead time, real-world examples, and how modern digital tools monitor it in real time instead of on spreadsheets.

## What is Takt Time?

**Takt time** is the maximum allowable time to produce one unit of product to meet customer demand. It sets the pace at which work must flow through your production line to satisfy customer orders without overproducing or falling behind.

The word "takt" comes from the German "taktzeit," meaning "cycle time" or "beat." Despite the linguistic overlap, takt time and cycle time are fundamentally different metrics, a distinction we cover in detail below.

Formally, takt time is **the available production time divided by customer demand**. It's a customer-driven metric calculated from actual demand rather than production capability, and it functions as:

- A planning target that prevents overproduction and underproduction
- A balancing tool that distributes work evenly across workstations
- A performance metric that reveals bottlenecks and capacity constraints
- A continuous improvement baseline that quantifies the gap between current and required performance

## Takt Time Formula

![Takt Time Formula](https://flowfuse.com/blog/2025/09/images/takt-time-formula.png){dataZoomable=""}*The fundamental takt time formula*

**Takt Time = Available Production Time ÷ Customer Demand**

Two components need careful definition to calculate this accurately.

### Available Production Time

:cta-image{alt="Arch Systems scales automation across complex manufacturing environments with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/arch-systems-book-demo.png"}

This is the net time available for production during your planning period (typically one shift or day). It includes only planned production time, excluding scheduled breaks, lunch, shift changeovers, planned maintenance, and meetings, but not unplanned downtime like breakdowns.

For example: an eight-hour shift equals 480 minutes. Subtract a 10-minute break (470), a 20-minute lunch (450), and a 30-minute planned changeover (420). Available production time equals 420 minutes.

Organizations frequently overestimate available time by failing to account for all legitimate non-production activities, then face persistent schedule shortfalls when reality proves less generous than planning assumptions.

### Customer Demand

Customer demand is the number of units customers require during your planning period, drawn from actual orders, forecasted demand, inventory-based production targets, or an average over weeks or months.

Using daily order quantities creates takt times that vary day to day, potentially requiring frequent line rebalancing. Averaging demand over longer periods creates more stable takt times but risks temporary overproduction or underproduction as actual demand fluctuates around the average. Most manufacturers use a hybrid: averaged demand for line design, with periodic adjustments for actual order patterns.

### Step-by-Step Example

Using available production time of 420 minutes and customer demand of 210 units:

**Takt Time = 420 minutes ÷ 210 units = 2.0 minutes per unit**

Your production line must complete one unit every 2 minutes to meet demand. This establishes a maximum allowable cycle time: any operation taking longer than 2 minutes per unit will prevent the line from meeting demand unless compensated elsewhere or by added capacity.

## Real-World Examples of Takt Time

### Example 1: Automotive Parts Manufacturing

An automotive parts manufacturer produces brake assemblies during an eight-hour shift that includes a 30-minute lunch, 20 minutes of breaks, and a 10-minute changeover. Customer orders require 120 assemblies per shift.

Available production time: 480 − 30 − 20 − 10 = 420 minutes. Takt time: 420 ÷ 120 = **3.5 minutes per unit**.

The line must complete one brake assembly every 3.5 minutes. At a 5-minute actual cycle time, production falls about 30% short (84 units instead of 120). At 3 minutes per unit, the line overproduces by 20 units, creating excess inventory. Cycle times significantly above takt time reveal capacity shortfalls; cycle times well below it suggest redeployable capacity or overproduction risk. Takt time sets the required pace; a [run at rate](https://flowfuse.com/blog/2026/08/run-at-rate/) verifies that the line can sustain it under real production conditions.

### Example 2: Electronics Assembly (Multiple Shifts)

An electronics manufacturer runs two shifts producing circuit boards, with weekly demand of 2,400 units across five days. Each 8-hour shift allocates 40 minutes for breaks and 20 minutes for changeovers.

Available time per shift: 480 − 40 − 20 = 420 minutes. Weekly available time: 420 × 2 × 5 = 4,200 minutes. Takt time: 4,200 ÷ 2,400 = **1.75 minutes per unit**.

Calculating per-shift instead (240 units/shift ÷ 420 minutes) yields the same 1.75 minutes per unit, showing the calculation holds regardless of the time horizon you choose, as long as it matches your planning cycle.

### Example 3: Variable Product Mix

For lines running multiple models, takt time is calculated as a weighted average: total available time divided by total unit demand across all models. A line with 450 minutes available and combined demand of 180 units (across three models) has an average takt time of 2.5 minutes per unit. Manufacturers typically use level loading, sequencing models proportionally (e.g., A-A-B-A-A-C) rather than running large batches, to keep pace steady and surface quality issues sooner.

## Takt Time vs. Cycle Time vs. Lead Time: Comparison Matrix

| Feature                 | **Takt Time**                                                 | **Cycle Time**                                              | **Lead Time**                                                    |
| ----------------------- | ------------------------------------------------------------- | ----------------------------------------------------------- | ---------------------------------------------------------------- |
| **Fundamental Meaning** | The "Target Pace." The rate required to satisfy the customer. | The "Actual Speed." The time it takes to perform the work.  | The "Wait Time." The total duration a part spends in the system. |
| **Formula**             | **Available Production Time ÷ Customer Demand**               | **Time to complete one unit of work**                       | **Order completion time – Order placement time**                 |
| **What it Includes**    | Only net available production time (no breaks).               | Loading, processing, unloading, and reset time.             | Processing time + Queue time + Shipping + Delays.                |
| **Operational Focus**   | **Planning:** How many people or machines do we need?         | **Efficiency:** How can we make this specific task faster?  | **Responsiveness:** How quickly can we turn an order into cash?  |
| **Management Signal**   | If this changes, you must rebalance your production line.     | If this is too high, you have a bottleneck at that station. | If this is too high, your inventory levels are likely bloated.   |

In an ideal lean environment: **Cycle Time should sit at roughly 90–95% of Takt Time**, leaving a small buffer for minor interruptions without missing demand. **Lead Time** should stay as close as possible to the sum of your cycle times; if total cycle time is 1 hour but lead time is 10 days, 99% of the product's time in the system is pure waste.

## Why Takt Time Matters in Manufacturing

**Synchronizing production with demand.** Without takt time, production systems tend to run at maximum achievable speed regardless of actual demand, generating inventory during slow periods and shortages when demand rises. Calculating takt time correctly aligns production pace directly with order rate: when demand changes, takt time changes proportionally, triggering controlled adjustments instead of guesswork. This also caps overproduction: any output beyond the takt-time-derived rate is inventory the customer hasn't ordered yet, which is why pull-based systems use takt time as their replenishment signal.

**Line balancing and capacity planning.** Workstations with mismatched cycle times create bottlenecks: slow stations cause downstream waiting, fast ones cause upstream waiting, and both build up work-in-process that hides quality problems. Takt time gives every station the same target to balance against. For example, on a three-station line where Station 2's 3.5-minute cycle time bottlenecks Stations 1 (1.5 min) and 3 (2.0 min), rebalancing to a 2.5-minute takt time redistributes work so each station lands close to 2.3–2.4 minutes, and the bottleneck largely disappears. The same gap between current cycle time and takt time also quantifies staffing needs, equipment investment cases, and capacity expansion decisions.

**Continuous improvement and safety.** The gap between current cycle time and takt time gives kaizen and process-improvement efforts a concrete target: measure, find root causes, implement fixes, re-measure against takt time, repeat. It also protects quality and safety: production pushed to maximum speed rather than a sustainable, demand-matched pace tends to sacrifice quality checks and proper technique, and manufacturers moving to takt-time-based pacing typically see fewer defects and safety incidents as a result.

## Implementing Takt Time Monitoring with FlowFuse

Understanding takt time in theory is one thing; putting it into practice requires the right tools. [FlowFuse](https://flowfuse.com) connects to your existing systems, whether [PLCs](https://flowfuse.com/blog/2025/10/plc-to-mqtt-using-flowfuse/), [databases](https://flowfuse.com/node-red/database/), or ERP software, to calculate takt time automatically in real time instead of on static spreadsheets. Before starting, [create a FlowFuse account](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} if you don't already have one.

### Step 1: Connect to Your Data Sources

FlowFuse supports connections to industrial systems through its library of [protocol](https://flowfuse.com/node-red/protocol/) and [database](https://flowfuse.com/node-red/database/) nodes, pulling customer orders from your [ERP system](https://flowfuse.com/blog/2025/06/connect-shop-floor-to-odoo-erp-flowfuse/), production schedules from MES, and real-time counts from PLCs.

For this demo, simulate customer orders with an Inject node:

1. Add an Inject node
2. Configure the payload with this JSONata expression:

```json
   $round($random() * 50 + 50)
```

3. Set it to trigger every 5 seconds

This simulates demand varying between 50 and 100 units.

### Step 2: Calculate Available Production Time

1. Add a Change node
2. Use the following JSONata expression:

```json
   (8 * 60) - 60
```

This represents an 8-hour shift (480 minutes) minus 60 minutes for breaks and changeovers, leaving 420 minutes of available production time, the numerator in the formula.

### Step 3: Automate Takt Time Calculation

1. Add another Change node
2. Configure it with this JSONata expression:

```json
   $round(($number(msg.payload.availableTime) / $number(msg.payload.customer_order)) * 100)/100
```

This applies the formula automatically, recalculating takt time with every new order.

### Step 4: Create Real-Time Dashboards

1. Install the [FlowFuse Dashboard](https://flowfuse.com/platform/dashboard/) package via the Palette Manager (`@flowfuse/node-red-dashboard`)
2. Use text widgets for a simple readout, or the Template widget for a custom display; [FlowFuse AI](https://flowfuse.com/blog/2025/07/flowfuse-ai-assistant-better-node-red-manufacturing/) can generate the code from a plain-English description
3. Wire the Inject node into the available-time Change node, that into the takt-time Change node, and that into the UI Template node
4. Deploy the flow and open the dashboard

:video{ariaLabel="Simple takt time display dashboard built with FlowFuse" autoPlay="true" height="546" loop="true" muted="true" playsInline="true" preload="none" width="558"}*Real-time takt time monitoring dashboard in FlowFuse*

Here's the complete flow:

::render-flow{:height='300'}
```json
[{"id":"d5e580f48a9299a6","type":"inject","z":"c2c694c911f786fe","name":"Simulate Customer Order","props":[{"p":"payload.customer_order","v":"$round($random() * 50 + 50)","vt":"jsonata"}],"repeat":"5","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":400,"y":300,"wires":[["518dbc1ac72f7c21"]]},{"id":"518dbc1ac72f7c21","type":"change","z":"c2c694c911f786fe","name":"Calculate total available time","rules":[{"t":"set","p":"payload.availableTime","pt":"msg","to":"(8 * 60) - 60","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":660,"y":300,"wires":[["3d35535dbb06fc86"]]},{"id":"3d35535dbb06fc86","type":"change","z":"c2c694c911f786fe","name":"Calculate Takt Time","rules":[{"t":"set","p":"payload","pt":"msg","to":"$round(($number(msg.payload.availableTime) / $number(msg.payload.customer_order)) * 100)/100","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":910,"y":300,"wires":[["de044b9204a9b248"]]},{"id":"de044b9204a9b248","type":"ui-template","z":"c2c694c911f786fe","group":"79d59adc1e8219b7","page":"","ui":"","name":"Display: Takt Time","order":1,"width":0,"height":0,"head":"","format":"<template>\n  <v-sheet class=\"d-flex justify-center align-center led-background\" height=\"150\" elevation=\"4\" rounded>\n    <div class=\"led-display\">\n      {{taktTime}}\n    </div>\n  </v-sheet>\n</template>\n\n<script>\n  export default {\n  data() {\n    return {\n      taktTime: this.msg?.payload ?? '00:00.0'\n    }\n  },\n  watch: {\n    msg(newMsg) {\n      if (newMsg?.payload) {\n        this.taktTime = newMsg.payload;\n      }\n    }\n  }\n}\n</script>\n\n<style scoped>\n  .led-background {\n    background: #0a0a0a;\n    /* Dark black background */\n    background-image: radial-gradient(circle, #111 1px, #0a0a0a 1px);\n    background-size: 20px 20px;\n    /* Carbon-like grid */\n  }\n\n  .led-display {\n    font-family: 'Digital-7', monospace;\n    font-size: 96px;\n    color: #0f0;\n    text-shadow:\n      0 0 5px #0f0,\n      0 0 10px #0f0,\n      0 0 20px #0f0,\n      0 0 30px #0f0;\n  }\n</style>\n\n<!-- Include Digital-7 font from CDN -->\n<link href=\"https://fonts.googleapis.com/css2?family=Orbitron&display=swap\" rel=\"stylesheet\">","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":1110,"y":300,"wires":[[]]},{"id":"79d59adc1e8219b7","type":"ui-group","name":"Takt Time","page":"9b1c640ccc6a665e","width":6,"height":1,"order":1,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"9b1c640ccc6a665e","type":"ui-page","name":"FlowFuse Dashboard","ui":"d44eab3a91dda8d9","path":"/","icon":"home","layout":"grid","theme":"2278e18670b606b7","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"d44eab3a91dda8d9","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":true},{"id":"2278e18670b606b7","type":"ui-theme","name":"Default Theme","colors":{"surface":"#2e073e","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"da2b78557435736b","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.27.2"}}]
```
::

## Best Practices for Takt Time Implementation

- **Accurate Data:** Base calculations on actual production time, including breaks, changeovers, and realistic downtime, using real customer demand, and update regularly.
- **Leadership Commitment:** Leaders must support implementation visibly, allocate resources, and communicate the benefits clearly.
- **Gradual Deployment:** Start with a pilot line, train operators thoroughly, stabilize, and expand gradually rather than rolling out across all lines at once.
- **Lean Integration:** Combine takt time with value stream mapping, standardized work, and 5S to reduce waste and improve process capability.
- **Visual Management:** Use visible displays showing calculated takt time and production status at a glance so operators can react quickly.
- **Problem Response:** Establish escalation procedures, keep critical spares and maintenance nearby, and train operators in basic troubleshooting.
- **Continuous Refinement:** Review takt time regularly, track performance against it, and share lessons learned across deployments.

## Conclusion

Takt time turns volatile customer demand into a precise, manageable production rhythm. The formula is simple (Available Production Time ÷ Customer Demand), but consistently applying it is what separates world-class operations from those stuck firefighting overproduction and missed deadlines. Manual tracking on spreadsheets tends to lag reality; platforms like FlowFuse give you the real-time visibility to monitor takt time, cycle time, and lead time automatically across your value stream.


# MCP and Custom AI Models on FlowFuse!

We have a VERY exciting announcement today: you can now build an MCP server and upload custom-trained AI models to FlowFuse!

## AI on FlowFuse

Node-RED is already the most capable and flexible low-code development environment out there. FlowFuse makes it secure, robust, and scalable.

As of today, you can now use FlowFuse to create your own MCP server and use custom-trained AI models that you've built for any application.

Build an MCP server to create an AI agent that will do whatever you've design it to do. And add a training model that you've built using your own training data, so data processing works exactly the way you want it to.

## Model Context Protocol

LLMs were trained by scraping data from the internet to build data models that can complete a task (like answering a question or writing a blog article -- but not this one!) given some input prompt. When you rely on an LLM to answer questions that are very general or perform operations that are rather straightforward, LLMs can generally do so with ease.

However, if you want to do something more sophisticated, or create an AI agent that will rely on specific data, that data needs to be presented to the AI somehow. MCP is what enables that.

Instead of relying just on LLMs trained from scraping the entire internet, the new MCP nodes enable you to create your own MCP servers, so you can present information to an AI tool, putting much more power and control in your hands as a developer.

You are now able to create your own, custom AI agent using FlowFuse.

## Custom Data Models

When creating an AI agent or getting AI assistance with some task, one component is the data that is surfaced to the model. That part is handled by MCP. Another part is how the model interacts with that data. That part is handled with our new AI nodes.

Instead of relying on a standard LLM, even one that has been set up to connect with an MCP server, it is possible to train the model itself. The new AI nodes allow you to train a custom model, put it in [ONNX](https://onnx.ai){rel="&#x22;nofollow&#x22;"} format, and connect it to Node-RED, where it can be deployed to run any operation you wish with your new, personally-trained AI.

## The Sky Is the Limit

The flexibility of Node-RED, the reliability of FlowFuse, and the customizability enabled by these MCP and AI nodes means you can build just about any AI application you wish!

And this week, we're going to tell you all about it. Stay tuned for a demo or three, some tutorials, and overall plenty of instructional content goodness that will demonstrate the power that is now available with these AI releases!

While we're at it, we are also going to unveil a new feature right on our home page: a trained FlowFuse Expert (AI) that will teach you how to build applications in FlowFuse and Node-RED!

## Try it Now

Ready to try out these new nodes? If you're new to FlowFuse, [create a trial team](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}. Then, head to Manage Palette (in the hamburger menu on the right side of the Node-RED editor), click Install, and in the dropdown menu, choose FlowFuse Nodes to see the catalog of nodes that are exclusive to FlowFuse customers. From here, you can install both the MCP nodes and AI ONNX nodes.

If you're an existing FlowFuse user, begin by restarting the Node-RED instance where you want to use the nodes, then follow the same instructions as above.


# Building MCP Servers for AI Agent Integration in Node-RED with FlowFuse

FlowFuse released MCP nodes for Node-RED, allowing AI to directly interact with the flows you have built. These nodes let AI read sensor data, query databases, and control equipment. You use FlowFuse to collect and manage data in your flows, while AI agents determines what actions to take and why, enabling intelligent monitoring and automated control of factory and IIoT/IoT systems.

This article explains how to build an MCP server with FlowFuse and connect AI to your systems for real-time insights, operational decisions, and automated control.

### What Is MCP?

The Model Context Protocol (MCP) is an open standard that enables AI assistants to access data and execute actions across external systems.

MCP works through three key components. Resources give AI visibility into your operations through read-only access to sensor data, database records, SCADA tags, and equipment logs. This real-time information helps AI understand what's actually happening on your factory floor or in your IIoT environment.

Tools let AI perform specific actions in your systems. These might include adjusting equipment parameters, triggering maintenance alerts, or generating operational reports. Each tool clearly defines what it needs as input and what it will produce as output, which keeps operations predictable and safe.

Prompts are workflow templates that guide AI through more complex tasks. They show AI how to use multiple resources and tools together to complete multi-step operations. This is particularly valuable when you need AI to follow established procedures rather than improvising solutions.

When you connect an AI agent to your MCP server, it discovers all available resources and tools automatically. The protocol handles the technical details of data requests and action execution, so AI can start working with your industrial systems right away. You build your flows in Node-RED, and AI learns how to interact with them intelligently through the MCP interface.

## Getting Started

This section guides you through setting up an MCP server, defining resources, and creating tools so AI can interact with your system.

### Prerequisites

Before you begin, ensure you have the following:

- **A running FlowFuse Enterprise instance.** If you do not have one, [contact us](https://flowfuse.com/contact-us/) to discuss Enterprise options and get started.
- **Ensure the `@flowfuse-nodes/nr-mcp-server-nodes` package is installed**. This will add the [MCP nodes](https://flowfuse.com/node-red/flowfuse/mcp/) to your Node palette in your instance editor.

> **Note:** The MCP nodes (@flowfuse-nodes/nr-mcp-server-nodes) are only available on the Enterprise tier.

### Configuring the MCP Server

Before defining resources or tools, the MCP Server must be configured. This server acts as the central endpoint for AI agents, ensuring all resources and tools are accessible under a single, consistent configuration.

1. Drag an **MCP Resource or Tool*&#x2A; node onto your workspace and click the &#x2A;*+** next to Server to create a new configuration.
2. Define the server properties:
   - **Name**: Enter a descriptive name, e.g., `Node-RED MCP Server`.
   - **Protocol**: Leave the default `http/sse` (currently the only option).
   - **Path**: Specify the endpoint path for the server, e.g., `/mcp`.

![MCP Server Configuration](https://flowfuse.com/blog/2025/10/images/mcp-server-config.png){dataZoomable=""}*Caption: Configuring the MCP Server in Node-RED*

3. **Click Done** to save the server configuration.

Once the server is configured, clients can connect using a URL. The URL to connect with is your instance URL plus the MCP path you configured, for example:

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

```text
https://your-instance.flowfuse.cloud/mcp
```

or if you are running FlowFuse Node-RED instance locally, use the host, port, and MCP path of your instance, for example:

```text
http://localhost:1880/mcp
```

or

```text
http://192.168.1.100:1880/mcp
```

This URL allows AI agents to discover resources, execute tools, and interact with your flows.

### Securing Your MCP Server

To ensure your MCP server is protected from unauthorized access, enable FlowFuse User Authentication.

1. Navigate to your instance **Settings → Security** tab
2. Select **FlowFuse User Authentication**, click **Save Changes**, and in the popup, click **Restart** to apply the changes.

![FlowFuse User Authentication settings screenshot](https://flowfuse.com/blog/2025/10/images/ff-auth.png){dataZoomable=""}*FlowFuse User Authentication settings screenshot*

3. Click **Add Token** and provide a descriptive name for identification
4. Set an expiry date (recommended for enhanced security)
5. Click **Create** and copy the generated token

When connecting to your MCP server from a client, include the token in the request headers:

```json
{
  "node-red-mcp-server": {
    "url": "http://localhost:1880/mcp",
    "type": "http",
    "headers": {
      "Authorization": "Bearer ffhttp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    }
  }
}
```

Replace `ffhttp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx` with your actual token. This ensures that only authorized clients can access your MCP server resources and tools.

::div{.blog-update-notes}
**UPDATE:** [FlowFuse Expert now allows you to connect directly with your MCP Resources and Tools](https://flowfuse.com/blog/2025/12/flowfuse-release-2-25/#interact-with-mcp-resources-in-flowfuse-expert), so you don't need to connect external AI agents anymore.

```text
<p>You'll need to select the MCP server you want to connect to in the FlowFuse Expert Insights tab. Once connected, FlowFuse Expert will automatically query your Resources and execute your Tools based on your team role and your instructions. The annotations you configure in the <a href="#defining-an-mcp-tool">MCP Tool node</a> (read-only, destructive, idempotent, open-world) integrate with FlowFuse's role-based access control to ensure secure, appropriate access for every team member.</p>

![FlowFuse Expert](./images/mcp-in-flowfuse.png){data-zoomable}
```
::

### Defining an MCP Resource

Now let's start by defining a Resource. In MCP, a Resource represents a data source that you want to expose to an AI agent. In an industrial context, this could be a sensor value, a machine's status, or a list of production lines.

1. Drag the MCP Resource node from the palette onto your workspace.
2. Double-click the node to open its configuration panel and select the added mcp server configuration.
3. Enter the unique id for the resource, for example : "all-production-lines"
4. Provide a unique URI for this specific resource, for example, `mcp://monitor-all-production-lines` Make sure your every resource must have a unique URI.
5. Enter a clear, human-readable title, like "Monitoring All production lines". This is the name the AI agent or client that will connect will see, so make it descriptive.
6. Give the node a descriptive name for your flow, such as Production Lines Resource, and enter a brief description.

![MCP Resource Configuration](https://flowfuse.com/blog/2025/10/images/mcp-resource-node-config.png){dataZoomable=""}*Setting up an MCP Resource in FlowFuse*

7. Click Done and then Deploy your flow.

At this point, your MCP server is live and resource is discoverable. However, it doesn't contain any data yet.

To expose data you will need to connect the MCP Resource node to any data-producing node in your flow. This could be an HTTP Request node retrieving data from an API, a FlowFuse Query node for fetching records from a FlowFuse data table, industrial connectors such as OPC UA Read, Modbus Read, PLC Read nodes.

8. Next, drag the MCP Response node and connect its input to the output of the upstream data source node.

> The MCP Response node is crucial because it delivers the results of your flow back to the AI agent. Without it, the AI will not receive the data it requests. Any errors are also fed back to the MCP Response node, enabling the AI to handle them appropriately.

9. Deploy the flow

Now, when an AI agent or any other client requests this URI, the flow will automatically execute and query your data source for the latest information. This data is then returned to the agent, providing it with the real-time context needed to answer your questions.

#### Example: Monitoring Production Lines

For this article, we've built a demonstration data flow. We have a table named production-lines where new data is inserted every five seconds from 10 different lines.

We then created a data resource and exposed all the line data to it. Now, let's connect a AI Agent to this resource and explore the kinds of questions we can ask to monitor the factory floor effectively.

:video{ariaLabel="Monitoring Production Lines" autoPlay="true" height="1870" loop="true" muted="true" playsInline="true" preload="none" width="3024"}*Production line monitoring using MCP Resources*

### Defining an MCP Tool

While resources are useful for providing access to data, tools enable an AI agent to perform specific, parameterized actions within your system.

1. Drag the MCP Tool node from the Node-RED palette onto your workspace.
2. Double-click the node to open the configuration panel and select the MCP Server configuration you previously created.
3. Enter a tool name that will be visible to clients connecting to the MCP server, such as *Maintenance* or *Maintenance Scheduler*.
4. Next, set annotations. Annotations help AI clients understand your tool's behavior and control which FlowFuse team members can access it based on their role (Viewer, Member, or Owner).
   - **Read-Only Hint**: Tool only reads data, doesn't modify anything. Safe for exploratory queries.
     - **Access**: Viewer role and above
   - **Destructive Hint**: Tool may delete or irreversibly modify data. Use with caution.
     - **Access**: Owner role only
   - **Idempotent Hint**: Calling the tool multiple times with same parameters has the same effect as calling it once. Safe to retry.
     - **Access**: No effect on roles (only relevant for writing tools, which require Member minimum)
   - **Open-World Hint**: Tool interacts with external systems or data sources that may change unpredictably.
     - **Access**: Member role and above
   > **Note:** These are hints only and do not enforce behavior. The actual behavior of a tool is determined by your Node-RED flow implementation. Annotations are used by FlowFuse for role-based access control (RBAC) and FlowFuse Expert. They are also part of the standard MCP specification and can be consumed by external agents, but their effect ultimately depends on the client's implementation.
5. Provide a clear description of the tool's purpose, and assign a descriptive name to the node within your flow.
6. Define the input schema in JSON format. This schema helps the AI understand what data is required to perform the action and also validates incoming requests. For detailed guidance, refer to the [Getting Started Guide](https://json-schema.org/learn/getting-started-step-by-step){rel="&#x22;nofollow&#x22;"}.
   > Tip: You can also use the FlowFuse Expert to generate the JSON schema automatically. Just click **Ask FlowFuse Expert** in the input schema field and describe the expected input in plain English.
   :brBelow is an example schema for a Tool node. It shows how data is defined, its type, and which fields are required along with minimum lengths:
   ```json
   {
     "type": "object",
     "properties": {
       "line": {
         "type": "string",
         "description": "The production line where maintenance is required",
         "minLength": 1
       },
       "description": {
         "type": "string",
         "description": "Description of the maintenance task",
         "minLength": 1
       },
       "priority": {
         "type": "string",
         "description": "Priority of the task",
         "enum": [
           "Low",
           "Medium",
           "High"
         ]
       }
     },
     "required": [
       "line",
       "description",
       "priority"
     ]
   }
   ```
   :br![MCP Tool Node Configuration](https://flowfuse.com/blog/2025/10/images/mcp-tools.png){dataZoomable=""}*Setting up an MCP Tool in FlowFuse*
7. Click *Done*, then deploy your flow.

At this stage, the tool becomes discoverable by connected AI clients. However, it will not perform any action until it is linked to a flow that executes a task, such as an HTTP Request node performing a POST operation, a Query node inserting data into a database, or an OPC UA Write node controlling a device.

8. Drag the MCP Response node and connect its input to the output of the final node in your action flow.
   > The MCP Response node is necessary because the AI needs to receive the outcome of the action, whether it was successful or not. Errors are also fed back to the MCP Response node, enabling the AI to handle them appropriately.
9. Deploy the flow once again.

Your MCP Tool is now active. When an AI agent invokes it, the connected flow executes the defined action and returns the result to the agent.

#### Example: Scheduling Maintenance for Production Lines

In this example, the flow includes a tool that triggers a POST request to the maintenance system API, which was developed using FlowFuse and the FlowFuse Dashboard. The AI Assistant was then asked to identify which production line was performing the worst and schedule a maintenance task for it.

:video{ariaLabel="Scheduling Maintenance Example" autoPlay="true" height="1638" loop="true" muted="true" playsInline="true" preload="none" width="3024"}*AI agent scheduling maintenance using an MCP Tool*

Below is the flow that includes the Resource we created to monitor production lines and the Tool that sends a POST request.

*Note: The flow uses the FlowFuse Query node and FlowFuse tables, which are only available on the Enterprise tier. If you do not have Enterprise, you can use other data sources instead, such as HTTP Request, OPC UA, or other database nodes.*

::render-flow{:height='300'}
```json
[{"id":"c0952d97df3a1491","type":"group","z":"3831e63ae3acc9b0","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["2da059f0b9465120","5ee2cab1a6affc67","1ea311e63b6b7b89","628139fa99072e2e"],"x":94,"y":179,"w":712,"h":142},{"id":"2da059f0b9465120","type":"mcp-response","z":"3831e63ae3acc9b0","g":"c0952d97df3a1491","name":"","x":700,"y":240,"wires":[]},{"id":"5ee2cab1a6affc67","type":"mcp-resource","z":"3831e63ae3acc9b0","g":"c0952d97df3a1491","name":"Lines MCP Resource","server":"460154892784fd4e","resourceUri":"mcp://monitor-all-production-lines","resourceId":"all-production-lines","title":"Monitoring All Production lines","description":"Represents the real-time data stream for all production Line. Contains sensor readings, operational status, and performance metrics accessible via the MCP server.","mimeType":"application/json","x":220,"y":220,"wires":[["1ea311e63b6b7b89"]]},{"id":"1ea311e63b6b7b89","type":"tables-query","z":"3831e63ae3acc9b0","g":"c0952d97df3a1491","name":"Retrieve Lines Data","query":"SELECT * FROM public.production_lines;","split":false,"rowsPerMsg":1,"x":450,"y":220,"wires":[["2da059f0b9465120"]]},{"id":"628139fa99072e2e","type":"catch","z":"3831e63ae3acc9b0","g":"c0952d97df3a1491","name":"Catch errors in this group","scope":"group","uncaught":false,"x":430,"y":280,"wires":[["2da059f0b9465120"]]},{"id":"460154892784fd4e","type":"mcp-server","name":"NODE-RED MCP SERVER","protocol":"http","path":"/mcp"},{"id":"a55471a9a3c7af9f","type":"group","z":"3831e63ae3acc9b0","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["7fd32aa0ef7ca984","a412bb732aa5e5e0","3b3c8c52146e69ef","03a75b77302b1d19"],"x":94,"y":339,"w":712,"h":142},{"id":"7fd32aa0ef7ca984","type":"http request","z":"3831e63ae3acc9b0","g":"a55471a9a3c7af9f","name":"Schedule Maintenance","method":"POST","ret":"txt","paytoqs":"ignore","url":"","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":440,"y":380,"wires":[["3b3c8c52146e69ef"]]},{"id":"a412bb732aa5e5e0","type":"mcp-tool","z":"3831e63ae3acc9b0","g":"a55471a9a3c7af9f","name":"","server":"460154892784fd4e","toolName":"maintenance","title":"Create Maintenance Task","description":"Handles maintenance tasks on the production line","inputSchema":"{\n  \"type\": \"object\",\n  \"properties\": {\n    \"line\": {\n      \"type\": \"string\",\n      \"description\": \"The production line where maintenance is required\",\n      \"minLength\": 1\n    },\n    \"description\": {\n      \"type\": \"string\",\n      \"description\": \"Description of the maintenance task\",\n      \"minLength\": 1\n    },\n    \"priority\": {\n      \"type\": \"string\",\n      \"description\": \"Priority of the task\",\n      \"enum\": [\n        \"Low\",\n        \"Medium\",\n        \"High\"\n      ]\n    }\n  },\n  \"required\": [\n    \"line\",\n    \"description\",\n    \"priority\"\n  ]\n}","x":190,"y":380,"wires":[["7fd32aa0ef7ca984"]]},{"id":"3b3c8c52146e69ef","type":"mcp-response","z":"3831e63ae3acc9b0","g":"a55471a9a3c7af9f","name":"","x":700,"y":380,"wires":[]},{"id":"03a75b77302b1d19","type":"catch","z":"3831e63ae3acc9b0","g":"a55471a9a3c7af9f","name":"Catch errors in this group","scope":"group","uncaught":false,"x":430,"y":440,"wires":[["3b3c8c52146e69ef"]]},{"id":"4e9c50c5940103ab","type":"global-config","env":[],"modules":{"@flowfuse-nodes/nr-mcp-server-nodes":"0.1.1","@flowfuse/nr-tables-nodes":"0.1.0"}}]
```
::

If you need more example flows, you can import the examples that come with the MCP nodes. Click the main menu from the top right, click Import, switch to Examples, and look for `@flowfuse-nodes/nr-mcp-server-node`, then select mcp\_server and click Import. If you prefer a video tutorial, watch this [video tutorial on YouTube](https://www.youtube.com/watch?v=troUvaF8V68){rel="&#x22;nofollow&#x22;"}.

With your MCP server, Resources, and Tools in place, the AI agent can now interact with your industrial systems in a structured way. Up to this point, we've covered the basics and demonstrated a simple workflow. The MCP Prompt node, which allows AI agents to be guided through complex, multi-step tasks, will be explored in a future article.

## Conclusion

This guide demonstrated how to build a fully functional MCP server with FlowFuse and Node-RED, providing AI agents with structured access to industrial systems through Resources and Tools, which enable workflows such as monitoring production lines, scheduling maintenance, and automating operational decisions, all without complex coding.

FlowFuse [recently added ONNX AI nodes](https://flowfuse.com/blog/2025/10/ai-on-flowfuse/). With these nodes, you can train custom models, deploy them in Node-RED, and execute tasks tailored to your processes. Combined with FlowFuse’s capabilities to collect, transform, and visualize industrial data, the platform makes development, monitoring, and optimization faster, smarter, and more scalable.

Adopting MCP with FlowFuse is a strategic step toward AI-enabled, future-ready industrial automation. [Book a demo today](https://flowfuse.com/blog/2025/10/ai-on-flowfuse/) to see how FlowFuse connects, transforms, and visualizes your industrial data while making AI-driven operations easy and actionable.


# Deploy Custom-Trained AI Models: Using ONNX with Node-RED and FlowFuse

FlowFuse is introducing a new set of AI nodes to make it easier than ever to integrate AI and machine learning into your Node-RED workflows.
In this guide, you will learn how to train an image classifier model, and use it with the new FlowFuse AI Nodes to recognise your own products, components - or anything else you can imagine.

### Introduction

In this article, we will be building a PyTorch-based image classification model to identify fruit types (apple, kiwi, mango) using a dataset of labelled images.
Of course, you would typically be classifying your own things like your company widgets and products, but for the sake of learning the process, we will be using images of fruit.
Once the model is trained, it is exported to the ONNX format, it is then ready for use with the new FlowFuse AI nodes.

Note: The code and sample dataset used in this tutorial can be downloaded from [this link](https://website-data.s3.eu-west-1.amazonaws.com/2025-10-onnx-model-training-dataset.zip){rel="&#x22;nofollow&#x22;"}.

### Some background first

The process we will use is commonly referred to as "transfer learning". This is where you take a pre-trained model and fine-tune it on your own dataset.
This is a common approach in deep learning as it allows us to leverage the knowledge learned by the pre-trained model and adapt it to our specific task with a smaller dataset. For reference, this tutorial will use ResNet-18 which is an 18-layer Residual Network (ResNet), a convolutional neural network (CNN) architecture that uses "skip connections" to help train very deep networks by addressing the vanishing gradient problem. Pre-trained ResNet-18 models are often trained on the ImageNet dataset and are widely used for image classification of 1000 categories.

### Overview of operations

The 3 main steps to achieve this involves:

1. Setting up a Python environment with PyTorch, TorchVision, ONNX, and ONNX Runtime.
2. Organizing your dataset into train, validation, and test folders for each class.
3. Perform "transfer learning" to fine-tune the model against your images & generate the ONNX model.

Let's get started...

### Setup the environment

#### Pre-requisites

This tutorial was tested on Ubuntu using Python 3 and `pyenv` for environment management.

For the sake of brevity, from this point forward, the tutorial will assume you are using a debian based operating system and `pyenv`.
Instructions will need to be adapted if you are using something else.

##### Python tools

Ensure you have `pyenv` and `pyenv-virtualenv` installed.

```bash
pyenv --version
pyenv virtualenv --version
```

If you don't have them installed, this [Medium article](https://medium.com/@aashari/easy-to-follow-guide-of-how-to-install-pyenv-on-ubuntu-a3730af8d7f0){rel="&#x22;nofollow&#x22;"} worked well in our case.

##### Sub dependencies

During setup and testing, my installation failed at the last step due to missing `bz2` support (a TorchVision dependency).
If you encounter this, you would need to install `libbz2` then you would need to rebuild your python environment.
To save time, I recommend that you perform the steps below now to ensure the dependencies are installed and avoid the mis-step.

```bash
sudo apt update
sudo apt install -y libbz2-dev liblzma-dev libsqlite3-dev libssl-dev zlib1g-dev libffi-dev build-essential
```

#### Virtual Environment Setup

Install python 3.10.14 (or any version compatible with pytorch and onnx):

```bash
pyenv install 3.10.14
```

Create a new virtual environment:

```bash
pyenv virtualenv 3.10.14 venv_py3_10_14_pytorch
```

Activate the virtual environment:

```bash
pyenv activate venv_py3_10_14_pytorch
```

*NOTE: Depending on your shell, your commandline may become decorated with the name of the virtual environment.*

Install the required packages:

```bash
pip install --upgrade pip
pip install torch torchvision onnx onnxruntime matplotlib numpy
```

Create a working directory

```bash
mkdir ~/my-py-projects
cd ~/my-py-projects
mkdir pytorch-onnx
cd pytorch-onnx
# Associate this directory with the virtual env we created earlier
pyenv local venv_py3_10_14_pytorch
```

(Optional) Create a `requirements.txt` file to document the packages used in this project:

```bash
pip freeze > requirements.txt
```

### Organizing your dataset

For this example, I have created a simple dataset of images of apples, kiwis, and mangos.
You can use your own dataset or download a dataset from the internet (e.g. [this one](https://www.kaggle.com/datasets/){rel="&#x22;nofollow&#x22;"} or [this one](https://images.cv/search-labeled-image-dataset){rel="&#x22;nofollow&#x22;"}).
Just make sure to organize the images in the following structure:

```bash
data/
    train/
        apples/
            apple1.jpg
            apple2.jpg
            ...
        kiwis/
            kiwi1.jpg
            kiwi2.jpg
            ...
        mangos/
            mango1.jpg
            mango2.jpg
            ...
    val/
        apples/
            apple3.jpg
            apple4.jpg
            ...
        kiwis/
            kiwi3.jpg
            kiwi4.jpg
            ...
        mangos/
            mango3.jpg
            mango4.jpg
            ...
    test/
        apples/
            apple5.jpg
            apple6.jpg
            ...
        kiwis/
            kiwi5.jpg
            kiwi6.jpg
            ...
        mangos/
            mango5.jpg
            mango6.jpg
            ...
```

Now, inside `~/my-py-projects/pytorch-onnx/` you should have:

```bash
pytorch-onnx/
│
├── data/
│   ├── train/
│   │   ├── apples/
│   │   ├── kiwis/
│   │   └── mangos/
│   ├── val/
│   └── test/
│
├── fruit_classifier.py   # we will create this shortly
└── requirements.txt      # optional
```

### Fine-tune the model

Now we can create a simple pytorch model to classify the images.

Create a new file called `fruit_classifier.py`

```bash
# Use nano to create the file (you can use your favorite editor e.g. vim, code, etc)
nano fruit_classifier.py
```

Add the following code:

```python
# fruit_classifier.py

import torch
import torch.nn as nn
import torch.optim as optim
from torch.utils.data import DataLoader
import torchvision.transforms as transforms
import torchvision.datasets as datasets
import torchvision.models as models
import onnxruntime as ort
import numpy as np

# --- Dataset ---
data_dir = "data"
transform = transforms.Compose([
    transforms.Resize((224, 224)),
    transforms.ToTensor(),
    transforms.Normalize(mean=[0.485, 0.456, 0.406],
                         std=[0.229, 0.224, 0.225])
])

train_dataset = datasets.ImageFolder(f"{data_dir}/train", transform=transform)
val_dataset   = datasets.ImageFolder(f"{data_dir}/val", transform=transform)
test_dataset  = datasets.ImageFolder(f"{data_dir}/test", transform=transform)

train_loader = DataLoader(train_dataset, batch_size=32, shuffle=True)
val_loader   = DataLoader(val_dataset, batch_size=32, shuffle=False)
test_loader  = DataLoader(test_dataset, batch_size=32, shuffle=False)

print("Class mapping:", train_dataset.class_to_idx)

device = torch.device("cuda" if torch.cuda.is_available() else "cpu")

# --- Model ---
model = models.resnet18(weights=models.ResNet18_Weights.IMAGENET1K_V1)
model.fc = nn.Linear(model.fc.in_features, len(train_dataset.classes))
model = model.to(device)

criterion = nn.CrossEntropyLoss()
optimizer = optim.Adam(model.parameters(), lr=1e-4)


# --- Training ---
def train(num_epochs=5):
    for epoch in range(num_epochs):
        model.train()
        running_loss = 0.0
        for inputs, labels in train_loader:
            inputs, labels = inputs.to(device), labels.to(device)

            optimizer.zero_grad()
            outputs = model(inputs)
            loss = criterion(outputs, labels)
            loss.backward()
            optimizer.step()

            running_loss += loss.item()

        avg_loss = running_loss / len(train_loader)
        print(f"Epoch {epoch+1}, Loss: {avg_loss:.4f}")


# --- Evaluation ---
def evaluate(loader):
    model.eval()
    correct, total = 0, 0
    with torch.no_grad():
        for inputs, labels in loader:
            inputs, labels = inputs.to(device), labels.to(device)
            outputs = model(inputs)
            _, preds = torch.max(outputs, 1)
            correct += (preds == labels).sum().item()
            total += labels.size(0)
    return correct / total


# --- Export to ONNX ---
def export_model():
    dummy_input = torch.randn(1, 3, 224, 224, device=device)

    torch.onnx.export(
        model,               # model being run
        dummy_input,         # model input (or a tuple for multiple inputs)
        "fruit_classifier.onnx",    # where to save the model (can be a file or file-like object)
        export_params=True,  # store the trained parameter weights inside the model file
        opset_version=16,    # the ONNX version to export the model to
        do_constant_folding=True,  # whether to execute constant folding for optimization
        input_names=['input'],   # the model's input names
        output_names=['output'],  # the model's output names
        dynamic_axes={"input": {0: "batch_size"}, "output": {0: "batch_size"}}
    )

    print("Model exported to fruit_classifier.onnx")


# --- Test with ONNX Runtime ---
def test_onnx():
    ort_session = ort.InferenceSession("fruit_classifier.onnx")

    def to_numpy(tensor):
        return tensor.detach().cpu().numpy() if tensor.requires_grad else tensor.cpu().numpy()

    inputs, _ = next(iter(test_loader))
    ort_inputs = {"input": to_numpy(inputs[:1])}
    ort_outs = ort_session.run(None, ort_inputs)

    pred_class = np.argmax(ort_outs[0])
    print("ONNX Prediction:", train_dataset.classes[pred_class])


# --- Main ---
if __name__ == "__main__":
    train(num_epochs=5)
    val_acc = evaluate(val_loader)
    print(f"Validation Accuracy: {val_acc:.2%}")

    export_model()
    test_onnx()

```

#### Run the fruit\_classifier.py Python script

Now you can run the script that will train the model, export it to ONNX format, and run a quick classification test using the ONNX Runtime:

```bash
python fruit_classifier.py
```

What you should see:

```log
Class mapping: {'apple': 0, 'kiwi': 1, 'mango': 2}
Epoch 1, Loss: 0.7811
Epoch 2, Loss: 0.1383
Epoch 3, Loss: 0.0671
Epoch 4, Loss: 0.0399
Epoch 5, Loss: 0.0184
Validation Accuracy: 80.95%
Model exported to fruit_classifier.onnx
ONNX Prediction: apple
```

If you changed the data set from fruit to your use own images and classifications, it will output a different `Class mapping` that you will need to use in the Node-RED flow on the next step - make a note of this.

### Using your newly generated ONNX Model with the FlowFuse ONNX Node

1. Import the finished ONNX model into a location in the file system where your Node-RED instance can access it
   - In FlowFuse cloud you can do this via the Assets tab
2. Import the demo flow
   - Open your Node-RED editor
   - Press `CTRL-I` or select `Import` from the menu to open the Import Dialog
   - Select the **Examples** tab
   - Click the **@FlowFuse/nr-ai-nodes** entry
   - Click the demo named **advanced-custom-model**
   - Click the **Import** Button
3. Double click the ONNX node to open the configuration dialog
4. Enter the path to your ONNX model in the **Path** field
5. If necessary, update the classifications (labels) in the Function node named **load labels** as noted in the previous section
6. Deploy the flow
7. Click the inject button on the left of the flow to trigger an inference

![Image showing how to import demo flow](https://flowfuse.com/blog/2025/10/images/custom-onnx-mode--import-flow.png){dataZoomable=""}*Image showing how to import demo flow*

![Image showing inference in action](https://flowfuse.com/blog/2025/10/images/custom-onnx-mode--in-action.png){dataZoomable=""}*Image showing inference in action*

### Supplementary Notes

#### Clean up

To deactivate the virtual environment when you're done, simply run:

```bash
pyenv deactivate
```

You can remove the `__pycache__` and other temporary files if they were created:

```bash
rm -rf __pycache__
rm -rf runs/ logs/ checkpoints/
```

If you want to completely remove the virtual environment, you can do so with:

```bash
pyenv uninstall venv_py3_10_14_pytorch
```


# FlowFuse 2.23: MCP and ONNX nodes, FlowFuse AI Expert on the homepage, Application-level Permission Control, FlowFuse Expert for Self-Hosted, and more!

In this exciting release, we've shipped several features that accelerate development in Node-RED using AI, enable creation of AI agents using new Model Context Protocol nodes, provide application-level access controls for much more sophisticated user permissions management, and put an expert flow creator right on our homepage. It's a big one! Let's have a look.

## MCP Nodes

![Image of MCP nodes](https://flowfuse.com/blog/2025/10/images/mcp-nodes.png)&#x2A;[MCP nodes in the Node-RED palette, ready for use]*

With this release, you can now create a Model Context Protocol server using Node-RED. The new MCP nodes enable the creation of a MCP server so that you can create AI agents that will rely on the exact data that you want to surface to an LLM. As AI services rely upon data presented to them, whether it's anything available on the world wide web (as with LLMs generically) or more focused information, our MCP nodes provide the ability to expose specific resources so that an AI service will rely upon the right data without making all of your information public. It's a really exciting development. Check out [the Changelog entry](https://flowfuse.com/changelog/2025/10/mcp-nodes/) for more.

## FlowFuse AI Nodes

While MCP makes it possible to create AI agents to rely on the data you have chosen, the new FlowFuse AI nodes allow you to connect AI models of your choosing--including ones that you have trained yourself--to Node-RED to create any workflow you like. The ONNX (Open Neural Network Exchange) format lets you connect a model for whatever purpose you have in mind. This package ships with nodes for running your own custom-trained model, for classifying images, for object detection, and for image depth estimation. This is a huge step in the direction of fully-controlled AI automation inside of Node-RED on FlowFuse.

For self-hosted customers, once you've upgraded, contact [FlowFuse Support](https://flowfuse.com/support) to get access to these exciting new nodes.

## Application-Level Role-Based Access Control

![Image of application-level permissions](https://flowfuse.com/blog/2025/10/images/rbac2.png)&#x2A;[Control permissions at the application level]*

One of the key features of FlowFuse is the ability to manage Node-RED applications by choosing who gets access to what. Up to now, team owners had to configure permissions at the team level. But what if there are members of your team that should have write permissions to one Node-RED instance, but only viewer access to another? You would have to put those instances on different teams and configure permissions there. With many instances and applications, this could be a headache.

We've solved it. You can now manage permissions at the Application level. Now one and the same team can have users who can access some applications with one level of permissions, and and another application with a different level. We've heard your feedback on this need and are happy for you to give it a try!

## FlowFuse Expert

![Image of FlowFuse Expert](https://flowfuse.com/blog/2025/10/images/expert.png)&#x2A;[The FlowFuse Expert gives step-by-step instructions for building flows]*

You can now get complete instructions for building a Node-RED flow on [flowfuse.com]() using the FlowFuse Expert! This newest feature in the FlowFuse AI toolkit provides detailed guidance on creating Node-RED flows for any purpose you have in mind.

Head over to [flowfuse.com]() to check it out! We have big plans in mind for this feature, but can't say much yet. For now, it's enough to say that low code development is headed toward a whole new level with FlowFuse.

## FlowFuse Expert for Self Hosted Deployments

Speaking of AI assistance, self-hosted FlowFuse deployments have until now not had access to the FlowFuse Expert inside of Node-RED, helping to complete flows using natural language for explanation of flows, creation of Dashboard, Function, and Tables nodes, and Snapshot descriptions. These had been available only to FlowFuse Cloud customers. I'm happy to say that our many self-hosted customers now (finally) can get access to this tool, which helps speed flow creation exponentially. Contact [FlowFuse Support](https://flowfuse.com/support) to help get you setup.

## Import JSON at Instance Creation

Developers want the fastest way to spin up a functional Node-RED instance, and we've taken another step in that direction by offering the option of uploading a JSON file during the instance creation workflow.

# Sneak Peek

What if you could surface your FlowFuse Tables data outside of the FlowFuse environment, for broader consumption as you see fit? Or use data coming into Node-RED to predict maintainance needs? We have exciting things on the way for you!

## Don't Miss Node-RED Con 2025!

While not exactly a release item, I'd be remiss if I failed to mention Node-RED Conference 2025! We've got a great lineup of speakers who will cover a broad and deep variety of topics on the use of Node-RED. Check out the website and register here: <https://nrcon.nodered.org/.>{rel="&#x22;nofollow&#x22;"}

## What else is new?

For a complete list of everything included in our 2.23 release, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.23.0){rel="&#x22;nofollow&#x22;"}.

Your feedback continues to be invaluable in shaping FlowFuse's development. We'd love to hear your thoughts on these new features and any suggestions for future improvements. Please share your experiences or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Which of these new features are you most excited to try? Email me directly at <greg@flowfuse.com> - I'd love to hear from you!

## Try FlowFuse

### FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in the cloud within minutes.

### Self-Hosted

Get FlowFuse running locally in under 30 minutes using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# How to Log PLC Data to CSV Files

CSV files have been recording manufacturing data since the mid-1980s, over 40 years of continuous use across every industry. Logging to databases like InfluxDB, TimescaleDB, or PostgreSQL is excellent for real-time analytics, complex queries, and large-scale operations. But many organizations still rely on CSV files for good reasons: regulatory compliance, legacy system integration, offline analysis, or simply because it's the format their teams know and trust. If you're reading this, you're likely one of them and need a reliable solution.

CSV files offer something databases can't always guarantee: universal compatibility and permanence. Excel opens them instantly, databases import them natively, and analysis tools expect them. No licensing, no vendor tie-ins, no format obsolescence. Data captured decades ago is still perfectly readable today and will be readable decades from now, regardless of what systems you're using.

The truth is, most manufacturers use both for distinct purposes. CSVs remain the standard on the shop floor for data loggers that write locally during network outages, regulatory submissions requiring immutable audit trails, batch documentation archived for decades, and data exchange with suppliers and auditors.

Meanwhile, databases handle real-time monitoring and automated alerts, cross-functional analytics, high-frequency sensor queries, and dynamic relationships across materials and equipment.

This isn't an either/or choice. It's a dual-track system where databases provide operational speed and CSVs provide the permanence layer, ensuring your compliance records and critical data outlive any technology stack.
This guide shows how to implement PLC data logging with **FlowFuse** in a way that keeps running, stable, resilient, and production-ready.

:video{ariaLabel="Video showing FlowFuse collecting data from a PLC using OPC UA and logging it to a CSV file." autoPlay="true" height="1474" loop="true" muted="true" playsInline="true" preload="none" width="3024"}&#x2A;Video showing FlowFuse collecting data from a PLC using OPC UA and logging it to a CSV file.*

## Prerequisites

Before getting started, make sure you have:

- **A running FlowFuse instance** – If you don’t have one yet, [sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} for FlowFuse and set up an instance on your edge device. This device will manage data collection and logging from your PLC using Node-RED.

## Step 1: Setting Up PLC Communication in FlowFuse

Before logging data, you need a stable connection to your PLC. FlowFuse uses Node-RED under the hood, which supports every major industrial protocol through community-maintained packages. This means you can connect to any equipment, regardless of age or manufacturer.

### Choosing Your Protocol

The right protocol depends on what your PLC supports.

Modern PLCs typically offer open standards like OPC UA, Modbus TCP, or EtherNet/IP. These protocols work across different manufacturers and give you the most flexibility.

If your PLC supports OPC UA, that is likely your best option. It is becoming the common language across industrial equipment, Siemens, Rockwell, Schneider, and most other manufacturers support it. This is also the option I used in the demo I prepared for this article. For more information on how to use OPC UA with your PLC, you can refer to [this article](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/).

Legacy systems use vendor-specific protocols: [S7](https://flowfuse.com/blog/2025/01/integrating-siemens-s7-plcs-with-node-red-guide/) for Siemens, MC Protocol for Mitsubishi, FINS for Omron, and [EtherNet/IP](https://flowfuse.com/blog/2025/10/using-ethernet-ip-with-flowfuse/) for Allen-Bradley. If your PLC only speaks its native language, Node-RED has dedicated nodes for each one.

### Installing the Right Node

Node-RED's package ecosystem includes nodes for virtually every industrial protocol. The most common ones are:

- `node-red-contrib-modbus` – Modbus RTU/TCP devices
- `node-red-contrib-s7` – Siemens S7-300/400/1200/1500
- `node-red-contrib-opcua` – OPC UA servers
- `node-red-contrib-cip-ethernet-ip` – Allen-Bradley PLCs
- `node-red-contrib-mcprotocol` – Mitsubishi Q/L series
- `node-red-contrib-omron-fins` – Omron PLCs

To install a package in FlowFuse, go to the palette manager (hamburger menu → Manage palette → Install) and search for the node you need. Installation takes seconds.

### Configuring Your Connection

Drag the appropriate input node onto your canvas and configure it according to the node's documentation.

### Verifying Data Quality

Before building your logging flow, verify you're getting clean, consistent data. Connect a debug node to your PLC input, deploy, and watch the incoming messages.

You should see values updating at your configured interval with consistent structure and sensible numbers. No connection errors, timeouts, or garbage data.

If something's wrong, intermittent connections, bad values, protocol errors, fix it now. Connection problems multiply when you add logging logic on top.

A stable PLC connection is the foundation. Get this right, and the rest is straightforward.

## Step 2: Building the Basic CSV Logging Flow

With a stable PLC connection verified, you can now build the flow that writes data to CSV files.

### Understanding the Data Flow

The logging system needs four components working together:

1. PLC input node that collects data at regular intervals
2. Function node that adds timestamps and handles daily file rotation
3. CSV node that formats data into proper CSV structure
4. File node that writes to disk

### Adding Timestamps and Daily File Rotation

Your PLC data needs timestamps and a way to organize files by date.

1. Drag a function node onto your canvas
2. Connect it to your PLC input node
3. Double-click the function node and add this code:

```javascript
const now = new Date();
const timestamp = now.toISOString();

// Create filename with today's date (YYYY-MM-DD format)
const dateStr = now.toISOString().split('T')[0];
const filename = `./plc_data_${dateStr}.csv`;

// Structure the data
msg.payload = {
    timestamp: timestamp,
    temperature: msg.payload.temperature,
    pressure: msg.payload.pressure,
    flowRate: msg.payload.flowRate
};

// Store filename for the file node
msg.filename = filename;

return msg;
```

4. Click Done

This creates a new file each day automatically. When the date changes, the filename changes, and Node-RED starts writing to a fresh file. Your logs stay organized by date: `plc_data_2025-10-16.csv`, `plc_data_2025-10-17.csv`, and so on.

### Formatting Data with the CSV Node

The CSV node handles all the formatting work, proper escaping, column ordering, and headers.

1. Drag a CSV node onto your canvas
2. Connect it to your function node
3. Double-click to configure:
   - Set the columns: `timestamp,temperature`
   - Enable "first row contains column names"
   - Choose comma as the separator
   - Choose RFC 4180 as parser (this handles commas in your data, like alarm messages or status text, by wrapping them in quotes so they don't break the CSV structure)
4. Click Done

![Image showing CSV node configuration](https://flowfuse.com/blog/2025/10/images/csv-config.png){dataZoomable=""}*Image showing CSV node configuration*

The CSV node converts your data object into a properly formatted CSV line with headers included automatically when a new file is created.

### Writing to File

The file node writes your formatted CSV data to disk.

1. Drag a file node onto your canvas
2. Connect it to your CSV node
3. Double-click to configure:
   - Set filename to `msg.filename` (uses the dynamic filename from your function)
   - Choose "append to file" mode
   - Enable "Create directory if it doesn't exist"
4. Click Done
5. Deploy your flow

![Image showing Write node configuration](https://flowfuse.com/blog/2025/10/images/write-file-config.png){dataZoomable=""}*Image showing Write node configuration*

Let it run. Each day at midnight, the system automatically starts a new file. Old files stay untouched, new data goes to today's file.

This daily rotation keeps file sizes manageable and makes it easy to find data from specific dates. But there are still edge cases to handle, what happens when disk space runs low or file writes fail? The next step addresses these reliability issues.

## Step 3: Monitoring Disk Usage

Running a logging system continuously means files accumulate. Monitor disk space to prevent unexpected failures when storage runs low.

Add disk space monitoring to prevent unexpected failures.

1. Drag an inject node onto your canvas and configure it to trigger every hour
2. Add a Function node with the following code. Since the code uses the fs module, make sure to import it within the setup of function node:

```javascript
try {
    // Get disk usage information
    const stats = fs.statfsSync('./');

    const totalSpace = stats.blocks * stats.bsize;
    const freeSpace = stats.bfree * stats.bsize;
    const usedSpace = totalSpace - freeSpace;
    const percentUsed = (usedSpace / totalSpace) * 100;

    msg.payload = {
        totalGB: (totalSpace / (1024 ** 3)).toFixed(2),
        freeGB: (freeSpace / (1024 ** 3)).toFixed(2),
        usedGB: (usedSpace / (1024 ** 3)).toFixed(2),
        percentUsed: percentUsed.toFixed(2)
    };

    // Warning threshold
    if (percentUsed > 90) {
        msg.warning = `Disk space critical: ${percentUsed.toFixed(1)}% used`;
    }

    return msg;

} catch (err) {
    msg.payload = { error: err.message };
    return msg;
}
```

3. Connect it to your notification system to alert when space is critical, for notification you can use [email](https://flowfuse.com/node-red/notification/email/), [telegram](https://flowfuse.com/node-red/notification/telegram/), discord with [FlowFuse](https://flowfuse.com/node-red/notification/discord/).
4. Deploy the flow

Now you'll get warnings before disk space becomes critical, giving you time to archive old data or expand storage.

## Step 4: Handling Connection Interruptions

Network issues, PLC restarts, or equipment maintenance can cause connection drops. Your logging system should handle these gracefully and automatically resume when the connection is restored.

Most PLC nodes emit error events when a connection fails. Add error handling to detect and log these events.

1. Add a Catch node configured to monitor your PLC input node and Write File node.
2. Drag a Function or Change node to format the error messages according to your chosen notification method, and connect it to the Catch node.
3. Connect the node that formats the error message to your selected Notification node.
4. Deploy the flow.

Below is the complete flow we have built throughout this article.

*Note: When testing with the Inject node, bypass the OPC UA Client and inject data directly into the logger flow.*

::render-flow{:height='300'}
```json
[{"id":"66776385db5794bc","type":"group","z":"FFF0000000000001","name":"","style":{"fill":"#ffcf3f","label":true,"fill-opacity":"0.57"},"nodes":["ac0d35a6466cfcb4","4aff5b57cbb63b8f","a5c5746934670306","d796d3aee8ea0343","23ebc0da4315ac46","181ed86f9c11d1f7","b34d440897108110","575ed67714072973","d08353a9c90b0396","e719ae6fee22c812","2518dc909d447655"],"x":94,"y":271.5,"w":1112,"h":269.5},{"id":"ac0d35a6466cfcb4","type":"csv","z":"FFF0000000000001","g":"66776385db5794bc","name":"","spec":"rfc","sep":",","hdrin":true,"hdrout":"once","multi":"one","ret":"\\r","temp":"timestamp,temperature","skip":"0","strings":true,"include_empty_strings":"","include_null_values":"","x":770,"y":320,"wires":[["a5c5746934670306"]]},{"id":"4aff5b57cbb63b8f","type":"function","z":"FFF0000000000001","g":"66776385db5794bc","name":"Daily PLC Logger","func":"// @ts-ignore Node ≥ 18.15 provides fs.statfsSync; editor types may lag\n\nconst now = new Date();\nconst dateStr = now.toISOString().split('T')[0];\nconst timestamp = now.toISOString();\n\nconst filename = `./plc_data_${dateStr}.csv`;\n\nmsg.payload = {\n    timestamp: timestamp,\n    temperature: msg.payload,\n};\n\nmsg.filename = filename;\n\n// Track last date in flow context\nconst lastDate = flow.get('lastDate') || '';\nif (lastDate !== dateStr) {\n    msg.reset = true; // Will trigger CSV node to write headers\n    flow.set('lastDate', dateStr);\n} \n\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":610,"y":320,"wires":[["ac0d35a6466cfcb4"]]},{"id":"a5c5746934670306","type":"file","z":"FFF0000000000001","g":"66776385db5794bc","name":"Log Data to CSV file","filename":"filename","filenameType":"msg","appendNewline":true,"createDir":true,"overwriteFile":"false","encoding":"none","x":940,"y":320,"wires":[["2518dc909d447655"]]},{"id":"d796d3aee8ea0343","type":"OpcUa-Client","z":"FFF0000000000001","g":"66776385db5794bc","endpoint":"","action":"read","deadbandtype":"a","deadbandvalue":1,"time":10,"timeUnit":"s","certificate":"n","localfile":"","localkeyfile":"","securitymode":"None","securitypolicy":"None","useTransport":false,"maxChunkCount":1,"maxMessageSize":8192,"receiveBufferSize":8192,"sendBufferSize":8192,"setstatusandtime":false,"keepsessionalive":false,"name":"","x":420,"y":320,"wires":[["4aff5b57cbb63b8f"],[],[]]},{"id":"23ebc0da4315ac46","type":"inject","z":"FFF0000000000001","g":"66776385db5794bc","name":"","props":[{"p":"topic","vt":"str"}],"repeat":"5","crontab":"","once":false,"onceDelay":0.1,"topic":"ns=3;i=1004","x":220,"y":320,"wires":[["d796d3aee8ea0343"]]},{"id":"181ed86f9c11d1f7","type":"catch","z":"FFF0000000000001","g":"66776385db5794bc","name":"","scope":["a5c5746934670306"],"uncaught":false,"x":180,"y":420,"wires":[["b34d440897108110"]]},{"id":"b34d440897108110","type":"debug","z":"FFF0000000000001","g":"66776385db5794bc","name":"Errrors","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":630,"y":420,"wires":[]},{"id":"575ed67714072973","type":"function","z":"FFF0000000000001","g":"66776385db5794bc","name":"Check Disk Space","func":"try {\n    // Get disk usage information\n    const stats = fs.statfsSync('./');\n\n    const totalSpace = stats.blocks * stats.bsize;\n    const freeSpace = stats.bfree * stats.bsize;\n    const usedSpace = totalSpace - freeSpace;\n    const percentUsed = (usedSpace / totalSpace) * 100;\n\n    msg.payload = {\n        totalGB: (totalSpace / (1024 ** 3)).toFixed(2),\n        freeGB: (freeSpace / (1024 ** 3)).toFixed(2),\n        usedGB: (usedSpace / (1024 ** 3)).toFixed(2),\n        percentUsed: percentUsed.toFixed(2)\n    };\n\n    // Warning threshold\n    if (percentUsed > 90) {\n        msg.warning = `Disk space critical: ${percentUsed.toFixed(1)}% used`;\n    }\n\n    return msg;\n\n} catch (err) {\n    msg.payload = { error: err.message };\n    return msg;\n}","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[{"var":"fs","module":"fs"}],"x":430,"y":500,"wires":[["e719ae6fee22c812"]]},{"id":"d08353a9c90b0396","type":"inject","z":"FFF0000000000001","g":"66776385db5794bc","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"1800","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":210,"y":500,"wires":[["575ed67714072973"]]},{"id":"e719ae6fee22c812","type":"debug","z":"FFF0000000000001","g":"66776385db5794bc","name":"Disk Full Warning !","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":670,"y":500,"wires":[]},{"id":"2518dc909d447655","type":"debug","z":"FFF0000000000001","g":"66776385db5794bc","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1110,"y":320,"wires":[]},{"id":"7131c5523d86fe8b","type":"global-config","env":[],"modules":{"node-red-contrib-opcua":"0.2.342"}}]
```
::

## Conclusion

You now have a production-ready PLC data logging system built on FlowFuse. It addresses the key reliability issues that typically cause downtime, connection drops, write failures, disk space limits, and daily file rotation, turning a simple flow into one that can run unattended for months.

The use of CSV ensures long-term data accessibility. Every analytics platform, database, and spreadsheet can read it, and it will remain usable decades from now, regardless of what tools or systems you adopt in the future.

Start small: connect one PLC, verify data quality, and deploy your first logging flow. Then gradually add error handling, storage monitoring, and redundancy as needed. Over time, this setup becomes a foundation for scalable, dependable industrial data collection.

FlowFuse makes this process straightforward by combining Node-RED’s flexibility with enterprise-grade management and monitoring. You can deploy updates remotely, manage devices across multiple sites, and standardize data collection, all from a single platform.

And while CSV is a reliable starting point, FlowFuse also integrates seamlessly with modern databases and historians like InfluxDB, TimescaleDB, and MySQL. Even better, FlowFuse Cloud includes a built-in PostgreSQL service and an AI Query Node that lets you explore your data conversationally, turning raw logs into actionable insights.

For more on how FlowFuse connects PLCs across OPC UA, Siemens S7, EtherNet/IP, and Modbus to collect and route industrial data, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).

> You can [talk to our team](https://flowfuse.com/book-demo/), they’ll walk you through a live demo showing how FlowFuse helps you connect, collect, transform, and visualize your industrial data reliably and intelligently.


# Introducing FlowFuse Expert

We've had an exciting week launching MCP and ONNX nodes, and now we’ve added something else we're really excited about: **FlowFuse Expert**. It helps you build flows by providing a step-by-step recipe to build an application in FlowFuse and Node-RED, in plain language.

Oh, and it was created by and is running on FlowFuse technology! Take a look:

Instead of hunting through documentation or piecing together forum posts, you simply describe what you want to build and get a clear recipe for creating it.

Head over to [flowfuse.com]() and you'll see it right on the home page. Type what you're trying to build. FlowFuse Expert might ask a few questions to clarify your setup, and once you answer, it will provide a simple, easy-to-follow recipe: which nodes you need with exact copyable names, how to configure them, and how to wire them together.

:video{ariaLabel="FlowFuse Expert: Providing Recipe for Connecting Serial Devices" autoPlay="true" height="1726" loop="true" muted="true" playsInline="true" preload="none" width="3024"}*FlowFuse Expert: Providing a Recipe for Connecting Serial Devices*

Down the road, we plan to integrate it directly into the FlowFuse environment. So if you're already using [FlowFuse Expert](https://flowfuse.com/blog/2025/07/flowfuse-ai-assistant-better-node-red-manufacturing/) to speed up your development, FlowFuse Expert will be right there alongside it, answering questions and providing recipes for whatever you're trying to build.

## Why We Built This

We kept seeing people get stuck at the same point. They were excited about FlowFuse and Node-RED, with a clear idea of what they wanted to build, but weren't sure how to get started.

That gap between vision and implementation shouldn't be a bottleneck, nor should time be wasted reading long documents or articles. FlowFuse Expert provides the starting point, the specific guidance you need to start building, without dumbing anything down.

## How It Works

FlowFuse Expert is built on and runs entirely using FlowFuse technology itself. It is powered by RAG + GPT-4.1. We've ingested all of our blogs, changelogs, and documentation into a vector database. When you describe what you want to build, FlowFuse Expert searches this knowledge base and uses that context to generate accurate, and super simple step-by-step instructions.

## Try FlowFuse

FlowFuse Expert is just one of the many powerful tools we’ve made available to everyone. With FlowFuse, you can deploy, scale, and manage Node-RED effortlessly, accelerate development with FlowFuse AI-assistance, and build your own MCP server. Let AI agents monitor and control industrial applications using MCP nodes, or run your custom AI models in Node-RED with ONNX nodes.

[Start your free FlowFuse trial today](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and see how you can deploy, manage, and scale secure Node-RED to build powerful industrial applications while exploring the new AI tools we’ve made available for FlowFuse users within Platform.


# The Node-RED Revolution: How Low-Code is Democratizing Industrial Automation

To understand the impact Node-RED has had on industrial automation, it's useful to understand where it has come from and what has enabled its success.

Almost 20 years ago, I was helping to develop an MQTT broker. One of the features of the broker was to create message transformations; taking messages from one topic, modifying their structure and republishing on another topic. It was a really useful feature, but it was only ever exposed via a programming API. Customers had to write lots of code to make use of it. It was also difficult to examine what transformations had already been created. I would often find myself getting a piece of paper and writing out the transformations to help spot any unexpected interactions between them. At the time, I dreamed of a way to better visualise what was happening - but that was far out of scope of our requirements at the time.

Fast forward a few years, and I found myself faced with a similar challenge; working on customer projects that often required pulling data from different sources and having to write the same bits of code again and again to get the job done. This time, I was more in a position to do something about it, and after a couple days of coding, I had a simple demo of a tool that could visualise MQTT topics and how messages would get routed between them. Then we added a way to pull data from a Serial port, a way to run custom code against the messages, a way to do HTTP requests - each week, a new customer project would raise a new requirement and this little side project would prove its worth again and again.

This is, of course, the Node-RED origin story. But how has this little side project become the widely adopted success it has - and why is it so valuable to Industrial users? I think there are three parts to this; its low-code visual nature, its Open Source availability and its extensibility.

## Low-Code Visualisation

One of my original motivations for Node-RED was to save time by not having to write the same pieces of boiler-plate code each time I needed to do a particular task. Dragging a node into the workspace takes seconds and replaces minutes - or even hours - of traditional code development time.

This abstraction empowers anyone to start building applications in Node-RED. System engineers understand the problem they are trying to solve. Node-RED gives them the ability to build their solutions without having to think about the lines of code each node represents - they can focus on the task at hand.

## Open Source

The move away from proprietary solutions gives users more control and influence over the tools they use. Open Source Software brings principles of collaboration, transparency, and interoperability. It was a very deliberate choice to make Node-RED Open Source in its early days; we knew the project’s future lay in building an open community around it - with contributors from many backgrounds.

## Extensibility

A natural consequence of the Open Source path the project took was to make it easy to extend what Node-RED could do. Enabling the community to build their own nodes greatly accelerated the adoption of the project - with the Open Source ethos underpinning that work.

Whilst we see Node-RED used in many industries, it finds a natural home in the Industrial automation space. Being able to run anywhere from edge-of-network devices to the cloud gives a lot of flexibility in the types of solutions it can be applied to. At its heart, Node-RED is all about accessing data, wherever it may be and doing something meaningful with that data.

We see it being used alongside traditional PLCs, providing an easier point of integration - pulling data from many different systems in one place, providing a dashboard visualization in situ, and making the data available to the wider organization. Having a consistent developer experience for all those tasks makes Node-RED a natural choice.

## Scaling Node-RED within your organization

Through the early life of the project, we focussed on the core of Node-RED being a high-quality, reliable, low-code development tool. Through the community, we knew there were companies beginning to adopt Node-RED at scale, but some of the challenges they were facing were out of scope of what the core project could address.

The flexibility of Node-RED comes at a cost of how you scale and manage your Node-RED infrastructure. All organizations have a responsibility to keep their IT infrastructure secured and well-maintained - and that has to be considered when adopting any technology.

For all of its strengths, the choice of Open Source at the core does pose some questions that should not be overlooked. For example, who can be relied on to fix issues if you don’t have the engineering capacity within your own organization? How do you manage all of those Node-RED instances throughout your organization?

These were the questions that motivated me to start FlowFuse - and is where we elevate Node-RED to be a robust enterprise-ready platform. Just as the early development of Node-RED was driven by our own requirements, FlowFuse has been built based on first-hand experience of what’s needed to scale Node-RED.

A great example is one of our early customers who is a large manufacturer in the US. They began adopting Node-RED in 2018 across their facilities. At the time, they had to build a lot of custom automation to manage it, but the overheads were becoming unmanageable. With their small IT team, they found it hard to properly track the different versions of flows deployed across their sites. They moved over to FlowFuse which has enabled them to continue scaling their operations and now have thousands of Node-RED instances being managed by the platform.

This is a common pattern we see; FlowFuse solves the operational challenges that slow down digital transformation; engineers are able to focus on solving real business problems with confidence.

## Join us at Node-RED Con

Next month we’re sponsoring the Node-RED Con virtual event - a free day of talks from the Node-RED community all about how it’s being used in industry. There are lots of fascinating talks scheduled and I’d urge you to [register to attend](https://events.zoom.us/ev/AqhqiQ8mTK2lnAoOEH8c8TA1a_9MzVhZq_T7d1-kMHlHDt2_Qh_0~AtAGpC_uhX5LxGrRFYeO63TLtQlUXVUdpy3DY5mEZFgC79PyUeKZzgp8njVUDVZdS3SBo8HS1wGVPdosNhe2VVxCpw){rel="&#x22;nofollow&#x22;"}.


# What's the Difference Between Node-RED and FlowFuse

FlowFuse is an industrial data platform built on Node-RED. Many Fortune 500 manufacturers and Industrial IoT companies use it to run mission-critical operations where downtime is not an option.

If you're hearing about FlowFuse for the first time, you might wonder: &#x2A;"If it's built on Node-RED, what makes it different?"*

This article answers that question. You'll learn what FlowFuse adds to Node-RED, whether it competes with Node-RED, and how to decide which platform is right for you.

## Where Node-RED Came From

To understand what FlowFuse adds, it helps to first look at Node-RED itself.

In 2013, Nick O'Leary (CTO and Founder of FlowFuse) and Dave Conway-Jones at IBM identified a problem: connecting devices, APIs, and services required hundreds of lines of code for tasks that should be straightforward. Their solution was to make programming visual. Drag nodes, draw connections, deploy your logic.

Engineers who understood systems but couldn't code could suddenly build applications. Tasks that took weeks were completed in hours. Node-RED runs on laptops, Raspberry Pis, factory floor gateways, and enterprise servers. The community has built thousands of nodes for most scenarios you'll encounter.

For small projects, prototypes, and learning, Node-RED provides what you need without overhead.

## When Limitations Surface

Your Node-RED flow works. It monitors equipment, processes data, and displays dashboards. Then the question arises: &#x2A;'Can we deploy this across all 50 of our factories efficiently, without wasting time or money?*

That question exposes the limitations of standalone Node-RED:

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

You need to deploy to 50 sites across three continents without manual setup at each location. Five engineers need to work on improvements without conflicts. You need alerts when any instance goes down because downtime stops production and costs money. Your security team requires SSO integration, role-based access control, and audit trails. You need to push updates to all sites at once, not travel to each location over weeks. When someone deploys a breaking change on Friday afternoon, you need to roll it back in seconds.

This is where Node-RED ends and FlowFuse begins.

**Node-RED gives you the tools to build. FlowFuse provides the infrastructure to deploy, manage, and scale what you've built.**

## What FlowFuse Adds

FlowFuse doesn't replace Node-RED. You use the same visual editor, nodes, and flows. FlowFuse adds the operational layer that transforms Node-RED from a development tool into a production platform.

### Security and Compliance

Standard Node-RED leaves authentication to you, typically basic auth or custom middleware. For personal projects, this suffices. Production environments controlling industrial systems need more.

FlowFuse provides role-based access control (RBAC) to define who edits flows versus who views them. Single Sign-On via SAML, LDAP, and OIDC integrates with your existing identity systems. Audit logs capture every deployment with details on who made changes and when. Database credentials and API tokens are managed through encrypted secrets storage, keeping them out of flow exports and version control.

For supply chain security, FlowFuse generates a Software Bill of Materials (SBOM) listing every node and dependency across your instances. Security teams can scan for vulnerabilities and track what needs updating.

### Team Collaboration and Version Control

Node-RED was built for individual developers. When two people edit the same instance, the last save wins. No version history exists. No way to review changes before deployment. No rollback option.

FlowFuse enables multi-user teams working on shared projects with proper permissions. Every deployment creates a snapshot, a complete record of your flows at that point in time. Compare snapshots to track changes or restore previous versions when deployments break production.

### Remote Device Management

Node-RED instances running on edge devices in remote factories, warehouses, or hard-to-reach locations create operational challenges. Troubleshooting means traveling on-site or configuring complex VPN access.

FlowFuse provides centralized management through its Device Agent, a lightweight service installed on remote devices that establishes secure connections back to your FlowFuse instance. From one dashboard, you see and control your entire fleet. Open any device's editor or view its logs through secure tunnels without exposing ports or setting up VPNs. Push updates over-the-air to individual devices or groups.

### Deployment Pipelines and Scalability

Standalone Node-RED moves code from development to production through manual export and import. This doesn't scale and introduces errors with each manual step. Managing one instance is simple. Managing hundreds requires standardization.

FlowFuse builds structured deployment into the platform. Create Development, Staging, and Production environments for each project. Promote snapshots between stages with single clicks. Organize devices into groups by location or function, then target updates to specific groups. Deploy to all North American packaging lines while leaving European facilities on their current version. The platform organizes work through teams and projects, giving each group isolated resources while maintaining central oversight.

### Observability and Monitoring

Standalone Node-RED displays logs from a single instance. When you're running multiple instances across different locations, you need centralized visibility. Building this yourself means integrating Prometheus, configuring exporters, creating Grafana dashboards, and setting up alerting, weeks of specialized work.

FlowFuse provides centralized observability. View logs from any instance, check audit logs for specific deployments, monitor real-time status showing when each instance was last seen, and track CPU and memory usage across your entire fleet, all from one interface.

### Managed Infrastructure

Running Node-RED means managing servers or edge devices, handling installations, planning updates, configuring backups, and preparing disaster recovery. At scale, this becomes a full-time responsibility.

FlowFuse Cloud is fully managed, they handle infrastructure, you build applications. FlowFuse Self-Hosted runs on your infrastructure but manages orchestration, updates, and monitoring. Both options deliver over-the-air updates for Node-RED versions, security patches, and configuration changes without downtime.

### Certified Nodes

The Node-RED community has built thousands of nodes covering most use cases. Production environments need assurance about maintenance, security vulnerabilities, and long-term support.

FlowFuse's Certified Nodes program vets community contributions for quality, security, and maintenance. FlowFuse takes ongoing responsibility for certified nodes and accepts certification requests for nodes you need.

### Development Acceleration

Node-RED's visual programming is fast, but real-world development has friction points. Complex function nodes and UI templates require time and coding skill. Understanding teammates' flows isn't always straightforward. Building the same patterns across projects becomes repetitive.

FlowFuse Expert tackles these challenges directly in the editor. Describe your need in plain language, it generates function nodes or UI templates, explains existing flows, writes SQL queries, suggests relevant nodes, and creates documentation. This speeds up experienced developers while making Node-RED accessible to those still learning.

The Blueprint Library provides tested and proven templates for common industrial scenarios, OEE dashboards, Andon systems, operator terminals. Instead of building from scratch, start with working solutions and customize them for your needs.

Team Library enables reusability within your organization. Export a flow to your Team Library once, and it's available across all team instances. Your team maintains consistent patterns without recreating the same work.

### Commercial Support

Node-RED's community provides excellent support for learning and troubleshooting through forums and discussions. Production outages costing money per minute require faster resolution and guaranteed response times.

FlowFuse offers commercial support with Service Level Agreements. Work directly with engineers who understand Node-RED internals, have encountered your problems before, and can architect solutions that scale.

## Are Node-RED and FlowFuse Competitors?

No. Node-RED and FlowFuse are not competitors, they’re complementary. FlowFuse is built directly on top of Node-RED, and the two projects share deep roots. In fact, FlowFuse employees, including Node-RED’s co-creator Nick O’Leary, are among the most active contributors to Node-RED itself. They review pull requests, write code, run Node-RED Con, and maintain long-term support for the community.

When Node-RED improves, FlowFuse improves too. This is the same dynamic seen in other open-source ecosystems: Linux thrives alongside Red Hat, Kubernetes powers enterprise platforms, and PostgreSQL continues to evolve while vendors provide enterprise features. The open-source project remains free and independent, while the commercial platform adds operational value on top.

FlowFuse also invests back into the ecosystem. A good example is the [FlowFuse Dashboard](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"} (often called Node-RED Dashboard 2.0), which replaced the deprecated original Node-RED Dashboard. By sponsoring and maintaining this project, FlowFuse ensures the community continues to have a modern, supported visualization tool.

And importantly, your flows remain portable. Anything you build in FlowFuse works in plain Node-RED. There is no vendor lock-in. FlowFuse exists to extend Node-RED, not replace it.

## Conclusion

Node-RED is a development tool. FlowFuse is a production platform.

Node-RED lets you build flows. FlowFuse lets you deploy them securely, collaborate, manage them centrally, and scale them across your organization.

FlowFuse takes what you’ve built in Node-RED and makes it production-ready.

**Want to See FlowFuse in Action?**

This article highlighted the key differences between Node-RED and FlowFuse, but many advanced features and real-world use cases remain to be explored.

[Book a demo with our team](https://flowfuse.com/book-demo/) to see a complete live demo and discover how FlowFuse extends Node-RED for enterprise operations, or [start a free trial](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"} to experience it yourself.


# OpenAI's AgentKit or FlowFuse: Choosing the Right Low-Code App for Your Needs

AI is moving fast, and with it, the tools we use to build intelligent applications.
Two interesting platforms that have emerged are OpenAI's AgentKit and FlowFuse.
While both offer AI capabilities, they are designed for very different purposes.
Let's break down the key differences to help you decide which platform is the
right fit for your needs.

## OpenAI's AgentKit: For building AI agents

[OpenAI's AgentKit](https://openai.com/index/introducing-agentkit/){rel="&#x22;nofollow&#x22;"} is a toolkit for developers who want to build and deploy AI
agents. Key features of AgentKit include the Agent Builder, a low-code visual environment
for designing multi-agent workflows, and a Connector Registry
for managing data and tool connections.
It also provides ChatKit for embedding chat-based agent experiences,
Expanded Evals for measuring agent performance, and reinforcement fine-tuning (RFT)
to customize reasoning models. Essentially, AgentKit is for developers who are
building AI-native applications and need a robust set of tools to create and
manage their agents within the OpenAI ecosystem.

## FlowFuse: The Bridge Between the Physical and Digital Worlds

FlowFuse, on the other hand, is built on the foundation of [Node-RED](https://flowfuse.com/node-red/),
also a low-code platform. FlowFuse is specifically designed for industrial and
IoT applications, with a strong focus on what's known as "the edge" – the
physical world where data is generated by assets like sensors, machines, and other
devices.

This is where the user's point about edge data extraction comes in. FlowFuse
excels at managing and scaling fleets of Node-RED instances running on edge
devices. This allows engineers to easily and securely collect data from all their
industrial devices and sensors, effectively "fusing the physical with the digital."

## Key Differentiators

So, how do these two platforms really differ? The first key differentiator is
their core focus. AgentKit is for building AI agents that live in the digital
world of applications and services, whereas FlowFuse is for building and managing
end-to-end data applications that interact with the physical world through edge
devices.

AgentKit, in its current form, does not have a focus on edge data extraction.
Its purpose is to help you build the "brains" of an AI. FlowFuse's entire reason
for being is to provide the "nervous system" that connects those brains to the
real world. It's all about managing edge deployments and ensuring a reliable flow
of data from the edge.

The [FlowFuse Expert](https://flowfuse.com/blog/2025/07/flowfuse-ai-assistant-better-node-red-manufacturing/) is a powerful tool that helps engineers, even those
who aren't expert coders, to build and manage their Node-RED flows. For instance,
you can describe what you need in plain English and the assistant will generate
the necessary code. It can also analyze a complex flow and explain what it does,
making it easier to maintain. Furthermore, the assistant is a huge time-saver as
it can create realistic test data and even help you build custom dashboards to
visualize your data.

So, while AgentKit is a toolkit for building AI agents, the FlowFuse Expert
is a tool that helps you build the applications that connect to the physical world.
It empowers any engineer to fuse the physical with the digital by making it easier
than ever to create the logic needed to collect, transform, and act on data from
the edge.

What's more, FlowFuse already supports creating [AI and RAG](https://flowfuse.com/blog/2025/07/flowfuse-release-2-20/#new-blueprint-agentic-ai-with-retrieval-augmented-generation) integrations and will soon be releasing dedicated MCP nodes that greatly simplifies low-code building of AI Agents.
enabling AI to work directly at the edge. This means you can create AI
agents that not only process data from physical devices but also make decisions
right where the data is generated, with a lot less latency due to less Cloud
round-trips. This is especially important for industrial applications where
milliseconds matter.

## Conclusion

Choosing between OpenAI's AgentKit and FlowFuse comes down to what you're trying
to achieve. If your goal is to build sophisticated, AI-powered agents for your
applications and your focus is on the digital realm, then OpenAI's AgentKit is
the clear choice. However, if you need to connect to, manage, and extract data
from physical devices in the real world, and you want to empower your engineers
with an FlowFuse Expert that makes this process easier, then FlowFuse is the
platform for you.

In the end, these are two powerful but very different tools. AgentKit is for the
AI developer, while FlowFuse is for the industrial engineer who wants to bring
the power of AI to the edge. We're looking forward to how these technologies can
be combined in future!

## Ready to Connect Your Physical World?

While AgentKit is perfect for building AI agents in the digital realm, FlowFuse
is built for the challenges of industrial and IoT data: managing edge
deployments at scale, connecting to diverse industrial protocols, and ensuring
reliable data flow from thousands of physical devices.

Whether you're monitoring production lines, building predictive maintenance
systems, or implementing Industry 4.0 initiatives, FlowFuse provides the
infrastructure to collect, transform, and act on data from the edge.

**Start building today:** [Try FlowFuse free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} or [book a demo](https://flowfuse.com/book-demo/) to
see how we help teams manage industrial data at scale.


# How to Connect Any PLC to MQTT in Under an Hour

Getting PLC data into systems where it can be monitored, analyzed, and acted upon is essential for modern manufacturing. MQTT has become the standard for moving this data. It's lightweight, handles unreliable networks well, and excels at real-time streaming. Once your PLC data is published to MQTT, it creates a common pipeline that IT systems understand, flowing easily to cloud platforms, analytics tools, dashboards, and eliminating protocol translation headaches.

:product-update-note

The protocol itself is simple. But implementation in a real factory, with actual PLCs and production networks, is where things fall apart. Costs pile up, timelines drag on, and you end up needing expertise that's hard to find.

This guide cuts through that complexity. You'll learn how to connect PLCs using MQTT without the typical headaches. We'll walk through extracting data from any PLC protocol, transforming it properly, and publishing it reliably, with working examples you can adapt to your own setup.

## Why PLC-to-Cloud Gets So Complicated

Before diving into the solution, it's worth understanding why this is so difficult.

First, there's the proprietary protocols. Factory floors have PLCs from different manufacturers, each speaking their own language: Modbus, OPC-UA, Ethernet/IP, Profinet, FINS, etc. Getting data out means dealing with all of them at once, maintaining multiple drivers and troubleshooting different failure modes.

Then there's the networking challenge. Factory networks weren't built for internet connectivity. Isolated subnets, strict firewalls, and security-conscious IT departments mean getting approval for gateways (whether edge devices or software platforms) involves security reviews and architecture decisions that can drag on for months.

The costs add up quickly. Cloud platforms charge per message, and streaming data from dozens of machines easily reaches thousands per month, before gateway hardware and licenses.

And there's the expertise gap. Plant engineers know PLCs but not cloud APIs. IT teams know infrastructure but not industrial protocols. You end up needing expensive consultants, turning what should be straightforward into a six-figure project.

The solution lies in low-code integration platforms that consolidate protocol handling, edge computing, and cloud connectivity into a single system. This guide demonstrates one approach using FlowFuse, a platform built on Node-RED that addresses each challenge outlined above.

## Prerequisites

Before you start, make sure you have the following:

- A properly configured and fully operational PLCs, located on the same network as the edge device that will be reading its data.
- A running FlowFuse instance on your edge device. If you do not have an account, [sign up for a free trial](https://flowfuse.com/blog/2025/09/installing-node-red/) and set up your instance following the instructions in this article.

# Getting Started

Now, let's get started. First, watch this demo, where I have built a FlowFuse flow that collects data from four sources: Siemens S7 and Allen-Bradley PLCs, an OPC UA server, and a Modbus simulator.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: vptAoDR78Cc
---
::

This flow standardizes data from each protocol into a consistent JSON format, enriches it with contextual metadata, and publishes everything to the FlowFuse MQTT Broker, all within a single instance. The following guide explains how to replicate this setup for any PLC on your factory floor.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

## Step 1: Extract Data from Your PLC

As mentioned earlier, extracting data is the first and most complex step. Get this wrong, and the complexity and costs can spiral out of control. FlowFuse simplifies this process. Its pre-built connectors handle Modbus, OPC UA, EtherNet/IP, and other protocols right out of the box, no custom coding, expensive proprietary gateways, or per-tag licensing fees required. You can configure your connections visually and have data flowing within minutes.

This is not just theory, Fortune 500 manufacturers are already running production systems on FlowFuse. Their consistent feedback? Massive cost savings compared to legacy systems, especially when deployed across multiple facilities. The enterprise features of FlowFuse handle the scale and security requirements large operations demand.

The Node-RED ecosystem that powers FlowFuse offers comprehensive protocol support. You'll find nodes available for every major PLC manufacturer, including:

- `node-red-contrib-modbus` – Modbus RTU/TCP PLCs and devices
- `node-red-contrib-s7` – Siemens S7-300/400/1200/1500
- `node-red-contrib-opcua` – OPC UA servers
- `node-red-contrib-cip-ethernet-ip` – Allen-Bradley PLCs
- `node-red-contrib-mcprotocol` – Mitsubishi PLCs
- `node-red-contrib-omron-fins` – Omron PLCs
- and many more

Adding a protocol node to your FlowFuse instance takes just a few clicks. Open the palette manager from the hamburger menu, select **Manage palette**, go to the **Install** tab, and search for the node you need.

## Convincing the IT Team

When talking to people in the IIoT community, one recurring challenge always comes up, **convincing the IT team**.

Traditional industrial gateways require inbound connections from the cloud. This means opening specific ports in your firewall, creating security exceptions, and giving external systems a pathway into your production network. IT security teams push back on this, and rightly so. Inbound connections expand your attack surface and violate the principle of defense in depth.

FlowFuse solves this with an **edge-first architecture**. The Device Agent installs directly on hardware inside your factory network, a Raspberry Pi, an industrial PC, or even directly on supported PLCs. Once running, the agent initiates **outbound** connections to the FlowFuse platform using standard web protocols (HTTPS and WebSocket over port 443). All communication flows through this outbound connection. The platform never initiates connections back to your network.

From a security standpoint, this changes everything. Your firewall configuration does not change. :br
No new inbound rules. No DMZ setup. No VPN tunnels to maintain.

The device agent behaves like any other business application making secure outbound HTTPS requests, something your network already allows.

For networks with proxy servers, the agent supports standard proxy configurations through environment variables. For air-gapped networks, you can pre-cache Node-RED modules and deploy without internet connectivity after the initial setup.

## Step 2: Transform and Structure Your Data

Now let's move to the next step. Raw PLC data needs reshaping before cloud transmission. Register values, bit arrays, floating points, and timestamps arrive in different formats. FlowFuse offers several transformation methods suitable for different skill levels.

**Visual Transformation with Change Nodes and JSONata**

Change nodes handle simple transformations without coding. They allow you to map fields, modify values, convert units, and add metadata using dropdowns and form fields. JSONata allows more advanced data manipulation directly within the Change node.

Plant engineers can work directly with these visual tools, no programming required.

For example, suppose you are receiving a pressure sensor value as `msg.payload` but it lacks context.

You can use a **Change** node to:

- Add contextual information such as the machine ID, facility, or sensor location, unit

![Change node adding context to data](https://flowfuse.com/blog/2025/10/images/change-node-adding-context.png){dataZoomable=""}*Change node used to convert temperature and add machine context*

**Function Nodes for Custom Logic**

Function nodes provide full JavaScript access for complex requirements. Write custom logic, install npm packages, and access the complete JavaScript standard library when Change nodes and JSONata reach their limits.

*Tip: Use the [FlowFuse Expert](https://flowfuse.com/blog/2025/07/flowfuse-ai-assistant-better-node-red-manufacturing/) to generate function nodes. Describe the transformation you need in plain English, and it will create the code for you. For best results, provide sample input data to ensure the output matches your requirements.*

**Pre-built Community Nodes**

Before building custom solutions, check the palette manager. The Node-RED ecosystem includes thousands of nodes for data aggregation, statistical analysis, time-series buffering, and unit conversions. Many common transformation tasks already have ready-made solutions.

For example, a popular node I'm using in my demo for parsing and transforming data is `node-red-contrib-buffer-parser`. This node is especially useful when working with Modbus or PLC outputs, as it converts raw data into structured formats that can be easily processed further.

## Step 3: Set Up MQTT with FlowFuse

Most MQTT implementations require setting up a separate broker either paying for a managed service or hosting your own. FlowFuse includes a managed MQTT broker built directly into the platform, eliminating this extra step.

Traditional PLC-to-cloud setups typically involve several moving parts: edge gateways running protocol drivers, a separate MQTT broker (cloud-hosted or self-managed), and your destination cloud services. Each layer adds configuration work, licensing costs, and potential failure points. When data stops flowing, you end up troubleshooting across multiple systems to locate the issue.

FlowFuse consolidates those layers into a single integrated platform. It provides enterprise-grade features for management, scaling, deployment, and security, all handled by the FlowFuse infrastructure. You retain full control over configuration settings through a clean, intuitive interface, without needing to maintain multiple external systems.

To use the FlowFuse MQTT broker, you'll need a FlowFuse Pro or higher-tier account. Once on the Pro plan, you can enable the managed MQTT service by navigating to the Broker section from the left sidebar and selecting FlowFuse Broker.

![Enabling FlowFuse MQTT Broker](https://flowfuse.com/blog/2025/10/images/set-broker.png){dataZoomable=""}*Enabling FlowFuse MQTT Broker*

**Configure Publishing**

1. Drag a **FlowFuse MQTT Out** node onto your canvas.
2. Open the node configuration. It will automatically pick up its configuration.
3. Set the topic following ISA-95 hierarchy:

```text
company/site/area/line/cell/device/measurement
```

For Example:

```text
acme/plant-a/assembly/line1/press-1/pressure01/bar
```

**Why ISA-95 for MQTT Topics**

The ISA-95 Equipment Hierarchy Model is an international standard that defines how to organize manufacturing operations into logical layers. When you structure MQTT topics using this model, you're building toward a Unified Namespace (UNS), a single, consistent way to organize all operational data across your entire organization.

The goal of UNS is to eliminate data silos. Instead of each system maintaining its own proprietary structure, everything publishes to one shared namespace using a common hierarchy. Applications subscribe to exactly the data they need without knowing where it physically comes from or how it was collected.

ISA-95 makes this possible because it maps to how factories actually operate. `company/site/area/line/cell` matches your organizational structure. When you expand to new facilities or add equipment, the hierarchy extends naturally. Analytics tools can compare performance across sites. MES systems subscribe to production line data. Dashboards pull from specific cells. Everything uses the same addressing scheme.

This enables powerful wildcard subscriptions:

- `acme/#` - all company data
- `acme/chicago/#` - single site
- `+/+/assembly/#` - assembly operations everywhere
- `acme/chicago/assembly/line2/#` - one production line

*Note: Use lowercase with hyphens for multi-word names.*

4. Set **QoS** to **1**.
5. Click **Deploy**.

After deploying the flow, the MQTT client for your device will be automatically created. To configure access:

6. Double-click the MQTT Out node.
7. Click **Configure Access Control**. You will be redirected to the platform's broker client management section, filtered to show the client created for this instance.

![Configure MQTT Client Access Control](https://flowfuse.com/blog/2025/10/images/configure-access-control.png){dataZoomable=""}*Configure MQTT Client Access Control*

8. Click the client **edit**, select **Publish**, and then click **Confirm**.

![Configuring Client Access Control](https://flowfuse.com/blog/2025/10/images/client-access-control.jpg){dataZoomable=""}*Configure MQTT Client Access Control*

That's it. You now have PLC data flowing to MQTT with proper access controls configured and a topic structure that scales with your organization. To view the topic hierarchy and the schema for your topics, go to the FlowFuse Broker section. Here, you'll see all the topics within your MQTT broker. By clicking **Open Schema**, you can view the auto-generated schema document created by FlowFuse.

![FlowFuse Topic Hierarchy View](https://flowfuse.com/blog/2025/10/images/mqtt-topic-hierarchy.png){dataZoomable=""}*FlowFuse Topic Hierarchy View*

![Topic schema auto-generated by FlowFuse](https://flowfuse.com/blog/2025/10/images/mqtt-topic-schema-document.png){dataZoomable=""}*Topic schema auto-generated by FlowFuse*

## Bridging the Expertise Gap and Cutting Costs

Now let's talk about the remaining problems: the expertise gap and cost. FlowFuse solves both by changing how the work gets done.

Plant engineers configure PLC connections, transform data, contextualize it, and send it to MQTT through drag-and-drop interfaces without writing code, that's what you saw in the steps above. IT teams manage security and access controls through standard web tools. Neither needs expertise in the other's domain.

The FlowFuse Expert fills remaining gaps, describe what you need in plain English, and it generates function nodes, database queries, or dashboard components. Click "Explain" on any flow to get instant documentation.

This eliminates the consultant dependency that inflates project costs. Your team handles implementation and maintenance without external help at [[]{.katex-mathml}[[[]{.strut style="height:0.7278em;vertical-align:-0.0833em;"}[150]{.mord}[−]{.mord}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 250 per hour, saving [[]{.katex-mathml}[[[]{.strut style="height:0.8389em;vertical-align:-0.1944em;"}[12]{.mord}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[000]{.mord}[t]{.mord.mathnormal}[o]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 30,000 on setup alone. The managed MQTT broker includes unlimited messaging with no per-message fees. Protocol drivers are free and open-source with no per-tag licensing. Deploy on existing industrial hardware instead of buying $10,000 proprietary gateways.

Manufacturers typically see substantial cost reduction in the first year, with improving economics as you scale since hardware and licensing costs stay eliminated. Most engineers ship production flows in their first session.

## Get Started

Connect your first PLC today. [Sign up for FlowFuse](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"}, install the Device Agent on your edge hardware, and have data flowing to MQTT in under an hour. The platform handles the complexity, you focus on turning factory data into insights.

MQTT is one of several ways FlowFuse connects PLCs to the modern industrial stack. For a full view of supported protocols, OPC UA, EtherNet/IP, Siemens S7, Modbus, and more, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).


# Beyond Cloud AI Orchestration: Why the Future is Hybrid Edge-Cloud Intelligence

Congratulations to n8n on their [Series C funding round](https://blog.n8n.io/series-c/){rel="&#x22;nofollow&#x22;"}! This is a fantastic milestone and a clear signal that the market has moved beyond AI experimentation and into the serious business of production deployment. Platforms like n8n are mastering what we call centralized orchestration: creating cloud-native "brains" that connect digital services, APIs, and data sources to execute complex workflows. This approach excels for digital-first applications and represents a crucial evolution in workflow automation.

But for industrial applications, we need to think beyond traditional cloud orchestration.

The tech world is buzzing with talk of AI agents and orchestration platforms, and the energy around n8n's recent funding is proof of this momentum. This energy is a fantastic sign of a maturing market, proving that we've moved beyond AI experimentation and into the serious business of production deployment.

Cloud orchestration platforms excel at what they're designed for: connecting digital services, managing API workflows, and orchestrating cloud-native applications. However, for the industries that power our physical world, manufacturing, logistics, energy, and infrastructure, we need complementary approaches that address the unique requirements of operational technology. This is where hybrid edge-cloud architectures become essential.

## Industrial Requirements: Where Cloud-Only Solutions Face Challenges

When operations involve real-world assets like factory machinery, remote sensors, or logistics fleets, purely centralized approaches encounter specific industrial constraints. For applications where milliseconds matter, such as emergency shutdowns or quality control decisions, the latency of cloud round-trips can be too slow for critical responses. Connectivity challenges in industrial environments, from remote oil platforms to underground mining operations, require systems that can operate intelligently even when cloud connections are intermittent.

Additionally, the economics of data movement become significant at industrial scale. Streaming continuous data from thousands of sensors to the cloud for processing can be costly and inefficient, especially when much of that processing could happen locally. Many industries also have regulatory requirements that mandate certain operational data remain on-premise for compliance and security reasons.

These constraints don't invalidate cloud orchestration, they highlight the need for hybrid approaches that leverage both cloud capabilities and edge intelligence where each excels.

## The Next Paradigm: Hybrid Edge-Cloud Intelligence

The future of industrial AI isn't choosing between cloud or edge, it's intelligently combining both. Rather than replacing cloud orchestration, the industrial world needs a hybrid architecture: a distributed nervous system where cloud orchestration handles high-level coordination and data aggregation, while edge intelligence manages real-time operations and local decision-making.

In this paradigm, AI operates at multiple levels. Edge devices handle immediate responses, predictive maintenance alerts, quality control decisions, and safety shutdowns, without waiting for cloud communication. Meanwhile, cloud orchestration excels at what it does best: aggregating data from multiple sites, running complex analytics, coordinating across systems, and managing enterprise-wide workflows. This creates a complementary relationship where each layer operates within its strengths.

## FlowFuse: Bridging Edge and Cloud Intelligence

While the market builds excellent tools for cloud-based AI orchestration, FlowFuse specializes in the hybrid approach that industrial applications demand. Built on the proven foundation of Node-RED, our platform provides engineers with a unified control tower to manage both cloud orchestration and edge intelligence at scale.

FlowFuse Cloud enables centralized management and coordination, while our edge capabilities allow thousands of Node-RED instances to operate intelligently at remote locations. This hybrid architecture lets you seamlessly integrate the physical and digital worlds, leveraging cloud orchestration for enterprise workflows while maintaining real-time edge intelligence where it matters most.

Our FlowFuse Expert simplifies the creation and management of complex logic across both cloud and edge environments, democratizing advanced automation without requiring specialized data science skills. Soon, with our upcoming AI Agent nodes, FlowFuse will enable powerful AI agents to operate seamlessly across the entire hybrid architecture, from cloud coordination to edge execution.

## Conclusion: The Power of Hybrid Intelligence

The rise of AI orchestration platforms represents an important evolution in automation technology. These tools excel in their domain and will continue to play a crucial role in digital transformation initiatives.

For industrial applications, the future lies in hybrid architectures that combine the strengths of both approaches. Cloud orchestration provides the coordination, analytics, and enterprise integration capabilities that modern businesses require, while edge intelligence delivers the real-time responsiveness and resilience that industrial operations demand.

Choosing the right approach comes down to understanding your requirements. For digital-first applications, cloud orchestration platforms offer powerful solutions. For industrial and IoT applications that bridge physical and digital worlds, hybrid edge-cloud architectures provide the comprehensive intelligence needed to succeed.

## Ready to Build the Future of Industrial AI?

FlowFuse is built for the challenges of industrial and IoT data. Whether you're implementing Industry 4.0 initiatives or building predictive maintenance systems, we provide the platform to deploy and manage intelligence across both cloud and edge environments.

[Start building today: Try FlowFuse free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} or [Book a demo](https://flowfuse.com/book-demo/)


# EtherNet/IP Integration with FlowFuse: Communicating with Allen-Bradley PLCs

EtherNet/IP is one of the most widely used industrial communication protocols for connecting PLCs, sensors, and controllers across manufacturing environments. If you're working with Allen-Bradley PLCs, whether it's ControlLogix, CompactLogix, or MicroLogix, you're using some of the most trusted automation hardware in the industry.

This guide will show you how to integrate Allen-Bradley PLCs with FlowFuse using EtherNet/IP. While the focus is on Allen-Bradley, the same Node-RED nodes and techniques also work with other EtherNet/IP-compatible PLCs, such as Omron and Automation Direct. You will learn both connected and unconnected messaging modes, so you can choose the approach that fits your setup. By the end of this guide, your PLCs will be communicating with FlowFuse (Node-RED with enterprise capabilities), enabling you to build powerful industrial automation workflows.

## Prerequisites

Before integrating your Allen-Bradley PLC with FlowFuse, ensure you have the following:

**PLC Configuration:**

- Your Allen-Bradley PLC (ControlLogix, CompactLogix, or MicroLogix) should be properly configured and operational.
- Ensure that the appropriate ladder logic program is written according to your requirements and successfully downloaded to the PLC.
- Verify that the controller tags or data structures you want to access are properly defined.
- Note the PLC's IP address and slot number (typically slot 0 for the processor).

**Node-RED:**

- Install Node-RED on the device that will communicate with the Allen-Bradley PLC. You cannot install Node-RED directly on the PLC, as PLCs are controllers, not computers. You can use devices like the Raspberry Pi, Revolution Pi, or industrial PCs to connect and transfer data across systems.
- Use the [FlowFuse Device Agent](https://flowfuse.com/platform/device-agent/) to install Node-RED on your edge device.

> **Why FlowFuse Device Agent?** FlowFuse provides Node-RED with enterprise capabilities like remote management, team collaboration, device management, and DevOps pipelines, essential features for scaling industrial automation across your organization. These capabilities help streamline operations and ensure reliability in complex manufacturing environments. [Sign up for free](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"} to get started.

**Network Setup:**

- Verify that the device running Node-RED is on the same network as the PLC and can successfully ping the PLC's IP address.
- Ensure the PLC is properly connected to the network via Ethernet with a static IP address configured.
- Ensure that firewalls do not block EtherNet/IP communication (typically port 44818 for both TCP and UDP).

## Understanding EtherNet/IP Communication Modes

EtherNet/IP is an industrial network protocol widely used to communicate with Allen-Bradley and other PLCs over Ethernet. It allows devices to exchange data efficiently and reliably, making it a common choice for industrial automation systems.

EtherNet/IP supports two primary communication modes: **connected** and **unconnected** messaging. Your choice depends on how frequently you need to communicate with the PLC, the number of available connection resources, and, most importantly, what your PLC actually supports. Not all PLCs support both modes. For example, Allen-Bradley Micro800 series PLCs only support connected messaging, while ControlLogix and CompactLogix typically support both.

### Connected Messaging

Connected messaging establishes a persistent session between Node-RED and the PLC using the Forward Open protocol. Once connected, data flows continuously with minimal overhead, making it ideal for real-time monitoring and high-frequency updates. The advantage is speed, after the initial handshake, communication is fast and efficient. The tradeoff is that each session consumes one of the PLC's limited connection slots, typically ranging from 8 to 32 depending on the model.

Connected messaging itself can operate in two ways:

**Without Routing (Direct Connection):**
Used for PLCs that connect directly via Ethernet without backplane routing, such as the Allen-Bradley Micro800/850/870 series. Only the IP address is needed, no slot number or routing path is required.

**With Routing:**
Used for chassis-based PLCs like ControlLogix and CompactLogix, where the processor sits in a backplane slot. In this case, the slot number must be specified, as it automatically creates a routing path through the backplane to reach the processor.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

### Unconnected Messaging

Unconnected messaging sends individual requests without maintaining a persistent connection. Each transaction is standalone, request, response, done.

This approach doesn't consume connection slots, making it ideal when resources are limited or when multiple systems need occasional PLC access. The downside is higher overhead per message, resulting in slower performance compared to connected mode.

In practice, use connected mode for frequent polling and unconnected mode for occasional reads or writes, but always check your PLC's documentation to confirm which modes are supported.

## Installing the EtherNet/IP Node

To communicate with Allen-Bradley PLCs from FlowFuse, use the popular node-red-contrib-cip-ethernet-ip node, which supports both connected and unconnected messaging modes.

1. Open your FlowFuse Instance Node-RED editor in a web browser.
2. Click the main menu (three horizontal lines) in the top-right corner.
3. Select "Manage Palette" from the menu.
4. Switch to the "Install" tab and search for `node-red-contrib-cip-ethernet-ip`.
5. Click "Install" next to the node name.
6. Wait for the installation to complete.

Once installed, you'll find the EtherNet/IP nodes in your palette under the "plc" category. The main nodes are `ethernet-ip in` for reading data and `ethernet-ip out` for writing data to the PLC.

## Configuring the EtherNet/IP Node

Now that you have installed the EtherNet/IP node, it is time to configure the connection to your Allen-Bradley PLC.

1. Drag any EtherNet/IP node onto the canvas.
2. Double-click the node to open its configuration panel.
3. Click the "+" icon next to the &#x2A;*"PLC"** dropdown to add a new PLC configuration.
4. Enter the basic connection details:
   - Give your connection a descriptive name, such as &#x2A;*"Line 1 PLC"**, for easy identification.
   - Enter your PLC’s **IP address**.
   - Specify the **slot number** where your processor is located.
5. Configure the communication parameters:
   - **Cycle time** controls how often the node communicates with the PLC (for example, 500 ms means it updates twice per second).
6. Select the communication mode:
   - **Standard (Unconnected)**: This is the default option supported by most PLCs.
   - **Connected (With Routing)**: Use this option if you want to enable connected messaging with routing.

![EtherNet/IP Node Configuration](https://flowfuse.com/blog/2025/10/images/eth-ip-config.png){dataZoomable=""}*EtherNet/IP Node Configuration*

This node does not currently support connected messaging (without routing). I have developed node, `@sumit_shinde_84/node-red-contrib-cip-ethernet-ip-enhanced`, which supports connected messaging (without routing) but is still under development.

If you need connected messaging without routing, you can use that node. To enable connected messaging without routing, select Connected (no routing) from the communication mode dropdown in the configuration dialog.

### Adding Tags to Read or Write

After configuring the endpoint, you need to specify which tags you want to read from or write to the PLC.

1. In the same configuration window, switch to the "Tags" tab.
2. Click the "+Add" button in the top-right corner to add a new tag.
3. Enter the tag details:
   - **Name**: Enter the exact tag name as it appears in your PLC program (e.g., "Motor1Speed" or "Program\:MainProgram.Motor1Speed")
   - **Type**: Select the data type from the dropdown (e.g., BOOL, INT, DINT, REAL, etc.)
4. Repeat this process for each tag you want to monitor or control. You can add multiple tags that will all use the same PLC connection you configured earlier.

:video{ariaLabel="Adding tags to read and write" autoPlay="true" height="628" loop="true" muted="true" playsInline="true" preload="none" width="800"}*Adding tags to read and write*

If your tag belongs to a different scope, click the “+ Add” button at the top to create a new scope. Then, within that scope, add the tags in the same manner.

5. Once you've added all your tags, click "Add" to save the configuration, then "Done".
6. Finally, deploy the flow by clicking the "Deploy" button in the top-right corner.

**Important:** Tag names must match exactly as they appear in your PLC program, they are case-sensitive. Make sure to select the correct data type for each tag to ensure proper communication.

## Getting Started

Before we start, I'd like to show you what I've prepared, a flow where I'm sending commands to the PLC to control the stack light. To interact with it, I've built a nice dashboard using [FlowFuse Dashboard](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"}. Here's a quick demonstration:

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: 6X9HXJLKPyo
---
::

That’s the program I have downloaded to the PLC

![Program downloaded to the PLC](https://flowfuse.com/blog/2025/10/images/plc-program.png){dataZoomable=""}*Program downloaded to the PLC*

Now let’s learn how to build a flow that can both read and write data to your PLC.

### Writing Data to Your PLC

Writing to a PLC is where things get exciting, this is where you move from monitoring to actually controlling your equipment. Maybe you want to start a motor, adjust a setpoint, or trigger a sequence. Whatever your goal, the process is straightforward.

1. Drag an &#x2A;*`ethernet-ip out`** node onto the canvas.
2. Double-click the node to open its configuration.
3. Select the PLC configuration you created earlier from the dropdown.
4. Select the scope under which you added the tag, choose the tag that you want to write to.

![Configuring the EtherNet/IP out node to write data to a PLC tag](https://flowfuse.com/blog/2025/10/images/eth-out-node.png){dataZoomable=""}*Configuring the EtherNet/IP out node to write data to a PLC tag*

5. Click "Done".
6. Connect an &#x2A;*`inject`** node or any other input node to send data.
7. Deploy the flow and click inject button to test it.

The node expects the incoming message payload to contain the value you want to write to the tag. Ensure that the value type matches the data type you configured when adding the tag and what the PLC expects.

### Reading Single Tag from Your PLC

Reading data from your PLC is the foundation of any monitoring or control system. Whether you're tracking production counts, monitoring temperatures, or checking machine status, you'll start here.

Here's how to set it up:

1. Drag an &#x2A;*`ethernet-ip in`** node onto the canvas.
2. Double-click the node to open its configuration.
3. Select the PLC configuration you created earlier from the dropdown.
4. Select the scope under which you added the tag, select the mode to "Single Tag" and choose the tag that you want to read.

![Configuring the EtherNet/IP in node to read a single tag from the PLC](https://flowfuse.com/blog/2025/10/images/read-plc-tag.png){dataZoomable=""}*Configuring the EtherNet/IP in node to read a single tag from the PLC*

5. Click "Done".
6. Connect a &#x2A;*`debug`** node to view the data.
7. Deploy the flow.

The node will automatically read data based on your configured cycle time and output it.

*Note: Reading single tags individually isn't recommended for production use as it creates unnecessary network overhead. Consider using "All tags" mode or structuring your PLC with array data types to read multiple values efficiently in one request.*

### Reading Multiple Tags from Your PLC

Sometimes you need the full picture, not just one data point, but everything that matters for your process. Reading multiple tags at once gives you a complete snapshot of your system in a single message.

Let me show you how:

1. Drag an &#x2A;*`ethernet-ip in`** node onto the canvas.
2. Double-click the node to open its configuration.
3. Select the PLC configuration you created earlier from the dropdown.
4. In the **Mode*&#x2A; field, select &#x2A;*"All tags"*&#x2A; to read all configured tags together in a single message, or select &#x2A;*"All tags (one per msg)"** if you want each tag value sent as a separate message.

![Reading all tags with each tag sent as a separate message](https://flowfuse.com/blog/2025/10/images/all-tags-one-msg-per-tag.png){dataZoomable=""}*Reading all tags with each tag sent as a separate message*

![Reading all tags together in a single message object](https://flowfuse.com/blog/2025/10/images/all-tags-single-obj.png){dataZoomable=""}*Reading all tags together in a single message object*

5. Click "Done".
6. Connect a &#x2A;*`debug`** node to view the data.
7. Deploy the flow.

The node will automatically read all configured tags based on your cycle time, giving you full visibility into your PLC data.

## Next Steps

Now that you've learned how to read and write data with your Allen-Bradley PLC, you can build interactive dashboards to monitor and control your industrial processes. FlowFuse Dashboard makes it easy to create professional interfaces with buttons, gauges, charts, and controls, all without writing complex code.

Check out our [Getting Started with Dashboard guide](https://flowfuse.com/blog/2024/03/dashboard-getting-started/) to learn how to build your first dashboard.

### Beyond Allen-Bradley

FlowFuse isn't limited to EtherNet/IP. Connect Siemens PLCs via S7, use OPC UA for vendor-neutral communication, integrate Modbus devices, or connect IoT sensors with MQTT. Mix protocols as needed, your factory floor probably isn't single-vendor anyway. For a full view of every supported PLC brand and protocol, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).

[Book a demo](https://flowfuse.com/book-demo/) to see how FlowFuse connects your entire operation.


# Building a Web HMI for Factory Equipment Control

Most factory HMIs are still stuck in one place. Dedicated panels mounted next to equipment, or SCADA workstations in the control room. Need to check something? You're walking over there.

Web-based HMIs change that. Build your interface once in FlowFuse, and it runs anywhere, desktop, tablet, phone. Your operators can monitor and control equipment from wherever they need to be.

This tutorial walks you through building a simple motor control interface: two buttons and a status display. You will learn how to connect to PLCs, build HMI dashboards, and enable remote access. From there, you can scale up to production lines with multiple sensors and actuators, live charts, gauges, sliders, and interactive controls.

Here's what you'll build:

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: NQZ_u25sy1Q
---
::

## Prerequisites

Before beginning, ensure you have:

- **Edge device** - A computer, Raspberry Pi, or industrial PC that connects to your PLC and runs FlowFuse
- **PLC on the same network** - Your PLC must be networked with your edge device
- **Equipment to control** (optional but recommended) - Having a motor or other equipment connected to your PLC helps you follow along and see real results as you build the HMI

## Understanding the Setup

Your PLC already controls your equipment. It reads sensors, executes logic, and switches outputs. That doesn't change.

FlowFuse sits between operators and the PLC. It runs on an edge device connected to the same network as your PLC. FlowFuse communicates with the PLC using Modbus, OPC UA, EtherNet/IP, S7, or whatever protocol your PLC speaks.

Inside FlowFuse, nodes handle the PLC communication and data transformation while dashboard nodes let you build the HMI. These nodes create buttons, gauges, charts, and status displays. FlowFuse serves this interface as a webpage that any browser can access.

When an operator clicks a button, FlowFuse writes the command to the PLC. When the PLC updates its output, FlowFuse reads it and pushes the new value to the dashboard. The browser updates automatically.

## HMI Design Principles Worth Knowing

Before diving into the build, it's helpful to understand what makes industrial HMIs effective. Our tutorial keeps things simple, but these principles are worth knowing as you get more comfortable with FlowFuse and expand your system.

Good HMIs let operators quickly assess what's happening at a glance. Status should be immediately obvious: what is running, what is stopped, what needs attention. Color coding helps with this: green for running, red for stopped, yellow for warnings. Following standards like [ISA-101](https://www.isa.org/standards-and-publications/isa-standards/isa-101-standards){rel="&#x22;nofollow&#x22;"} ensures your color choices are consistent with what operators expect across different systems. We'll use this approach in our motor control example.

Your PLC handles real-time control, your HMI just reflects what's happening. Polling intervals between 500-1000ms work well for most applications. Faster polling doesn't improve control, it just increases network traffic. Status indicators should be large and clear, with critical information immediately visible and text readable from a reasonable distance.

If operators will use tablets, design for touch targets (minimum 44x44 pixels) and avoid interactions that depend on hovering. Test on actual devices your team will use. Most importantly, always show operators when the HMI is disconnected from the PLC. This is critical for safety, operators need to know immediately if their commands aren't reaching the equipment. Display connection status prominently, and consider disabling controls when disconnected.

## Step 1: Set Up FlowFuse

You need the FlowFuse agent running on an edge device that can reach your PLC over the network.

Start by creating a [FlowFuse account](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}. Once logged in, install and register the FlowFuse agent on your edge device by following this guide: [Installing Node-RED on Your Edge Device](https://flowfuse.com/blog/2025/09/installing-node-red/)

## Step 2: Connect to Your PLC

Your HMI needs to talk to your PLC to read equipment status and send control commands. FlowFuse handles this through Node-RED's protocol nodes, which support every major industrial controller. No proprietary gateways, no per-tag licensing, no vendor lock-in, just direct communication with your PLC.

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

Choose the node that matches your PLC:

- **[node-red-contrib-modbus](https://flowfuse.com/node-red/protocol/modbus/)** – Modbus RTU/TCP PLCs and devices
- **[node-red-contrib-s7](https://flowfuse.com/blog/2025/01/integrating-siemens-s7-plcs-with-node-red-guide/)** – Siemens S7-300/400/1200/1500
- **[node-red-contrib-opcua](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/)** – OPC UA servers (universal industrial standard)
- **[node-red-contrib-cip-ethernet-ip](https://flowfuse.com/blog/2025/10/using-ethernet-ip-with-flowfuse/)** – Allen-Bradley/Rockwell PLCs
- **[node-red-contrib-mcprotocol](https://flows.nodered.org/node/node-red-contrib-mcprotocol){rel="&#x22;nofollow&#x22;"}** – Mitsubishi PLCs
- **[node-red-contrib-omron-fins](https://flows.nodered.org/node/node-red-contrib-omron-fins){rel="&#x22;nofollow&#x22;"}** – Omron PLCs
- **[node-red-contrib-bacnet](https://flows.nodered.org/node/node-red-contrib-bacnet){rel="&#x22;nofollow&#x22;"}** – BACnet building automation devices

**Installing Protocol Nodes:**

1. Click the hamburger menu (top right) → **Manage palette**.
2. Go to the **Install** tab.
3. Search for your protocol node (e.g., `node-red-contrib-s7` for Siemens).
4. Click **Install**.

**Configuring Your Connection**

After installation, drag the protocol node onto your canvas. You’ll need two types of nodes: one for reading equipment status and one for sending commands.

Start with an input node for reading status (motor running, faults, sensor values). Use **S7 In** for Siemens, **Modbus Read** for Modbus devices, or **OPC UA Client** for OPC UA servers, etc. Open the node configuration and click the pencil icon next to the **Server/Connection** dropdown to create a new connection configuration. Here, enter the connection details for your PLC or server, such as IP address, port, credentials, and polling interval. The exact parameters vary by protocol; if you need help understanding what to configure, refer to the documentation links in the protocol node list above. Each link includes detailed setup guidance.

After saving the connection configuration, specify the **variable addresses that provide the status information*&#x2A; you want to read (tags/registers such as motor state, faults, and sensor values). If available, enable efficiency features like &#x2A;*“emit only on change”*&#x2A; or &#x2A;*“subscribe mode”** to minimize unnecessary updates.

For sending commands (start motor, stop motor, setpoints), drag the corresponding output node onto your canvas. When configuring it, select the **same Server/Connection** from the dropdown instead of creating a new one. This shared connection approach means the IP address, port, and credentials only need to be configured once and can be reused across all your PLC/server nodes. You then only need to specify the variable addresses that control your equipment, and connect those nodes to your dashboard buttons or automation logic.

**Important Note:** Some PLCs require configuration in their engineering software before allowing external access. For example, Siemens S7 requires **PUT/GET communication** enabled in TIA Portal, and Allen-Bradley controllers may need **explicit messaging** enabled in Studio 5000. Refer to your PLC’s documentation for any communication prerequisites.

**Test Your Connection:**

1. Add a **Debug** node and connect it to your input node.
2. Click **Deploy**.
3. Check for a green "connected" or "online" status indicator on your protocol node.
4. Open the debug panel to verify data is flowing from your PLC.

Once you see live values in the debug panel, your PLC connection is working and you're ready to build the operator interface.

## Step 3: Build Your HMI Dashboard

With your PLC connected, let's create the operator interface using FlowFuse Dashboard, a set of UI nodes that build web-based interfaces without writing HTML or JavaScript.

### Install Dashboard 2.0

1. Click the hamburger menu and select **Manage palette**.
2. Go to the **Install** tab.
3. Search for `@flowfuse/node-red-dashboard`.
4. Click **Install**.

### Create Your Motor Control Interface

**Add Control Buttons:**

1. Drag a **ui-button** widget onto your canvas.
2. Double-click to open its configuration.
3. Click the pencil icon next to "Group" to create a new group name, example, "Motor Controls" or another name that fits your equipment.
4. Click the pencil icon next to "Page" to create a new page like "Line 1", for example, "Line 1" or the area of your process this interface belongs to.
5. Configure the button:
   - **Label**: "Start"
   - **Payload**: `true` (boolean)
   - **Background**: `#28A745`

![Button node configuration showing Start label, true payload, and green background color](https://flowfuse.com/blog/2025/11/images/start-button.png){dataZoomable=""}*Start button node configuration*

6. Click Done.
7. Connect this node to your PLC write node.
8. Repeat to add a "Stop" button with payload `false` and `#DC3545` background.

![Button node configuration showing Stop label, false payload, and red background color](https://flowfuse.com/blog/2025/11/images/stop-button.png){dataZoomable=""}*Stop button node configuration*

### Add Status Display

The PLC continuously reports whether the motor is running or stopped as a boolean value. We'll convert these values into readable text with color-coded styling.

**Convert Boolean Values to Readable Status:**

1. Drag a **switch** node onto the canvas and connect it to your PLC read node.
2. Add two conditions: `is true` and `is false` to check `msg.payload`.

![Switch node configuration showing conditions for true and false values](https://flowfuse.com/blog/2025/11/images/switch-node.png){dataZoomable=""}*Switch node configuration for motor status*

3. Drag two **change**nodes onto the canvas:
   - Connect the first to the "true" output: set `msg.payload` to "RUNNING" and `msg.class` to "running"
   - Connect the second to the "false" output: set `msg.payload` to "STOPPED" and `msg.class` to "stopped"

![Change node configuration setting payload to RUNNING and class to running](https://flowfuse.com/blog/2025/11/images/change-node-running.png){dataZoomable=""}*Change node configuration for running status*

![Change node configuration setting payload to STOPPED and class to stopped](https://flowfuse.com/blog/2025/11/images/change-node-stopped.png){dataZoomable=""}*Change node configuration for stopped status*

**Create the Status Display:**

1. Drag a **ui-text** widget onto your canvas.
2. Double-click to configure:
   - **Group**: Select "Motor Controls" (or create a "Status" group).
   - **Label**: Leave empty or enter "Motor Status:"
   - **Value Format**: `msg.payload`.
3. Click Done.
4. Connect both change nodes to the ui-text widget.

![UI text widget configuration for displaying motor status](https://flowfuse.com/blog/2025/11/images/motor-status-text-widget.png){dataZoomable=""}*Motor status text widget configuration*

**Add Status Styling:**

1. Drag a **ui-template** widget onto the canvas.
2. Configure:
   - **Type**: Select "CSS (All Pages)" or "CSS (Single Page)".
   - Add this CSS:

```css
.running {
    color: lightgreen !important;
    font-size: 60px !important;
    font-weight: bold;
}
.stopped {
    color: red !important;
    font-size: 60px !important;
    font-weight: bold;
}
```

![UI template node with CSS styling for running and stopped status classes](https://flowfuse.com/blog/2025/11/images/css.png){dataZoomable=""}*CSS template for status display styling*

3. Click **Done** and deploy the flow

You've just built a basic motor control interface. FlowFuse Dashboard includes gauges, charts, sliders, and other widgets that work the same way, drag, configure, connect. See the [widget reference](https://dashboard.flowfuse.com/nodes/widgets.html){rel="&#x22;nofollow&#x22;"} for the full list.

### Accessing Your Dashboard

**Local Network Access:**

The dashboard in a remote instance isn't accessible by default. To enable it:

1. Go to **Instance Settings** → **Security**.
2. Check &#x2A;*"Allow Offline Access"** and set a username and password.

![Instance security settings showing Allow Offline Access checkbox and authentication fields](https://flowfuse.com/blog/2025/11/images/enable-offline-access.png){dataZoomable=""}*Enabling offline access in instance security settings*

3. Click **save settings**, then restart the instance using the top-right **action** button dropdown
4. Navigate to `http://[device-IP]:1880/dashboard` in your browser.

![Web browser displaying the completed motor control HMI with start/stop buttons and status display](https://flowfuse.com/blog/2025/11/images/flowfuse-dashboard-hmi.png){dataZoomable=""}*Completed HMI dashboard running in browser*

> **Note:** While offline access is convenient for testing purposes, it should be avoided in production environments. Running the dashboard locally may bypass secure authentication, potentially exposing sensitive controls and data. For production deployments, we recommend using a FlowFuse-hosted instance, which provides proper security. Setup instructions are available below.

**Remote Access:**

While a local dashboard works for on-site monitoring, it’s not ideal for production. A FlowFuse hosted instance lets you securely monitor and control your equipment from anywhere. Your edge device remains behind your factory network, while the hosted instance subscribes to PLC data via MQTT and displays it on the dashboard.

The architecture is straightforward: your edge device publishes PLC data to MQTT topics, and a hosted FlowFuse instance subscribes to those topics to display the data. When an operator clicks a control button in the hosted dashboard, it publishes a command to MQTT, which your edge device receives and writes to the PLC.

**Enable MQTT in Your Team:**

Before you can use MQTT, you need to [enable the FlowFuse MQTT broker](https://flowfuse.com/blog/2025/10/plc-to-mqtt-using-flowfuse/) for your team, a one-time setup in your FlowFuse team settings that also covers PLC to MQTT integration in depth.

**Configure Your Edge Device:**

On your remote instance (the one connected to your PLC), you'll publish status data and subscribe to commands:

1. Drag an **ff-mqtt-out** node onto the canvas.
2. Double-click to open configuration and click &#x2A;*"Configure access control"**.
3. FlowFuse automatically creates an MQTT client for your instance, enable both **Publish** and **Subscribe** permissions.
4. Set the topic to something descriptive like: `factory/line1/motor/status`
5. Connect this node to your PLC read node (the one that gets motor status).
6. Add an **ff-mqtt-in** node and set its topic to: `factory/line1/motor/command`
7. Connect this node to your PLC write node (the one that controls the motor).
8. Deploy your flow.

Your edge device now shares motor status via MQTT and listens for control commands.

**Build Your Remote Dashboard:**

Create a new [hosted instance](https://flowfuse.com/docs/user/introduction/#creating-a-node-red-instance) in FlowFuse. This instance runs in the cloud and will host your operator dashboard:

1. Install `@flowfuse/node-red-dashboard` using Manage Palette.
2. Build your control interface following the same steps as before, add ui-button widgets for start/stop and ui-text widgets for status display.
3. Add an **ff-mqtt-in** node with topic `factory/line1/motor/status` and connect it to your status display widgets.
4. Add an **ff-mqtt-out** node with topic `factory/line1/motor/command` and connect it to your control buttons.
5. Configure access control for this hosted instance's MQTT client (enable Publish and Subscribe).
6. Deploy.

Your dashboard is now accessible at `https://[your-instance].flowfuse.cloud/dashboard` from any device with internet access. Commands flow from the hosted dashboard through MQTT to your edge device, then to your PLC. Status updates travel the reverse path.

## Next Steps

You now have a working HMI that controls real equipment from any browser. The same approach scales to more equipment, motors, conveyors, pumps, valves, just repeat the connection and dashboard steps.

As your system grows, organize controls across multiple dashboard pages for different production lines or work cells. Add chart widgets to visualize production rates, cycle times, and sensor trends. Configure notification nodes to alert your team via email or Telegram when faults occur.

And if you need to deploy the solution across many production lines, FlowFuse's DevOps features help you manage the scale. Build your HMI once, then deploy it across multiple edge devices and push updates centrally without visiting each location.

For a full view of the PLC brands and protocols FlowFuse supports, Siemens, Allen-Bradley, Omron, OPC UA, Modbus, and more, see [how FlowFuse connects any PLC to the modern industrial stack](https://flowfuse.com/landing/plc/).

[Book a demo](https://flowfuse.com/book-demo/) to see how FlowFuse can help your organization connect, collect, transform, and visualize industrial data with our low-code and AI-powered editor, without the hassle of infrastructure management, deployment complexities, or security concerns at scale.


# Building a Label Scanner with FlowFuse for Product Labels & Serial Numbers

In production environments, labels are everywhere! Products have Serial Numbers and Lot Codes, Packages have Batch IDs and Dates. These are often critical to the processes for packaging, tracking, logging, inventory and so on.

Many companies still do this manually. Someone types in each code as products move through the line. It's repetitive, time-consuming work - mistakes are inevitable.

That's where OCR comes in. Optical Character Recognition (OCR) uses cameras to automatically read and extract text from labels and product markings. Instead of manual data entry, a camera simply captures the image and the system pulls out the information you need. It's a straightforward solution that's already being deployed in modern manufacturing facilities worldwide.

![Part with Serial No](https://flowfuse.com/blog/2025/11/images/serial-no-on-part.png){dataZoomable="" width="400"}*Part with Serial No*

For example, take a look at the image above. When processed with OCR, it returns the following text:

```text
Serial No: XYZ123456789
```

This tutorial shows you how you can build an OCR system using FlowFuse that can capture images from cameras, extract text from product labels, lot codes, and serial numbers, validate and parse the extracted data, store results in a database or trigger downstream workflows.

## Getting Started

Before we dive in, make sure you have a running FlowFuse instance.
If you do not have one yet, you can [sign up for the 30-day free trial](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"} and get a hosted instance running in under two minutes.

### Installing Required Nodes

To perform text extraction from images, you’ll need to install the `@sumit_shinde_84/node-red-contrib-simple-ocr` node in your FlowFuse instance.
This node uses the Tesseract OCR engine under the hood to recognize text from image files or image buffers.
To capture images and build a dashboard, you’ll also need the **FlowFuse Dashboard** and **Webcam** packages.

1. Open your **FlowFuse** editor.
2. From the main menu, select **Manage palette → Install**.
3. Search for and install the following packages one by one:
   - `@sumit_shinde_84/node-red-contrib-simple-ocr`
   - `@flowfuse/node-red-dashboard`
   - `@sumit_shinde_84/node-red-dashboard-2-ui-webcam`

Once installed, you’ll see the **simple-ocr** node under the **Function** category and the **Webcam** widget under the **dashboard 2.0** category in the left sidebar.

### Building the Scanner

Now, let’s build a scanner dashboard that you can open on a mobile device, allowing the phone to act as a scanner for capturing product labels and serial numbers.

:video{ariaLabel="Label Scanner Built with FlowFuse" autoPlay="true" height="720" loop="true" muted="true" playsInline="true" preload="none" width="1280"}&#x2A;[Label Scanner Built with FlowFuse]*

To capture images directly from your browser, you can use the **FlowFuse Dashboard** along with the **Webcam widget**, let's install them first.

#### Configuring the Webcam Node

1. Drag the **Webcam** widget onto your canvas.
2. Double-click the node to open its configuration.
3. Create a new ui group for it to render the feed (for example, *OCR Scanner*).
4. Drag the **Button** widget onto the canvas and set its label to **Scan**. Select the appropriate **group**, check **Enable pointerdown event**, and set the **payload** to `"capture"`.
5. Click **Done**. When the button is clicked, it will send the `"capture"` payload, which will trigger the **Webcam** widget to capture an image.

![Scan Label Button Widget Configuration](https://flowfuse.com/blog/2025/11/images/scan-label-button.png){dataZoomable=""}*Scan Label Button Widget Configuration*

6. Deploy the flow

When deployed, this flow creates a dashboard interface with a live camera preview and a large Scan Label button. Each time you click Scan Label, the captured image is sent as a `msg.payload.image` containing a image buffer.

> *Tip: To correct a flipped or mirrored camera preview, open the three-dot menu (⋮) on the webcam widget and enable "Mirror Image".*

##### Handling High-Resolution Images

When capturing an image, if you encounter an error stating that the image size exceeds **Dashboard 2.0’s** `maxHttpBufferSize`, you’ll need to reduce the image resolution or quality, otherwise, the dashboard connection may reset.

To fix this:

1. Double-click the **Webcam** widget.
2. Adjust the **image width**, **height**, and **quality** parameters.
3. By default, these are set to **640×480** resolution and **0.8** quality.

You can also check the image size from the webcam output using `msg.payload.sizeBytes`.

#### Adding the OCR Node

Now, let’s add an OCR node to extract text from the captured images.

1. Drag a **Change** node onto the canvas and set `msg.payload` to `msg.payload.image`.
2. Drag a **Simple OCR** node onto the canvas.
3. Connect the output of the **Webcam** widget to the **Change** node, and then connect the **Change** node’s output to the **Simple OCR** node.
4. Add a **Debug** node and connect it to the **Simple OCR** node to view the results.
5. Click **Done**, then **Deploy**.

Next, open the dashboard by clicking the **Dashboard 2.0** button in the right sidebar. Then, click the **Scan Label** button, the first click will activate your camera (make sure to grant your browser permission to access it).

Position the label in front of the camera, focus on it, and click **Scan** again. The recognized text will appear in the **Debug** panel.
Now, you need to validate and trim the recognized text, and add a visual indicator to show a successful scan. Let’s set that up next.

#### Validating and Parsing the Extracted Text

The OCR node returns raw text that may contain extra whitespace, line breaks, or unwanted characters. Let's add validation and parsing logic:

1. Drag another **Function** node onto the canvas.
2. Connect it after the **simple-ocr** node.
3. Add the following code:

```javascript
// Extract and clean OCR text
let text = (msg.payload.text || msg.payload || "")
  .replace(/[\r\n]+/g, ' ')
  .replace(/[^\w\s:]/g, '')
  .replace(/\s+/g, ' ')
  .trim();

// Match part number
let match = text.match(/(?:Part\s*No|No)[:\s]+([0-9A-Z]{6,12})/i);
let part = match?.[1]?.trim() || null;

// Validate format: 6 digits + 2 letters + 2 digits
let valid = part ? /^\d{6}[A-Z]{2}\d{2}$/.test(part) : false;

// Build payload
msg.payload = {
  success: valid,
  partNumber: valid ? part : null,
  timestamp: new Date().toISOString(),
  notificationMsg: valid
    ? `Label successfully scanned: ${part}`
    : "Scan failed, Invalid or unreadable label."
};

return msg;
```

> Tip: You don’t need to know JavaScript to create a function for validating and extracting the label text you’re scanning, just tell the [FlowFuse Expert](https://flowfuse.com/blog/2025/07/flowfuse-ai-assistant-better-node-red-manufacturing/) what you want, and it will generate it for you.

4. Click **Done**.

This function cleans the text, validates that something was detected, and attempts to extract structured data like serial numbers or part numbers using regular expressions.

#### Adding Visual Feedback

Users need immediate feedback when a scan succeeds or fails. Let's add both visual indicators:

1. Drag a **Change** node onto the canvas and connect it to the validation Function node.
2. Configure the Change node to set `msg.payload` to `msg.payload.notificationMsg`.
3. Drag a **ui-notification** widget onto the canvas.
4. Double-click the ui-notification node to configure it:
   - Select or create a **UI Base** configuration
   - Set the **position** to **center**
   - Optionally, configure the **timeout** duration (e.g., 3000ms for 3 seconds)
5. Connect the Change node output to the ui-notification node input.
6. Click **Done** and **Deploy** the flow.

Now when you scan a label:

- If the scan is successful, you'll see a green notification with "Label successfully scanned: [part number] "
- If the scan fails, you'll see a warning notification with "Scan failed, Invalid or unreadable label"

Your OCR scanning system is now complete! You can test it by opening the dashboard on your mobile device, positioning a product label in front of the camera, and clicking the Scan button. The system will capture the image, extract the text, validate it, and provide immediate visual feedback on the scan result.

::render-flow{:height='300'}
```json
[{"id":"604f466d22e1157b","type":"group","z":"9cf82b68bb89e8ce","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["a21c3c47d1f1cf10","3a71e800415a3966","ce383856293fe7e8","8858da9d0167fa59","45093fdd9e8c7374","223bb060bd896be0","c4a91f5b52a9c469","020e11e740154489","6ad6bad695c34c7b","31d2eb3589e05d01"],"x":84,"y":279,"w":822,"h":242},{"id":"a21c3c47d1f1cf10","type":"simple-ocr","z":"9cf82b68bb89e8ce","g":"604f466d22e1157b","name":"","x":750,"y":320,"wires":[["c4a91f5b52a9c469"]]},{"id":"3a71e800415a3966","type":"ui-webcam","z":"9cf82b68bb89e8ce","g":"604f466d22e1157b","name":"","group":"5a89ac7171f51cc3","width":0,"height":0,"passthru":false,"qrDetection":false,"imageWidth":"150","imageHeight":"150","imageQuality":"","x":380,"y":320,"wires":[["31d2eb3589e05d01"]]},{"id":"ce383856293fe7e8","type":"ui-button","z":"9cf82b68bb89e8ce","g":"604f466d22e1157b","group":"5a89ac7171f51cc3","name":"Scan Label Button","label":"SCAN","order":2,"width":0,"height":0,"emulateClick":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","iconPosition":"left","payload":"","payloadType":"str","topic":"topic","topicType":"msg","buttonColor":"","textColor":"","iconColor":"","enableClick":false,"enablePointerdown":true,"pointerdownPayload":"capture","pointerdownPayloadType":"str","enablePointerup":false,"pointerupPayload":"","pointerupPayloadType":"str","x":200,"y":320,"wires":[["3a71e800415a3966"]]},{"id":"8858da9d0167fa59","type":"function","z":"9cf82b68bb89e8ce","g":"604f466d22e1157b","name":"Extract and Validate Part Number","func":"// Extract and clean OCR text\nlet text = (msg.payload.text || msg.payload || \"\")\n  .replace(/[\\r\\n]+/g, ' ')\n  .replace(/[^\\w\\s:]/g, '')\n  .replace(/\\s+/g, ' ')\n  .trim();\n\n// Match part number\nlet match = text.match(/(?:Part\\s*No|No)[:\\s]+([0-9A-Z]{6,12})/i);\nlet part = match?.[1]?.trim() || null;\n\n// Validate format: 6 digits + 2 letters + 2 digits\nlet valid = part ? /^\\d{6}[A-Z]{2}\\d{2}$/.test(part) : false;\n\n// Build payload\nmsg.payload = {\n  success: valid,\n  partNumber: valid ? part : null,\n  timestamp: new Date().toISOString(),\n  notificationMsg: valid\n    ? `✅ Label successfully scanned: ${part}`\n    : \"⚠️ Scan failed, Invalid or unreadable label.\"\n};\n\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":310,"y":420,"wires":[["223bb060bd896be0","6ad6bad695c34c7b"]]},{"id":"45093fdd9e8c7374","type":"ui-notification","z":"9cf82b68bb89e8ce","g":"604f466d22e1157b","ui":"afea04ce8735c0a6","position":"center center","colorDefault":true,"color":"#000000","displayTime":"3","showCountdown":true,"outputs":1,"allowDismiss":true,"dismissText":"Close","allowConfirm":false,"confirmText":"Confirm","raw":false,"className":"","name":"","x":780,"y":420,"wires":[[]]},{"id":"223bb060bd896be0","type":"change","z":"9cf82b68bb89e8ce","g":"604f466d22e1157b","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.notificationMsg","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":570,"y":420,"wires":[["45093fdd9e8c7374"]]},{"id":"c4a91f5b52a9c469","type":"link out","z":"9cf82b68bb89e8ce","g":"604f466d22e1157b","name":"link out 1","mode":"link","links":["020e11e740154489"],"x":865,"y":320,"wires":[]},{"id":"020e11e740154489","type":"link in","z":"9cf82b68bb89e8ce","g":"604f466d22e1157b","name":"link in 1","links":["c4a91f5b52a9c469"],"x":125,"y":420,"wires":[["8858da9d0167fa59"]]},{"id":"6ad6bad695c34c7b","type":"debug","z":"9cf82b68bb89e8ce","g":"604f466d22e1157b","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":540,"y":480,"wires":[]},{"id":"31d2eb3589e05d01","type":"change","z":"9cf82b68bb89e8ce","g":"604f466d22e1157b","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.image","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":560,"y":320,"wires":[["a21c3c47d1f1cf10"]]},{"id":"5a89ac7171f51cc3","type":"ui-group","name":"Scanner","page":"f1eb99b1e714d411","width":6,"height":1,"order":1,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"afea04ce8735c0a6","type":"ui-base","name":"UI Name","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-control","ui-notification"],"headerContent":"page","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":5,"showDisconnectNotification":true,"allowInstall":true},{"id":"f1eb99b1e714d411","type":"ui-page","name":"Page Name","ui":"afea04ce8735c0a6","path":"/page1","icon":"home","layout":"grid","theme":"93822a7b43673c58","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"93822a7b43673c58","type":"ui-theme","name":"Default Theme","colors":{"surface":"#00a3d7","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"b5b8bfbe56c87605","type":"global-config","env":[],"modules":{"@sumit_shinde_84/node-red-contrib-simple-ocr":"0.1.1","@sumit_shinde_84/node-red-dashboard-2-ui-webcam":"1.1.2","@flowfuse/node-red-dashboard":"1.29.0"}}]
```
::

If you want to fully automate this process, you can set up a fixed camera positioned where products pass through on the production line. This approach eliminates manual scanning, but it will require proper camera mounting, lighting setup, and trigger mechanisms to capture images at the right moment as products move past the camera.

Furthermore, you can push scanned label data to a database. The easiest way to do this is using [FlowFuse Tables](https://flowfuse.com/blog/2025/08/getting-started-with-flowfuse-tables/), which is a built-in database service managed by FlowFuse. You'll find the **query** node in the palette that not only simplifies setup by connecting to the FlowFuse Tables database without any setup, it also has access to the integrated FlowFuse Expert, allowing you to [generate queries using natural language](https://flowfuse.com/blog/2025/09/ai-assistant-flowfuse-tables/), no SQL skills required!

## What's Next?

You've just built a working OCR system that turns any mobile device into a label scanner. It captures images, reads text, validates the data, and gives instant feedback, all without writing hundreds of lines of code.

This is just the starting point. Your system can grow with your needs: connect it to your inventory database, add support for different label formats, set up multiple scanning stations, or integrate it with your existing ERP system. The foundation is there.

Also, this OCR scanner is just one piece of what's possible with FlowFuse. Imagine connecting all your manufacturing systems, machine data, quality checks, inventory tracking, production metrics, into a unified industrial data platform where everything flows together seamlessly.

FlowFuse helps manufacturers like you break down data silos and build connected, intelligent operations. From shop floor to top floor, your data works together.

**See it in action.** [Book a demo](https://flowfuse.com/book-demo/) and discover how FlowFuse can transform your entire facility, not just your label scanning.

Or start building today with our [30-day free trial](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"}.


# How to Ingest CSV Logs into MQTT, Databases, and Dashboards

If you work in manufacturing, you likely have gigabytes of data in CSV files, temperature logs, production counts, machine status records. The data exists and is organized, but it's not accessible to the systems that need it.

PLCs log directly to CSV through proprietary software. Legacy SCADA systems write flat files. Custom applications generate daily reports. These systems are reliable, but they weren't built to integrate with MQTT brokers or databases.

If you're using FlowFuse to log data, you can send to MQTT and databases as data flows through FlowFuse. But if your CSV files come from PLCs, SCADA systems, or other external tools, you need to read and ingest them after they're written.

This guide shows you how to read CSV files, whether real-time or historical, and route them to MQTT brokers, databases, and dashboards.

### Prerequisites

Before starting, ensure you have:

- A running FlowFuse instance. If you don't have one, [sign up for free](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"}
- CSV log files with industrial data
- Access to an MQTT broker
- Access to a database

**Note:** If you have an Enterprise account, you won't need to set up external MQTT brokers or databases, FlowFuse provides these services built into the platform.

### Sample Data

If you don't have a CSV file and want to follow along, you can import the following flow and deploy it. This flow will simulate a temperature sensor and log readings to a daily CSV file.

::render-flow{:height='300'}
```json
[{"id":"66776385db5794bc","type":"group","z":"5a0080d134f80f7d","name":"","style":{"fill":"none","label":true,"fill-opacity":"0.57"},"nodes":["ac0d35a6466cfcb4","4aff5b57cbb63b8f","a5c5746934670306","23ebc0da4315ac46","2518dc909d447655"],"x":214,"y":279,"w":892,"h":82},{"id":"ac0d35a6466cfcb4","type":"csv","z":"5a0080d134f80f7d","g":"66776385db5794bc","name":"","spec":"rfc","sep":",","hdrin":true,"hdrout":"once","multi":"one","ret":"\\r","temp":"timestamp,temperature","skip":"0","strings":true,"include_empty_strings":"","include_null_values":"","x":670,"y":320,"wires":[["a5c5746934670306"]]},{"id":"4aff5b57cbb63b8f","type":"function","z":"5a0080d134f80f7d","g":"66776385db5794bc","name":"Daily PLC Logger","func":"// @ts-ignore Node ≥ 18.15 provides fs.statfsSync; editor types may lag\n\nconst now = new Date();\nconst dateStr = now.toISOString().split('T')[0];\nconst timestamp = now.toISOString();\n\nconst filename = `./plc_data_${dateStr}.csv`;\n\nmsg.payload = {\n    timestamp: timestamp,\n    temperature: msg.payload,\n};\n\nmsg.filename = filename;\n\n// Track last date in flow context\nconst lastDate = flow.get('lastDate') || '';\nif (lastDate !== dateStr) {\n    msg.reset = true; // Will trigger CSV node to write headers\n    flow.set('lastDate', dateStr);\n} \n\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":490,"y":320,"wires":[["ac0d35a6466cfcb4"]]},{"id":"a5c5746934670306","type":"file","z":"5a0080d134f80f7d","g":"66776385db5794bc","name":"Log Data to CSV file","filename":"filename","filenameType":"msg","appendNewline":true,"createDir":true,"overwriteFile":"false","encoding":"none","x":840,"y":320,"wires":[["2518dc909d447655"]]},{"id":"23ebc0da4315ac46","type":"inject","z":"5a0080d134f80f7d","g":"66776385db5794bc","name":"","props":[{"p":"payload"}],"repeat":"5","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"$round(70 + ($random() * 2), 2)","payloadType":"jsonata","x":310,"y":320,"wires":[["4aff5b57cbb63b8f"]]},{"id":"2518dc909d447655","type":"debug","z":"5a0080d134f80f7d","g":"66776385db5794bc","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1010,"y":320,"wires":[]}]
```
::

## Real-Time Data Pipeline

This pipeline monitors CSV files for changes and immediately publishes new data to MQTT topics. Use this approach when you need live data streams for dashboards, alerting systems, or real-time coordination between multiple systems.

### Step 1: Monitoring CSV Files

The Watch node continuously monitors a directory and triggers whenever a file is created or modified.

1. Drag the **Watch node** onto the canvas and double-click to configure it. Enter the directory path you want to monitor in the Files field, such as `/home/user/data/`.
2. Drag a **Change node** onto the canvas to set the correct filename. Configure it to set `msg.filename` using a JSONata expression: `"plc_data_" & $moment().format("YYYY-MM-DD") & ".csv"` which dynamically constructs the filename based on today's date. If your files use a different naming convention, adjust the expression accordingly.
3. Drag a **Read File node** onto the canvas to read the file contents. Set the Filename field to `msg.filename` as a message property. Configure the Output as "a single utf8 string" and leave Encoding at Default.

![Configuration screen of the Read File node showing filename set to msg.filename, output format as utf8 string, and default encoding](https://flowfuse.com/blog/2025/11/images/read-file-node.png){dataZoomable=""}*Configuration of the File In node to read CSV file contents*

4. Connect the output of the **Watch node** to the input of the **Change node**, and the output of the **Change node** to the input of the **Read File** node.
5. Deploy the flow.

At this point, whenever a CSV file in your monitored directory is created or modified, the flow reads its contents. The raw CSV data is now in `msg.payload` as a text string, ready to be parsed.

### Step 2: Parsing CSV Data

Now we'll convert the raw CSV text into structured data.

1. Drag a **CSV node**onto the canvas and connect it to the File In node output. Double-click to configure it to set:
   - Separator: Comma
   - Parser: RFC4180
   - Check "First row contains column names" and "Parse numerical values"
   - Output: "a single message [array] "

![CSV node configuration showing comma separator, RFC4180 parser, first row as column names, parse numerical values enabled, and output as single message array](https://flowfuse.com/blog/2025/11/images/csv-node-config.png){dataZoomable=""}*CSV parser configuration for batch processing with RFC4180 standard*

The CSV node now converts the raw text into an array of objects, where each object represents a row with named properties from the column headers.

### Step 3: Extracting the Latest Record

Since we’re reading the entire file each time it changes, we only need to publish the most recent data point to MQTT.

1. Drag a **Function node** onto the canvas and connect it to the CSV node output.
2. Add this code to extract only the latest row:

```javascript
// msg.payload is an array of all CSV rows
const rows = msg.payload;

// Extract only the latest row
if (rows && rows.length > 0) {
    msg.payload = rows[rows.length - 1];
    return msg;
} else {
    // No data in file yet
    return null;
}
```

3. Deploy the flow.

Your parsed data now flows through as individual records, ready to be published to MQTT.

### Step 4: Publishing to MQTT

Now we'll publish the parsed CSV data to an MQTT broker for real-time distribution. If you have FlowFuse Team or Enterprise tier, [enable the MQTT broker within your FlowFuse team](https://flowfuse.com/blog/2025/10/plc-to-mqtt-using-flowfuse/#step-3-set-up-mqtt-with-flowfuse).

#### Adding Context to Your Data

1. Drag a **Change node** onto the canvas and connect it to the output of the **Function node**. This step adds useful context for better data traceability.
2. Configure the node to set `msg.payload` to a structured object, customize it based on your data and application needs:

```javascript
{
    "timestamp": payload.timestamp,
    "site": "tokyo_plant",
    "line": "assembly_line_a",
    "device": "press_01",
    "measurement": "temperature",
    "value": payload.temperature,
    "unit": "celsius"
}
```

#### Configuring the MQTT Publisher

1. Drag the **ff-mqtt-out node** onto the canvas and connect it to the **Change node**. When you drag the node, it will be automatically configured with the FlowFuse MQTT broker, you do not need to manually add configuration.
2. By default, the client automatically created for your instance only has **subscribe** permissions. Click **Configure Access Control** next to the server in the node configuration window. This will redirect you to the platform’s broker client management page, filtered to show the client associated with this instance. Click the **Edit** button, enable both **Publish** and **Subscribe** actions, and then restart your instance.
3. Set the **topic** following ISA-95 hierarchy:

```text
company/site/area/line/cell/device/measurement
```

For example:

```text
acme/tokyo/assembly/line-a/press-01/temperature
```

4. Configure the **QoS level** in the MQTT node. Set it to QoS 1 for reliable delivery, this ensures your data reaches subscribers even if there are brief network issues, or choose according to your reliability requirements (QoS 0 for high-frequency non-critical data, QoS 2 for critical data).

![Configuring the MQTT Out node](https://flowfuse.com/blog/2025/11/images/csv-to-mqtt.png){dataZoomable=""}*Configuring the MQTT Out node*

5. Deploy the flow.

## Batch Processing Pipeline

This pipeline reads CSV files on a schedule and writes data to databases in efficient batches. Use this approach for historical data storage, trend analysis, and reporting where immediate writes aren't necessary.

### Step 1: Reading CSV Files on Schedule

Unlike the real-time pipeline that watches for file changes, batch processing runs on a timer.

1. Drag an **Inject node** onto the canvas. Configure it to trigger on your desired schedule:
   - For hourly batches: Set repeat interval to "interval" and enter 1 hour
   - For shift-based batches: Add multiple inject nodes, For example, one at 08:00 for night shift end, another at 16:00 for day shift end, and a third at 00:00 for evening shift end.
   - For daily batches: Set to trigger "at a specific time" once per day
2. Drag a **Change node** and configure it to set `msg.filename` to your CSV file path. Use a JSONata expression if you need dynamic filenames: `"plc_data_" & $moment().format("YYYY-MM-DD") & ".csv"`. If your files use a different naming convention, adjust the expression accordingly.
3. Drag a **Read File node** onto the canvas to read the file contents. Set the Filename field to `msg.filename` as a message property. Configure the Output as "a single utf8 string" and leave Encoding at Default.
4. Connect the output of the **Inject node** to the input of the **Change node**, and the output of the **Change node** to the input of the **Read File** node.

### Step 2: Parsing All Records

1. Drag a **CSV node** and connect it to the File In node output.
2. Configure it the same way as in the real-time pipeline:
   - Separator: Comma
   - Parser: RFC4180
   - Check "First row contains column names" and "Parse numerical values"
   - Output: "a single message [array] "

### Step 3: Filtering New Records

Since we’re reading the entire CSV file each time, we need to track which rows have already been written to the database to avoid duplicates.

1. Drag a **Function node** and connect it to the **CSV node** output. Add this code:

```javascript
const allRows = msg.payload;

// Get the last processed row count from flow context
let lastRowCount = flow.get('lastRowCount') || 0;

// Get only new rows since last processing
const newRows = allRows.slice(lastRowCount);

if (newRows.length > 0) {
    // Update the row count for next run
    flow.set('lastRowCount', allRows.length);
    
    msg.payload = newRows;
    return msg;
} else {
    // No new data to process
    node.warn("No new records to process");
    return null;
}
```

### Step 4: Inserting to Database

Now we'll configure the database insertion to write batched data efficiently.

#### Enabling FlowFuse Database

If you have a Enterprise account, you can use the built-in PostgreSQL database service instead of setting up an external database. Follow the instructions in [Getting Started with FlowFuse Tables](https://flowfuse.com/blog/2025/08/getting-started-with-flowfuse-tables/#step-1-enable-the-database-in-your-project) to enable the database in your project.

Once enabled, you'll have access to a fully managed PostgreSQL database that's automatically configured and ready to use with your FlowFuse flows.

#### Creating the Database Table

Before inserting data, you need to create a table to store your sensor readings.

1. In your Node-RED editor, drag a **Query node** onto the canvas. Just like the FlowFuse MQTT nodes, it will automatically configure itself when added to the canvas.
2. Double-click to open it and click &#x2A;*"Ask the FlowFuse Expert"** at the top of the configuration dialog.
3. In the assistant prompt, enter:
   &#x2A;“Create a new table named `sensor_data` to store sensor readings with the following columns: `timestamp`, `site`, `line`, `device`, `measurement`, `value`, and `unit`.”*, Modify the table name and columns as needed to match your specific data and application requirements.
4. Click the &#x2A;*"Ask the FlowFuse Expert"** button. The assistant will generate the SQL query for you and automatically populate it in the Query field.
5. Drag an **Inject node** onto the canvas, set it to trigger once, and connect it to the **Query node**.
6. Add a **Debug node** connected to the **Query node** output to see the result.
7. Deploy the flow and click the Inject button to create the table.

#### Preparing Data for Batch Insert

Instead of writing each CSV row individually to the database, we'll use batch inserts for much better performance. A single transaction with many rows is far more efficient than many separate transactions.

1. Drag a **Function node** onto the canvas and connect it to the previous **Function node** (the one that filters new records).
2. Name this node "Prepare Batch Insert" and add the following code:

```javascript
// msg.payload contains the new rows from CSV
const newRows = msg.payload;

// Transform each row to match your database schema
const formattedData = newRows.map(row => ({
    timestamp: row.timestamp,
    site: 'tokyo_plant',
    line: 'assembly_line_a', 
    device: 'press_01',
    measurement: 'temperature',
    value: row.temperature,
    unit: 'celsius'
}));

// Generate parameter placeholders for batch insert
// Each row has 7 fields, so we need 7 parameters per row
// Example: ($1,$2,$3,$4,$5,$6,$7), ($8,$9,$10,$11,$12,$13,$14), ...
const values = formattedData.map((_, i) => 
    `($${i * 7 + 1}, $${i * 7 + 2}, $${i * 7 + 3}, $${i * 7 + 4}, $${i * 7 + 5}, $${i * 7 + 6}, $${i * 7 + 7})`
).join(',');

// Build the SQL insert query with placeholders, modify the query according to your table name and schema.
msg.query = `
    INSERT INTO sensor_data 
    (timestamp, site, line, device, measurement, value, unit)
    VALUES ${values};
`;

// Flatten the data into a single array of parameters
// Order must match the columns in the INSERT statement
msg.params = formattedData.flatMap(r => [
    r.timestamp,
    r.site,
    r.line,
    r.device,
    r.measurement,
    r.value,
    r.unit
]);

return msg;
```

3. Click Done.

This function generates a parameterized SQL query that inserts all rows in a single database transaction, which is significantly faster than individual inserts.

## Visualizing CSV Data on Dashboard

Now that we've ingested CSV data into MQTT and databases, let's visualize it on a dashboard. We'll focus on real-time visualization using the MQTT pipeline we built earlier. For historical data visualization from FlowFuse Tables, refer to our comprehensive guide: [Building Time-Series Dashboards with FlowFuse Tables](https://flowfuse.com/blog/2025/08/time-series-dashboard-flowfuse-postgresql/)

#### Step 1: Installing Dashboard

1. In your Node-RED editor, click the hamburger menu (≡) in the top right corner.
2. Select **Manage palette**.
3. Go to the **Install** tab.
4. Search for `@flowfuse/node-red-dashboard`.
5. Click **Install** and confirm.

#### Step 2: Subscribing to MQTT Data

1. Drag an **ff-mqtt-in node** onto the canvas.
2. Configure the Topic to match your publisher: `acme/tokyo/assembly/line-a/press-01/temperature`
3. Set **Output** to "auto-detect (string or buffer)".

![Configuring the MQTT Out node](https://flowfuse.com/blog/2025/11/images/mqtt-to-dashboard.png){dataZoomable=""}*Configuring the MQTT Out node*

#### Step 3: Creating the Dashboard Widgets

Now we'll add a chart to visualize the temperature data in real-time.

1. Drag a **ui-chart** widget onto the canvas and double-click it. Create a new UI group for it to render.
2. Set the size according to your needs for the chart, label to "Temperature", type to "line", action to "append", and x-axis to "timescale".
3. Next, set series to `msg.payload.device`, x to `msg.payload.timestamp`, and y to `msg.payload.value`.

![UI Chart configuration showing line chart type, append action, timescale x-axis, with series, x, and y values mapped to payload properties](https://flowfuse.com/blog/2025/11/images/chart-node-config.png){dataZoomable=""}*Chart widget configuration for real-time temperature visualization*

4. Click **Deploy**.

Once deployed, open the dashboard, you should see a real-time line chart displaying temperature values over time, with each device shown as a separate series. Data points will automatically update as new MQTT messages arrive.

:video{ariaLabel="Dashboard showing real-time line chart with temperature data updating as new MQTT messages arrive" autoPlay="true" height="351" loop="true" muted="true" playsInline="true" preload="none" width="800"}*Live dashboard displaying real-time temperature readings from CSV data stream*

## What's Next

You've transformed static CSV files into live data streams that flow through MQTT, databases, and dashboards. Your legacy equipment now communicates with modern systems without any hardware changes.

This tutorial walked you through building a data pipeline. FlowFuse takes it further by handling both development and production deployment. When you need to scale across multiple production lines, manage team collaboration, deploy to hundreds of devices remotely, or maintain infrastructure like MQTT brokers and databases, FlowFuse provides the platform to do it all. As you saw, it also includes an FlowFuse Expert to speed up your workflow.

If you want to see more on how FlowFuse helps with scaling and production deployments, [book a demo](https://flowfuse.com/book-demo/) today.


# FlowFuse + LLM + MCP = Text Driven Operations

In industrial operations it's all about getting more out of the CAPEX already
spent. Achieving higher efficiency means everyone needs to get data from a lot of
different machines, have an understanding how these machines form lines and fit
together, and holistically understand these as a group of assets that collectively
can achieve more.

With the rapid adoption of Artificial Intelligence (AI), Model Context
Protocol, low-code platforms it's clear that the future of operations is
conversational.
The interface to machines is becoming plain text, allowing teams to obtain effects
and scale operational excellence across entire business units simply by asking
the right questions.

## The Context Challenge

Data capture involves integrating various machine protocols (like
[OPC-UA](https://flowfuse.com/node-red/protocol/opc-ua/) or [Modbus](https://flowfuse.com/node-red/protocol/modbus/)),
transporting, combining, and visualizing the information. While low-code tools
like Node-RED have decreased the implementation time to mere hours, the full
problem isn't solved: what happens *after* the data is collected?

Often, raw sensor data, like pressure, voltage, and temperature readings, lacks
context to immediately understand there's a problem worth solving. Even when a dashboard
has been built, spotting an issue (such as a high energy consumption on `machine 1`)
doesn't inherently guide the operator on how to resolve it.
Furthermore, data flow often involves a psychological hurdle, moving from areas
where an engineer feels comfortable (perhaps the data storage side) to areas of
less expertise (like machine protocols or physical voltage readings).

The goal is to asking high-level questions, such as:
"What changed in the energy consumption for machine 4?".

## Text: The New Language of Control

Removing code, often a complex layer, can be now achieved because of Large Language
Models (LLMs) and the Model Context Protocol (MCP).

LLMs, like ChatGPT, predict the next word in a sentence, allowing humans to
query systems using **natural language** rather than complex code.
LLMs face fundamental limitations though: they are typically cloud-based, can be
slow, and are trained at specific points in time, meaning they cannot inherently
react to real-time, event-based data or proprietary local context.

This is where the &#x2A;*Model Context Protocol (MCP)** steps in. The promise of
MCP is to give models more context through an agreed-upon protocol.
MCP allows operators to define exactly what read-only information (resources) or
functionality (tools) they want to expose to the LLM.

- **Resources** are read-only, like sensor readings, employee staff lists, vacation calendars, or specification sheets (e.g., upper and lower temperature limits).
- **Tools** are functions that allow the LLM to perform an action or change a state in the physical world.

By feeding this context into an MCP server (such as the official [FlowFuse MCP node](https://flowfuse.com/node-red/flowfuse/mcp/)),
the LLM transforms into a powerful operational partner.

For example, an operator can ask: "Can you show me the last five temp sensor readings recorded?".
Once the model identifies an anomaly, the operator can incorporate specifications and ask: "Are any of these values outside of spec for upper temp or lower temp?".
If a problem is confirmed, the system can use staff and location data to answer a pointed question like: &#x2A;*"Who are all the staff located nearest to the problem, and what is the quickest way to get there?"**.
This capability quickly transforms complex data into actionable steps, finding the problem, comparing it to specs, finding the right person, and routing them to the site, all within a matter of minutes.

## Orchestrating Effects Across the Machine Fleet

The ability to propagate these text-driven decisions across many machines by the
same team is enabled by Node-RED serving as the essential integration layer.

FlowFuse, a major corporate sponsor of Node-RED, aims to fuse the digital realm
with machines and the shop floor for IoT use cases. Node-RED acts as the shell
that connects proprietary and legacy machine protocols (OT side) to the modern MCP structure.

If a manufacturing facility wants to allow an LLM to control a physical device,
Node-RED can integrate the machine (e.g., a Siemens S7 stack light) and wrap the
control logic in an MCP tool. The LLM requests an action
(e.g., "turn the stack light green"), the MCP tool sends the action through
Node-RED's established adapters, and the action is executed.

This means that existing organizational logic and machine adapters, which have
already been integrated into Node-RED, can be instantly made LLM and AI ready.
This rapid adaptation allows a very broad spectrum of engineers to be applied to
problems, moving past relying on "tribal knowledge" held by a single expert.

## Text-Driven Playbooks and the Human in the Loop

Looking ahead, this technology enables the creation of **text-driven playbooks**.
An operator might input a natural language prompt:
"How do we optimize a certain procedure in the factory?". The resulting
operational procedure, driven by the LLM and executed via MCP tools, becomes a
documented playbook. This system helps organizations achieve operational excellence
by turning human text input into processes that the rest of the company can read,
understand, and replicate.

However, the industry must move cautiously. A critical element of the future of
operations is the necessity of a `human in the loop`.

AI is predictive and, in certain ways, random, meaning that if context slightly
changes, the output is not deterministic. When the consequences of an action are
physical or high-stakes
(e.g., stopping a production line, or an irreversible action like boiling an egg),
full control should not be handed over to a non-deterministic system. The risk of
an AI being "as confident when they're wrong as when they're right" necessitates human oversight.

For the near future (the next five years), the AI acts as a partner or a fault
partner, making the uncomfortable aspects of complex flows more manageable. It is
currently best applied in reversible or digital tasks, such as generating reports
or triggering low-consequence actions like turning a stack light orange to signal
an engineer. As trust grows and impacts iterate, AI will gain more influence and
context, but the final, consequential decisions will remain with the human.

The combination of LLMs, MCP, and Node-RED provides operators with super powers.
The operational floor is transforming from a place where experts write complex
code for singular machines, to a conversational environment where high-level, natural
language queries drive intelligent, scalable actions across the entire enterprise.

Ready to experience text-driven operations in your own facility?
[Try FlowFuse for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} or request a personalized demo to see how LLM-powered automation can transform your industrial processes.
[Contact us today](https://flowfuse.com/contact-us/) or sign up for our upcoming webinar to stay ahead in the Industry 4.0 revolution.


# FlowFuse 2.24: FlowFuse Expert in the Node-RED Editor, Scheduled Updates, Simpler Edge Device Addition, Store and Forward Blueprint, and what's next!

This release unlocks several new abilities for our users, speeding your development time, easing management of Node-RED instances, providing a smoother path to adding large numbers of devices, and more. Let's dig in.

:product-update-note

## FlowFuse Expert

![Image of FlowFuse Expert UI](https://flowfuse.com/blog/2025/11/images/ff-expert-ui.png)&#x2A;[FlowFuse Expert UI]*

The FlowFuse Expert used to live only on flowfuse.com, where you could use an LLM trained on FlowFuse and Node-RED documentation, and trained by the Node-RED experts at FlowFuse. Now, we've taken it a step further. The FlowFuse Expert is now available inside of the FlowFuse UI, and even in the Immersive Editor in Node-RED!

You are no longer limited in your interactions with the FlowFuse Expert by the location where you started your conversation. Keep the conversation going and rely on the Expert's advice right where you're building in Node-RED.

Even better, when you're working in the Immersive Editor, the Expert will recommend flows based on your inputs, and you can copy and paste them directly into the Node-RED Editor, once again saving you time and reducing the effort needed to develop in Node-RED.

## Automatic Updates of Instances

![Image of Scheduled Updates UI](https://flowfuse.com/blog/2025/11/images/scheduler.png)&#x2A;[Scheduled Updates Interface]*

When there are new updates to Node-RED, or the FlowFuse components, it has been a manual task for users to spot the update and trigger the upgrade to get the latest fixes and features applied to their instances.

We're here to make your tasks easier, not to give you more maintenance burdens. So with this release, we've introduced the ability to automatically apply any updates that are available to Node-RED or the FlowFuse stack around it. You get to pick a maintenance window during the week for when the updates should get applied.

For Starter tier teams, we will apply a default schedule for overnight at the weekend to minimise disruption. For Pro and Enterprise tiers, users can configure their own schedule via the Instance's Maintenance settings tab.

Keeping your software up to date is important, and this features gives you one less thing to worry about.

## Simpler Edge Device Addition

![Image of UI for provisioning token](https://flowfuse.com/blog/2025/11/images/token.png)&#x2A;[Provisioning Token Interface]*

Many of our customers make use of large fleets of edge devices. Through the use of provisioning tokens it's easy to get lots of devices setup quickly - but there were still some additional steps needed to get the devices properly named and organised. Now, when setting up a new device with a provisioning token, it is possible to name it at the same time, reducing the complexity of the workflow. We want you to be able to scale up your edge device count quickly and easily, and this represents a significant step in that direction.

## Blueprint: Store and Forward

When data acquisition and processing at the edge is mission critical, it is vital that data received at the edge can be stored and protected until it can be forwarded to its destination. Having heard from customers that an easy way to execute a store and forward structure is needed, we have created this Blueprint to speed your development of this data-preserving flow.

Find out more on the [blueprint page](https://flowfuse.com/blueprints/getting-started/store-and-forward/).

# Sneak Peek

FlowFuse MCP nodes allow you to surface information to an LLM to create custom AI agents. We're working on enabling FlowFuse to identify anything you have surfaced to an MCP, paving the way for creating massively powerful agents, enabled by everything you've connected to FlowFuse.

## FlowFuse Expert for Open-Source Node-RED

FlowFuse Expert is our collection of AI-enhancements within the Node-RED editor - assisted creation of Function nodes, autocompleting flows and documentation generation amongst other features. Currently it's an exclusive feature of the FlowFuse platform, but we're hard at work to bring it to standalone Node-RED instances.

Coming soon you'll be able to experience the power of AI-enhanced development within Node-RED wherever it's running.

## What else is new?

For a complete list of everything included in our 2.24 release, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.24.0){rel="&#x22;nofollow&#x22;"}.

Your feedback continues to be invaluable in shaping FlowFuse's development. We'd love to hear your thoughts on these new features and any suggestions for future improvements. Please share your experiences or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Which of these new features are you most excited to try? Email me directly at <greg@flowfuse.com> - I'd love to hear from you!

## Try FlowFuse

### FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in the cloud within minutes.

### Self-Hosted

Get FlowFuse running locally in under 30 minutes using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# How to Protect Your Factory From Bad Data: A Must-Have Read for IIoT

Bad data quietly corrupts production analytics, triggers false equipment alarms, and causes automation systems to make faulty control decisions. Unlike system crashes, these issues go unnoticed until they've already propagated through your operations, affecting multiple processes and causing unexpected shutdowns or production anomalies.

This article shows you how to build a data validation gateway using FlowFuse that stops bad data before it reaches your critical systems. You'll implement validation checkpoints, establish quality rules, and configure alerts, creating a protective barrier that ensures only reliable data flows into your production environment.

Below is a short video demonstration of the data validation gateway we'll be building together.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: _yThV3eurhw
---
::

## The Problem with Trusting Your Data

Most industrial applications assume incoming data is valid, temperature sensors send numbers between 0-100°C, MQTT messages contain properly formatted JSON, PLC status codes follow documented formats. There's usually no validation checking if these assumptions hold true.

This works until it doesn't. Sensors drift out of calibration. Network issues corrupt packets. Firmware updates change data formats without warning. When these things happen, bad data flows straight through unchecked.

Consider a temperature sensor sending `{"temperature": 72.5, "unit": "Celsius"}`. Then electromagnetic interference corrupts transmission, and your system receives `{"temperature": "ERR", "unit": "Celsius"}`. Your code tries to do math with "ERR", it fails silently, throws an exception, or worse, coerces "ERR" to NaN or 0. Now you're making decisions based on garbage data without realizing it.

Scale makes this worse. With hundreds of sensors, multiple PLCs, edge gateways, and third-party integrations sending data continuously, quality issues aren't occasional, they're constant. You spend more time troubleshooting data problems than actual equipment problems. Reports contain incorrect numbers. Predictive models make bad predictions from corrupted training data.

The solution isn't hoping for perfect data, it's validating it explicitly. That's what we're building in this guide.

## Understanding Data Quality

Before we start building, we need to answer a simple but critical question:

**What makes data "good"?**

This isn't about what data you collect or which machine it comes from. It's about whether the data is **reliable enough to drive decisions without causing chaos**.

Good data enables confident automation and informed decision-making.

Bad data misleads, and when your automation acts on misleading information, your team and operations pay the price.

To build effective validation, you need to check multiple dimensions of data quality. Some key aspects include:

- **Type Correctness**: Is the temperature a number or the string "ERR"?
- **Completeness**: Are all required fields present?
- **Range Validation**: Is the temperature between 0-100°C or an impossible 500°C?
- **Format Consistency**: Is the timestamp in ISO 8601 format or some custom format?

These aren't rigid categories, they're lenses through which you examine your data. Real validation often combines several of these checks together.

## Building Your Data Quality Checker

Now that we understand what "good data" looks like, let's build guardrails to enforce it.

> Before we start, make sure you have a running FlowFuse instance that is collecting data. If you don't have a real data source, don't worry, we'll provide a simulated setup as well. Just make sure you have a FlowFuse account and instance running. If you don't have an account, create one now with our [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}.

### Installing the JSON Schema Validator Node

For our validation system, we'll use [JSON Schema](https://json-schema.org/){rel="&#x22;nofollow&#x22;"}, a powerful, industry-standard way to define what valid data should look like. Think of it as a contract that your data must fulfill before entering your system.

JSON Schema lets you specify exactly what fields should exist, what types they should be, what ranges are acceptable, and what formats are required. Instead of writing dozens of if-statements to check each condition, you define the rules once in a schema, and the validator does the heavy lifting.

To get started, install the `node-red-contrib-full-msg-json-schema-validation` node in your FlowFuse instance:

1. Open your FlowFuse instance
2. Click the hamburger menu (three horizontal lines) in the top right
3. Select **Manage palette**
4. Go to the **Install** tab
5. Search for `node-red-contrib-full-msg-json-schema-validation`
6. Click **Install** next to the node

Once installed, you'll find the "json full schema validator" node in your palette under the function category.

### Creating Your First Validation Schema

Let's start with a practical example, validating temperature sensor data. Here's what we expect our sensor to send:

```json
{
    "temperature": 72.5,
    "unit": "Celsius",
    "sensor_id": "TEMP_LINE_01",
    "timestamp": "2025-11-21T10:30:00Z"
}
```

Now let's create a JSON Schema that validates this structure:

```json
{
    "type": "object",
        "required": ["temperature", "unit", "sensor_id", "timestamp"],
            "properties": {
        "temperature": {
            "type": "number",
                "minimum": 0,
                    "maximum": 100,
                        "description": "Temperature reading in Celsius"
        },
        "unit": {
            "type": "string",
                "enum": ["Celsius"],
                    "description": "Temperature unit (Celsius only)"
        },
        "sensor_id": {
            "type": "string",
                "pattern": "^TEMP_LINE_[0-9]+$",
                    "description": "Sensor identifier following the required naming convention"
        },
        "timestamp": {
            "type": "string",
                "format": "date-time",
                    "description": "ISO 8601 formatted timestamp"
        }
    },
    "additionalProperties": false
}
```

Let's break down what this schema validates:

- **Type Safety:** temperature must be a number (catches `"ERR"`, null, undefined)
- **Required Fields:** all 4 must exist (catches incomplete messages)
- **Range Limits:** temperature must be between 0–100°C.
- **Value Constraints:** unit must match the enum "Celsius" (enforces consistent units)
- **Format Rules:** ISO 8601 timestamps and `TEMP_LINE_*` naming (catches config/naming errors)

The `additionalProperties: false` line is particularly important, it rejects any data with unexpected fields, preventing schema drift over time.

#### Building the Validation Flow

Now let's build the flow:

1. Drag in your data input node such as MQTT In node, HTTP In node, or Inject node (for testing)
2. Drag the **JSON Full Schema Validator** node into your flow
3. Double-click the validator node and paste your JSON schema into the schema field.

![JSON Schema Validator node configured with schema rules](https://flowfuse.com/blog/2025/11/images/json-schema-validator.png){dataZoomable=""}*JSON Schema Validator node configured with schema rules*

4. The validator node has two outputs:
   - **Output 1**: Valid data that passes all schema checks
   - **Output 2**: Invalid data that fails validation

When validation fails, the node adds a `msg.error` property as an array, where each item provides detailed information about what went wrong (missing fields, incorrect types, out-of-range values, etc.)

5. Connect Output 1 to your normal processing pipeline (database writes, dashboards, automation logic)
6. Connect Output 2 to an error handler that logs the error details.

### Testing Your Validator

Time to test your validator. We'll use the **temperature sensor schema from the example above**, but you can follow these same steps with any schema you create. Just make sure your test payload matches what your schema expects, same field names, correct data types, and proper structure. Then you can tweak the values to trigger validation failures and see how your error handling responds.

Add an **Inject** node with this valid payload, and connect it to your JSON Schema Validator node:

```json
{
    "temperature": 72.5,
    "unit": "Celsius",
    "sensor_id": "TEMP_LINE_01",
    "timestamp": "2025-11-21T10:30:00Z"
}
```

This passes all checks against the temperature sensor schema example and routes to your valid data handler.

Now test with bad data:

```json
{
    "temperature": "ERR",
    "unit": "Celsius",
    "sensor_id": "TEMP_LINE_01",
    "timestamp": "2025-11-21T10:30:00Z"
}
```

This fails because `temperature` is a string instead of a number (as defined in our example schema), routing to your error handler. The `msg.error` output shows exactly what's wrong:

```json
[{
  "keyword": "type",
  "dataPath": ".temperature",
  "schemaPath": "#/properties/temperature/type",
  "params": {
    "type": "number"
  },
  "message": "should be number"
}]
```

These detailed error messages eliminate guesswork. You see the field, the problem, and where validation failed.

Test additional scenarios to see how the validator catches different issues:

**Missing required field:**

```json
{
  "temperature": 72.5,
  "unit": "Celsius",
  "timestamp": "2025-11-21T10:30:00Z"
}
```

**Out of range value:**

```json
{
  "temperature": 150,
  "unit": "Celsius",
  "sensor_id": "TEMP_LINE_01",
  "timestamp": "2025-11-21T10:30:00Z"
}
```

**Invalid enum value:**

```json
{
  "temperature": 72.5,
  "unit": "F",
  "sensor_id": "TEMP_LINE_01",
  "timestamp": "2025-11-21T10:30:00Z"
}
```

Each failure produces specific error messages that pinpoint the exact issue.

## Setting Up Error Alerts

Now that your validator is catching bad data on Output 2, let's set up Telegram notifications so you get instant mobile alerts whenever validation fails.

### Installing the Telegram Node

First, install the Telegram node from the palette:

1. Click the **hamburger menu** (three horizontal lines) in the top right.
2. Select **Manage palette**.
3. Go to the **Install** tab.
4. Search for `node-red-contrib-telegrambot`.
5. Click **Install** next to the node.
6. Wait for installation to complete.

Once installed, you'll find the "telegram sender" and "telegram receiver" nodes in your palette.

### Creating Your Telegram Bot and Getting Your Chat ID

Before you can send alerts, you need to create a Telegram bot and get your Chat ID. We have a detailed guide that walks you through the entire process: [How to Create a Telegram Bot and Find Your Chat ID](https://flowfuse.com/node-red/notification/telegram/#creating-a-bot-in-telegram)

Once you have your **bot token** and **Chat ID**, come back here to continue with the alert setup.

### Create the Alert Message

Now we'll format the error information into a clear Telegram message.

1. Find your validator node (the JSON Schema Validator).
2. Look at its **second output** (the bottom one). This is where bad data with errors comes out.
3. Drag a **function** node onto the canvas.
4. Connect it to the validator's **second output**.
5. Double-click the function node to open it.
6. Change the **Name** at the top to: `Format Alert` and add the following JavaScript:

```javascript
// Get error information
const errors = msg.error || [];
const badData = msg.payload || {};

// Build error list
let errorText = "";
errors.forEach((err, index) => {
    errorText += `${index + 1}. Field: ${err.dataPath || 'unknown'}\n`;
    errorText += `   Problem: ${err.message}\n\n`;
});

// Get current time
const time = new Date().toLocaleString();

// Build the alert message
msg.payload = {
  chatId: "PUT_YOUR_CHAT_ID_HERE",
  type: "message",
  content: `🚨 DATA VALIDATION FAILED

Time: ${time}
Sensor: ${badData.sensor_id || 'Unknown'}

ERRORS FOUND:
${errorText}

BAD DATA:
${JSON.stringify(badData, null, 2)}`
};

return msg;
```

1. Find the line `chatId: "PUT_YOUR_CHAT_ID_HERE"`.
2. Replace `PUT_YOUR_CHAT_ID_HERE` with your actual Chat ID.
3. Click **Done**.
4. Drag **telegram sender** node onto the canvas.
5. Connect your **Format Alert** function node to the **telegram sender** node.
6. Double-click the **telegram sender** node.
7. Click the &#x2A;*+** icon next to **Bot** to add your bot configuration.
8. Paste your **Bot Token** that you got from BotFather.
9. Give it a name like "Quality Check Bot".
10. Click **Add**, then **Done**.
11. Click **Deploy**.

Now test your setup by triggering a validation failure. You should receive an instant Telegram message showing exactly what went wrong.

Below is the complete flow that demonstrates the entire validation pipeline, from receiving sensor data to catching errors and sending Telegram alerts.

::render-flow{:height='300'}
```json
[{"id":"9b9f55548911ac66","type":"inject","z":"d7101f3a4d45deed","name":"Invalid Data","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"temperature\":\"ERR\",\"unit\":\"Celsius\",\"sensor_id\":\"TEMP_LINE_01\",\"timestamp\":\"2025-11-21T10:30:00Z\"}","payloadType":"json","x":260,"y":480,"wires":[["93c2895e93507e19"]]},{"id":"ae110e07ad7685d7","type":"debug","z":"d7101f3a4d45deed","name":"Data","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":760,"y":360,"wires":[]},{"id":"df3cea6a5e793d66","type":"function","z":"d7101f3a4d45deed","name":"Format Alert","func":"// Get error information\nconst errors = msg.error || [];\nconst badData = msg.payload || {};\n\n// Build error list\nlet errorText = \"\";\nerrors.forEach((err, index) => {\n    errorText += `${index + 1}. Field: ${err.dataPath || 'unknown'}\\n`;\n    errorText += `   Problem: ${err.message}\\n\\n`;\n});\n\n// Get current time\nconst time = new Date().toLocaleString();\n\n// Build the alert message\nmsg.payload = {\n    chatId: \"PUT_YOUR_CHAT_ID_HERE\",\n    type: \"message\",\n    content: `🚨 DATA VALIDATION FAILED\n\nTime: ${time}\nSensor: ${badData.sensor_id || 'Unknown'}\n\nERRORS FOUND:\n${errorText}\n\nBAD DATA:\n${JSON.stringify(badData, null, 2)}`\n};\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":750,"y":500,"wires":[["73c2d99fc1d7025a"]]},{"id":"c97a4811cf6d94ec","type":"inject","z":"d7101f3a4d45deed","name":"Valid Data","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"temperature\":72.5,\"unit\":\"Celsius\",\"sensor_id\":\"TEMP_LINE_01\",\"timestamp\":\"2025-11-21T10:30:00Z\"}","payloadType":"json","x":250,"y":400,"wires":[["93c2895e93507e19"]]},{"id":"b82034c189d13fd5","type":"comment","z":"d7101f3a4d45deed","name":"Data Simulation","info":"","x":260,"y":340,"wires":[]},{"id":"93c2895e93507e19","type":"json-full-schema-validator","z":"d7101f3a4d45deed","name":"","property":"payload","propertyType":"msg","func":"{\n    \"type\": \"object\",\n        \"required\": [\"temperature\", \"unit\", \"sensor_id\", \"timestamp\"],\n            \"properties\": {\n        \"temperature\": {\n            \"type\": \"number\",\n                \"minimum\": 0,\n                    \"maximum\": 100,\n                        \"description\": \"Temperature reading in Celsius\"\n        },\n        \"unit\": {\n            \"type\": \"string\",\n                \"enum\": [\"Celsius\"],\n                    \"description\": \"Temperature unit (Celsius only)\"\n        },\n        \"sensor_id\": {\n            \"type\": \"string\",\n                \"pattern\": \"^TEMP_LINE_[0-9]+$\",\n                    \"description\": \"Sensor identifier following the required naming convention\"\n        },\n        \"timestamp\": {\n            \"type\": \"string\",\n                \"format\": \"date-time\",\n                    \"description\": \"ISO 8601 formatted timestamp\"\n        }\n    },\n    \"additionalProperties\": false\n}","x":520,"y":420,"wires":[["ae110e07ad7685d7"],["df3cea6a5e793d66","30dce9e4816b95a9"]]},{"id":"73c2d99fc1d7025a","type":"telegram sender","z":"d7101f3a4d45deed","name":"","bot":"c588ce99d237a64a","haserroroutput":false,"outputs":1,"x":770,"y":560,"wires":[[]]},{"id":"30dce9e4816b95a9","type":"debug","z":"d7101f3a4d45deed","name":"Error","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":760,"y":440,"wires":[]},{"id":"c588ce99d237a64a","type":"telegram bot","botname":"Quality Check Bot","usernames":"","chatids":"","baseapiurl":"","testenvironment":false,"updatemode":"polling","pollinterval":300,"usesocks":false,"sockshost":"","socksprotocol":"socks5","socksport":6667,"socksusername":"anonymous","sockspassword":"","bothost":"","botpath":"","localbothost":"0.0.0.0","localbotport":8443,"publicbotport":8443,"privatekey":"","certificate":"","useselfsignedcertificate":false,"sslterminated":false,"verboselogging":false},{"id":"e1abd01699c129df","type":"global-config","env":[],"modules":{"node-red-contrib-full-msg-json-schema-validation":"1.1.0","node-red-contrib-telegrambot":"17.0.3"}}]
```
::

## Wrapping Up

You now have a working validator that stops corrupted data before it reaches your dashboards and automation logic. Bad sensor readings, malformed payloads, missing fields, your system catches them all and sends you detailed Telegram alerts the moment validation fails.

Pick one critical data source and deploy your validator there first. Watch how it performs, adjust your schema based on real patterns, then roll it out to additional sources. Apply this approach everywhere data enters your system, MQTT streams, API endpoints, PLC connections. You'll shift from constantly troubleshooting mysterious failures to preventing them entirely.

Pay attention to your validation metrics. High failure rates from specific sensors signal equipment problems. Recurring error patterns reveal network issues or configuration drift. Your validator becomes an early warning system for operational problems.

The validation patterns you build today make your automation trustworthy tomorrow.

Want to discover how FlowFuse helps you collect, validate, enrich, and use machine data to reduce costs and improve operational efficiency, along with powerful enterprise features? [Contact us](https://flowfuse.com/contact-us/) or [Book a demo](https://flowfuse.com/book-demo/) to get started.


# How to Optimize Industrial Data Communication with Protocol Buffers

You're generating terabytes of sensor data every day. Most of it is waste, I mean..

Not the measurements, those are fine. It's the packaging. Text formats wrap every reading in field names, quotes, and brackets. You're moving more formatting characters than actual data across your network.

Protocol Buffers eliminates this. It's binary serialization that transmits only what matters, no overhead, no bloat. This article shows you how to implement it and what happens when you stop paying to transmit garbage.

Don't worry about complexity, in FlowFuse this is three nodes and one text file. No thousand lines of code. You'll define your data structure in 5-10 lines, drag some nodes into your flow, point them at that file, and you're done. FlowFuse handles the rest.

## What You're Actually Transmitting

Your network doesn't have a data problem. It has a packaging problem.

Right now, somewhere in your facility, a sensor just reported 74°C. Simple reading. Four pieces of information. But here's what actually transmitted:

```json
{
  "sensor_id": "T-220",
  "temperature": 74,
  "unit": "C",
  "timestamp": 1700580000,
  "status": "OK"
}
```

See those field names? `sensor_id`, `temperature`, `unit`, `timestamp`, `status`. You wrote them once when you defined your data model. Now you're transmitting them thousands of times per second. Every single message carries a complete description of itself.

It's like receiving a package where the shipping label is bigger than what's inside.

**Here's what this costs you:**

One sensor sending 109 bytes every 5 seconds is nothing. One thousand sensors doing the same thing creates 21.8 KB/second of continuous traffic. That's 1.88 GB per day. Except only about 650 MB are actual measurement, the rest is field names, quotes, and brackets you're paying to transmit, store, and process.

Your edge device receives this message and fires up a JSON parser. It reads character by character, validates every quote matches, converts "74" from a string into a number, and builds a data structure. This happens millions of times per day in a mid-sized facility. The CPU isn't processing sensor data, it's processing text formatting.

Your control loop needs that temperature reading in 50 milliseconds. But the network is congested because it's moving 3-4x more data than necessary. The parser is slow because it's converting strings. And suddenly your 50ms requirement becomes 200ms, and nobody can figure out why because "we have plenty of bandwidth."

Meanwhile, your cloud provider charges by the gigabyte. Every month, you pay to ingest 1.88 GB from this sensor array. About 1.2 GB of that is field names and formatting. You're literally paying to store the word "temperature" millions of times.

**The compression trap:**

The obvious fix is GZIP. Compress everything, cut it in half, problem solved. Except now you're compressing garbage, then paying CPU cycles to decompress it, then parsing the same bloated JSON on the other end. You've added latency and processing overhead to save bandwidth on data you shouldn't be sending in the first place.

**What if you just didn't send it?**

Protocol Buffers doesn't compress your JSON. It replaces it. No field names in every message, they're defined once in a schema. No quotes or brackets, it's binary. No string-to-number conversions, numbers are already numbers.

That 109-byte JSON message becomes 47 bytes with Protocol Buffers. Not compressed. Just stripped of everything that isn't data, a 60% reduction in size.

The same sensor array that generated 1.88 GB per day now generates 750 MB. Your edge devices process messages in microseconds instead of milliseconds. Your control loops hit their timing requirements. And your cloud bill drops by 60%.

This isn't theoretical. It's measurable, repeatable, and you can implement it in an afternoon.

## Understanding Protocol Buffers

Before we dive into implementation, let's understand what makes Protocol Buffers different.

Protocol Buffers (protobuf) is a serialization format developed by Google. Unlike JSON, which describes data with every message, protobuf separates the schema from the data. You define your message structure once in a `.proto` file:

```protobuf
syntax = "proto3";

// Temperature sensor reading
message TemperatureSensorReading {
  string sensor_id = 1;
  float temperature = 2;
  string unit = 3;
  int64 timestamp = 4;
  string status = 5;
}
```

Those numbers (1, 2, 3, 4, 5) are field identifiers. When you encode a message, protobuf transmits only the field number and the value. No field names, no formatting characters, no whitespace.

**The binary difference:**

- JSON: `{"sensor_id":"T-220","temperature":74,...}` (109 bytes)
- Protobuf: `[21,0,0,74,66,26,7,99,101,108,11...` (47 bytes)

The receiver uses the same `.proto` file to decode field 1 as sensor\_id, field 2 as temperature, and so on. The schema exists once on each side, never in the message itself.

Now let's implement this in FlowFuse.

## Implementing Protocol Buffers in FlowFuse

We'll build a complete protobuf pipeline: define your data schema, encode sensor readings, transmit them, and decode on the receiving end.

> Before you start, Make sure you have a FlowFuse instance running on your edge device. If you don't have an account yet, [create one with our free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}. FlowFuse simplifies connecting devices and systems, transform, validate, contextualize, and visualize data while building industrial applications, all in a low-code environment. It includes enterprise features that accelerate management, development, deployment, and scaling with built-in security.

### Preparing Your Protocol Buffers Schema

Let's start by defining your data structure. This will be the foundation of your binary serialization. If you're using FlowFuse Device Agent to run your Node-RED instance, it's recommended to create this file inside the `/opt/flowfuse-device/` directory for proper access and management.

Create a file named `temperature-sensor.proto` ( or you can give it any name you want ). Make sure it ends with the `.proto` extension:

```protobuf
syntax = "proto3";

message TemperatureSensorReading {
  string sensor_id = 1;
  float temperature = 2;
  string unit = 3;
  int64 timestamp = 4;
  string status = 5;
}
```

You can define as many message types as you need for different data in the file. Each message type gets its own structure optimized for the specific data it carries.

### Installing the Protocol Buffers Node

To work with Protocol Buffers in FlowFuse, you'll need the protobuf node:

1. In your FlowFuse instance, open the palette manager (Menu → Manage palette)
2. Search for `node-red-contrib-protobuf`
3. Install the node

Once installed you will see the nodes in the left palette under the protobuf category.

### Encoding Data with Protocol Buffers

1. Drag your data source node (Modbus Read, OPC UA Client, S7, etc.) into the flow. Ensure it's configured correctly and that data is coming through, you can verify this using a Debug node.
2. Transform the data as needed and add any required metadata.
3. Add the **Encode*&#x2A; node to the flow. Open its configuration and click the &#x2A;*+** icon next to **Protofile** to add the full path to your `.proto` file.
   - Enable **Watch file** if you want the node to automatically reload when the `.proto` changes
   - Enable &#x2A;*Keep snake\_case (underscores)** if your field names require it

![Protocol Buffers node configuration](https://flowfuse.com/blog/2025/11/images/encode-config.png){dataZoomable=""}*Protocol Buffers node configuration*

4. Specify the **Message Type** as defined in your `.proto` file. For example, using the schema shown earlier, the type would be:

```text
TemperatureSensorReading
```

This tells the Encode node which message structure to apply during serialization.

If you need to set the type dynamically, you can also do:

```js
msg.protobufType = "TemperatureSensorReading";
```

5. Finally, connect the **Encode** node to the communication node (or to the node that is transforming data and adding metadata) that will send your data onward, for example, MQTT Out, HTTP Request, or any other transport you're using.
6. Deploy the flow.

Once data passes through the Encode node, it will automatically encode it into Protocol Buffers. When everything is working correctly, you'll see the node status update to "processed" with a green indicator.

### Decoding Protocol Buffers Data

Now that you're encoding and transmitting binary data, you need to decode it on the receiving end. This is where the matching `.proto` schema comes into play.

On your receiving FlowFuse instance (or wherever you're processing the data):

1. Copy the same `.proto` file to your receiving system. The schema must match exactly, same field numbers, same types, same message structure. This is critical for successful decoding.
2. Add the Decode node to your flow where you receive the protobuf data (after MQTT In, HTTP In, etc.)
3. Configure the Decode node by Clicking the + icon next to Protofile and enter the full path to your `.proto` file. Set the Message Type to match what was encoded (e.g., `TemperatureSensorReading`). Enable Watch file if you want automatic reloading on schema changes.
4. Connect Protocol buffer data source to Decode node.
5. Deploy the flow.

The Decode node will parse the binary message and output a standard JavaScript object that you can work with in function nodes, store in databases, or display in dashboards.

## What You Actually Get

Let's talk about what changes when you actually implement this.

Your network traffic drops by half or more. That struggling edge gateway suddenly has headroom. You can add more data sources or increase message frequency without upgrading anything.

Your edge devices aren't parsing text anymore. Messages that took milliseconds now decode in microseconds. Those freed CPU cycles go back to your actual application logic. Your processing loops hit their timing requirements again.

Your time-series database just got considerably smaller. The storage you already paid for goes further. That retention policy you've been managing? You just extended it without buying anything.

Your cloud provider charges per gigabyte. You were paying to transmit and store field names with every reading. Whatever your current cloud bill is, expect it to drop by 40-60%. Your provider doesn't care why, they just bill you for what moved through their infrastructure.

Before Protocol Buffers, scaling meant budgeting for more capacity. After implementation, the same infrastructure handles more without additional spend. That next tier pricing? You just pushed it out by years.

You're not rebuilding anything. Define a `.proto` schema, drop in encode/decode nodes, deploy. No consultants, no multi-phase rollout, no capital purchases.

This isn't optimization theater. It's removing waste that never should have been there. And once implemented, every new data source, every increased message rate, every additional field benefits from the same reduction. You're not just cutting your bill once, you're changing the cost structure of every future expansion.

## Cut the Waste Now

Your messages are 60% packaging. Protocol Buffers strips it out.

One schema file. Three nodes in FlowFuse. Deploy. Done.

The same platform you use to connect devices, systems and build dashboards now optimizes every byte you transmit. No new tools. No complexity. Just smaller messages and lower bills.

Pick one data flow. Implement it this afternoon. Scale it tomorrow.

[Start your free FlowFuse trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and stop paying to transmit field names.


# The Industrial IoT Market Shift: What the PTC Divestment Means for Your Data Strategy

The news of PTC selling Kepware and ThingWorx to TPG for $600 million has caused a significant impact across the industrial automation sector. For anyone working in manufacturing, OT data integration, or industrial IoT, this divestment raises important questions about the future direction of these widely-used platforms, and what it means for organizations relying on them.

But here's the thing: this isn't an isolated event. Back in July 2024, there were rumors that Autodesk might acquire PTC for $20+ billion. Those talks ultimately fell through when Autodesk walked away from the deal. Now, just months later, PTC has decided to divest two of its major industrial IoT assets. The pattern is clear: PTC is refocusing its strategy.

## A Strategic Realignment, Not a Surprise

PTC has been under strategic pressure for some time. The company operates across multiple domains: CAD and PLM (with Creo and Windchill), Application Lifecycle Management (ALM) with Codebeamer, and Industrial IoT with Kepware and ThingWorx. While this portfolio diversity has value, it also creates complexity, and when Autodesk considered acquiring PTC earlier this year, that complexity likely played a role in their decision to walk away.

Now, PTC is taking action on its own. By divesting Kepware and ThingWorx to TPG, the company is narrowing its focus to what it calls its "Intelligent Product Lifecycle" vision, concentrating on CAD, PLM, ALM, SLM (Service Lifecycle Management), and the integration of AI and SaaS across these core areas.

For PTC, this makes sense. Kepware and ThingWorx solve different problems than the rest of their portfolio. They're about OT data connectivity and IIoT application development (areas that don't naturally integrate with product design and lifecycle management). By selling these assets to TPG, PTC can focus resources on its core business while TPG invests in growing the connectivity and IoT platforms.

But for customers, this introduces uncertainty: What does life under TPG ownership look like?

## The Customer Reality: Uncertainty and Opportunity

For organizations using Kepware or ThingWorx, this transition will bring uncertainty. Product roadmaps may shift. Pricing structures could change. Integration strategies may no longer make sense in the same way. Even if TPG commits to investing in these platforms, the reality is that customers are now operating in a period of transition (and transitions often, if not always, bring risk).

This is precisely why, back in July when the Autodesk acquisition rumors started, we launched our migration landing page at flowfuse.com/vs/kepware. To leave things clear. To make a clear statement. We saw what was coming. Organizations that had built their OT data strategies on these platforms would soon be re-evaluating their options. And for many, this is the perfect moment to ask a more fundamental question: what should a modern industrial data integration platform actually look like?

## The Open-Source Alternative: Built by Node-RED's Founder

At FlowFuse, we take a fundamentally different approach to industrial data integration. We're not a closed, proprietary platform tied to a single vendor's roadmap or business priorities. Instead, we're built on Node-RED, the truly open-source, low-code programming tool created by Nick O'Leary, who is also the founder of FlowFuse.

This isn't just a technical detail but it's a strategic advantage. Here's why:

FlowFuse vs. Kepware: A Clear Comparison

For organizations evaluating their options, the differences between FlowFuse and traditional platforms like Kepware become clear when you compare them side by side:

- Open-source foundation: FlowFuse is built on Node-RED and the open-source ecosystem, giving you full transparency and control. Kepware, by contrast, is a proprietary stack with limited visibility into how it works.
- Zero vendor lock-in: With FlowFuse, your flows are portable. You can run them anywhere (cloud, on-premises, or at the edge). Kepware ties you to their licensing model and roadmap.
- Integration flexibility: Node-RED's 5,000+ community-contributed nodes mean you can connect to virtually anything (MQTT, OPC-UA, REST APIs, SQL databases, cloud services, and more). Kepware's integrations are often limited to proprietary or custom connectors.
- Transparent pricing: FlowFuse offers use-based, transparent pricing that scales with your needs. Kepware's licensing model is tiered, often creating cost barriers as you grow.
- Active community: Node-RED has one of the largest and most active open-source communities in industrial automation. You're not dependent on a single vendor for support, innovation, or problem-solving. Kepware operates in a closed ecosystem.
- Future-proof architecture: FlowFuse is cloud-ready, portable, and designed to evolve with your infrastructure. After multiple ownership transitions, Kepware's future direction under TPG remains uncertain.

You can explore these differences in detail at [flowfuse.com/vs/kepware](https://flowfuse.com/vs/kepware/).

## Connect to Anything, Collect Everything

Node-RED has over 5,000 community-contributed nodes, covering virtually every industrial protocol, database, cloud service, and API you can imagine. Whether you need to pull data from a Siemens S7 PLC, a Modbus device, an OPC UA server, push it to AWS IoT Core, Azure, or your own database, transform it in real-time, and visualize it on a custom dashboard. Node-RED can do it all.

And because it's open source, if a connector doesn't exist, you or the community can build it. This level of connectivity is unmatched. Kepware is powerful for protocol translation, sure, but it's primarily focused on moving data from OT systems to IT systems. Node-RED, by contrast, is a full data orchestration platform. You're not just collecting data, you're transforming, routing, analyzing, and acting on it, all in one place.

### No Vendor Lock-In, Ever

With proprietary platforms, your data integration strategy is tied to the vendor's business decisions. Pricing changes? You adapt. Features deprecated? You work around it. Company gets acquired? You hope for the best.

With Node-RED and FlowFuse, you're in control. The core technology is open source, maintained by a thriving global community. FlowFuse adds the enterprise-grade management, security, and scalability that industrial organizations need, but you're never locked in. If you ever decide FlowFuse isn't the right fit, your Node-RED flows are yours to take and run elsewhere. That's the power of true open source.

### Enterprise-Ready from Day One

One of the challenges with open-source tools is that they often require significant effort to operationalize at scale. That's where FlowFuse comes in. We provide:

- Centralized management of Node-RED instances across multiple sites and edge devices
- DevOps-ready workflows with version control, CI/CD integration, and team collaboration features
- Enterprise security with role-based access control, audit logs, and compliance-ready deployment options
- Scalability to manage thousands of edge devices or cloud-based instances from a single platform

In short, FlowFuse gives you the flexibility and openness of Node-RED with the operational rigor that enterprise IT and OT teams require.

To learn more take a quick look at this video and learn about these 5 reasons you should migrate to FlowFuse. <https://youtu.be/fUqfA521Iqg>{rel="&#x22;nofollow&#x22;"}

## Simple, Visual, and Incredibly Powerful

Node-RED's low-code, visual programming interface makes it accessible to engineers who aren't developers, while still being powerful enough for complex industrial applications. You wire together nodes to create data flows, connecting sources, transforming data, triggering actions, and building dashboards. It's intuitive, fast to prototype, and easy to maintain.

This means faster time-to-value. Instead of waiting months for vendor implementations or custom development, your team can build and deploy solutions in days or weeks. And because everything is visual, it's easier to document, troubleshoot, and hand off to other team members.

## What This Means for You

If you're currently using Kepware or ThingWorx, this transaction isn't necessarily bad news. TPG may very well invest in these platforms and accelerate their development. But it's also a reminder of a fundamental truth in enterprise software: when you build on proprietary platforms, you are always subject to the strategic priorities of the company that owns them.

This is a good time to ask some strategic questions:

- Is your data integration platform aligned with your long-term strategy?Or are you constantly adapting to vendor-driven changes?
- Can you extend and customize your platform to meet your unique needs? Or are you constrained by what the vendor offers?
- Do you have flexibility in how and where you deploy? Cloud, on-premises, edge, hybrid, can your platform handle all of these?
- What happens if your vendor’s priorities shift again? Are you prepared for another transition?

For organizations re-evaluating their options, open-source platforms like Node-RED and FlowFuse offer a compelling alternative. You get the connectivity, flexibility, and control to build exactly the data strategy you need, without being tied to a single vendor’s roadmap or business model.

## The Path Forward

The industrial automation market is evolving rapidly. As companies like PTC realign their portfolios, the organizations that thrive will be the ones that build on flexible, future-proof foundations.

At FlowFuse, we believe that foundation is open source. It's why we've built our platform on Node-RED, created by our founder Nick O'Leary. And it's why we're committed to giving industrial organizations the tools they need to take control of their data strategies, with the flexibility to adapt, the power to innovate, and the freedom to choose their own path.

## Ready to Explore Your Options?

If you're evaluating your options, whether you're currently on Kepware, ThingWorx, or another platform, [we'd love to talk](https://flowfuse.com/book-demo/).

See [how we stack up against Kepware](https://flowfuse.com/vs/kepware/) to learn more about how FlowFuse compares to traditional industrial connectivity platforms, or [contact our team](https://flowfuse.com/contact-us/) to speak with one of our Migration Experts. We can help you understand your options, plan a migration strategy, and show you how open-source industrial data integration can transform your operations.

The industrial IoT market is shifting. Make sure your data strategy is built to adapt.


# Store-and-Forward at the Edge: Buffering Production Data During Network Outages

Network outages happen. A fiber cut, a switch failure, or infrastructure maintenance can take your connectivity offline without warning. When it does, your PLCs continue operating normally, they don't wait for the network to recover.

The problem is that all the data they generate during that outage has nowhere to go. Production metrics, quality measurements, and alarm events accumulate with no path to your historian or cloud platform. When connectivity returns, you're left with gaps in your operational records. Those gaps create real problems: incomplete batch records for quality audits, missing data for troubleshooting production issues, and compliance documentation that doesn't hold up under review.

Store-and-forward solves this. This article walks through building a store-and-forward system with FlowFuse that maintains complete data continuity during network failures.

Below is the demo video where I show how production data can be lost without buffering, and how buffering prevents that from happening.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: YouTube video player
videoid: J1gDj6S-ijI
---
::

## What is Store-and-Forward?

Store-and-forward is a pattern where data is saved locally before transmission, then forwarded when network connectivity is available. Your edge device writes every data point to local SQLite storage first. If the network is up, the data transmits to your destination, MQTT broker, historian, cloud platform, or database. If the network is down, the data stays in storage until connectivity returns.

The edge device operates in three states. During normal operation, data writes to the buffer and forwards successfully, the buffer stays near-empty. During a network outage, data continues writing to the buffer but cannot forward, the buffer grows. When connectivity returns, the device forwards the buffered backlog in chronological order while continuing to collect new data, the buffer drains back to empty.

```mermaid
flowchart TD
    Source[PLC / Sensor]
    Destination[Cloud / Broker / Server]

    Source --> Start[Data Arrives at Edge]
    Start --> Save[Store in Local Buffer]
    Save --> Check{Network Available?}

    Check -->|Connected| Send[Send Data]
    Send --> Destination
    Destination --> Clear[Remove Data from Buffer]

    Check -->|Disconnected| Wait[Keep Data in Buffer]
    Wait --> Retry[Retry Until Network Restored]
    Retry --> Check

    %% Styling (consistent theme)
    style Source fill:#3B82F6,color:#fff
    style Start fill:#3B82F6,color:#fff
    style Save fill:#818CF8,color:#fff
    style Check fill:#6366F1,color:#fff
    style Send fill:#60A5FA,color:#fff
    style Destination fill:#60A5FA,color:#fff
    style Clear fill:#93C5FD,color:#000
    style Wait fill:#A5B4FC,color:#fff
    style Retry fill:#BFDBFE,color:#000
```

This solves the core problem in industrial data collection: network failures creating gaps in your time-series data. A four-hour outage would normally mean four hours of missing production data. With store-and-forward, that same outage causes zero data loss. Your destination system receives complete chronological data with only a delivery delay.

## Getting Started

Let's build a store-and-forward system to protect your data during network outages.

We'll approach this in six steps: establish a connection to collect data, set up a local buffer to temporarily store that data, write incoming data to the buffer, monitor network connectivity status, create forwarding logic to transmit buffered data when connectivity returns, and finally add error handling and buffer management to ensure reliable operation.

### Prerequisites

You'll need the following before implementing store-and-forward:

- **Edge Device Running FlowFuse Agent**: A running FlowFuse instance deployed on your edge hardware or gateway device.
- **node-red-node-sqlite**: SQLite node for local data storage.
- **node-red-contrib-ping**: Ping node for connectivity monitoring.

### Step 1: Set Up Data Collection

Data collection is the foundation of store-and-forward. Your edge device needs reliable connectivity to your data sources before you can buffer and forward their data.

FlowFuse handles this through Node-RED's 5,000+ community nodes, which support virtually every industrial protocol and interface, Modbus, OPC UA, MQTT, Ethernet/IP, GPIO pins, serial connections, and more. You collect data from your sources, transform it into the format you need, and prepare it for buffering.

For this guide, we'll assume you already have data flowing into FlowFuse. The store-and-forward pattern works the same regardless of which data sources or protocols you're using.

For more information on how FlowFuse can help you connect, collect, transform, and contextualize your data, and how it simplifies deployment, management, scaling, and security with enterprise features for production environments, [book a demo](https://flowfuse.com/book-demo/).

### Step 2: Implement SQLite Buffering

SQLite provides the persistent storage layer for your store-and-forward buffer. It's lightweight, requires no separate database server, and handles the write volumes typical of industrial data collection without issue.

Follow these steps to set up your SQLite buffer:

1. Drag the **sqlite** node from the palette onto your workspace.
2. Double-click the node to open its configuration panel. Click the pencil icon next to the Database field to create a new database configuration. Give it a name like **sqlite**, select **Read-write-create** as the mode, and click **Add** to save the configuration.

![SQLite database configuration with read-write-create mode enabled](https://flowfuse.com/blog/2025/11/images/sqlite-config.png){dataZoomable=""}*SQLite database configuration with read-write-create mode enabled*

3. Set the SQL Query mode to **Fixed Statement**. In the SQL Query field, enter:

```sql
CREATE TABLE IF NOT EXISTS data_buffer (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp INTEGER NOT NULL,
    sent INTEGER DEFAULT 0,
    payload TEXT,
    created_at INTEGER DEFAULT (strftime('%s','now') * 1000)
);
```

The payload stores the serialized data as JSON. The `sent` flag indicates whether the record is still pending (0) or has been successfully delivered (1), this acts as a safety marker to prevent cleanup of unsent data.

1. Connect an **Inject** node to **Sqlite** node
2. Deploy your flow and click the inject node button to create the table.

Your SQLite buffer is now ready to store data during network outages. The next step implements the logic to write incoming data to this buffer.

### Step 3: Store Incoming Data in Buffer

With your SQLite buffer ready, implement the logic to write incoming PLC data to storage.

1. Drag a **JSON** node onto the canvas and connect it to your data input source.
2. Double-click the node to open its configuration. Set the Action to `Always convert to JSON String` and set the Property to `msg.payload`, then click **Done** to save.

> **Note**: JSON converts your data object into a text string for storage. If your data source already provides a JSON string (not an object), you must delete this node.

![JSON node configured to stringify payload data for storage](https://flowfuse.com/blog/2025/11/images/stringify-json.png){dataZoomable=""}*JSON node configured to stringify payload data for storage*

3. Drag a **Change** node onto the canvas and connect it to the **JSON** node.
4. Double-click the **Change** node to configure it. Add the following rules:
   - **Rule 1**: Set `msg.params` to `{}` (JSONata expression)
   - **Rule 2**: Set `msg.params.$ts` to `msg.timestamp`
   - **Rule 3**: Set `msg.params.$payload` to `msg.payload`

![Change node rules for preparing SQLite insert parameters](https://flowfuse.com/blog/2025/11/images/set-params-step-3.png){dataZoomable=""}*Change node rules for preparing SQLite insert parameters*

5. Drag another **Sqlite** node onto the canvas and connect it to the **Change** node.
6. Double-click the node to configure it. Select your existing **Sqlite** database, set the SQL Query mode to `Prepared Statement`, and in the SQL Query field, enter:

```sql
INSERT INTO data_buffer (timestamp, payload, sent)
VALUES ($ts, $payload, 0);
```

7. Click **Done** to save the configuration and deploy your flow.

Your buffer now accumulates all incoming data. Each data point is serialized to JSON, structured into parameters, and written to SQLite with `sent=0` (not yet forwarded). The prepared statement approach prevents SQL injection issues and handles special characters correctly.

### Step 4: Monitor Network Connectivity

Network connectivity monitoring determines when your system can forward buffered data. The ping node checks connectivity to your destination system, and when the network is available, it triggers the forwarding process.

Follow these steps to implement connectivity monitoring:

1. Drag a **Ping** node onto the canvas.
2. Double-click the node to configure it. Enter the IP address or hostname of your destination system in the Target field (e.g., `broker.flowfuse.cloud`), select mode to "Automatic", set "Ping every" to `30` seconds (adjust based on your requirements), name it "Network Health Check", and click **Done** to save.

![Ping node configured to monitor network connectivity every 30 seconds](https://flowfuse.com/blog/2025/11/images/ping.png){dataZoomable=""}*Ping node configured to monitor network connectivity every 30 seconds*

3. Drag a **Switch** node onto the canvas and connect it to the **Ping** node.
4. Double-click the **Switch** node to configure it. Set the Property to `msg.payload`,
   - add Rule 1 as `false` (network is down),
   - add Rule 2 as `otherwise` (network is reachable).

![Switch node routing messages based on network connectivity status](https://flowfuse.com/blog/2025/11/images/if-connected-to-internet.png){dataZoomable=""}*Switch node routing messages based on network connectivity status*

5. Click **Done** to save.

The switch node routes messages based on ping results. When ping fails, `msg.payload` is `false`. Otherwise, the ping succeeded with a response time.

6. Drag two **change** nodes onto the canvas. Connect the first one to output 1 of the switch node (network down), and the second one to output 2 (network reachable).
7. Double-click the first change node to configure it:
   - **Rule 1**: Set `flow.networkOnline` to `false` (boolean) ( make sure it is stored in the persistent storage )
   - Name it "Set Network Offline"
   - Click **Done** to save.

![Change node setting network offline flag in persistent storage](https://flowfuse.com/blog/2025/11/images/set-network-offline.png){dataZoomable=""}*Change node setting network offline flag in persistent storage*

8. Double-click the second change node to configure it:
   - **Rule 1**: Set `flow.networkOnline` to `true` (boolean)
   - Name it "Set Network Online"
   - Click **Done** to save.

![Change node setting network online flag when connectivity is restored](https://flowfuse.com/blog/2025/11/images/set-network-online.png){dataZoomable=""}*Change node setting network online flag when connectivity is restored*

9. Drag another **change**node onto the canvas and configure it:
   - **Rule 1**: Set `flow.flowError` to **false** (this resets the error state triggered in the [Handle Errors and Disconnections](https://flowfuse.com/#handle-errors-and-disconnections) section).

![Change node resetting error state when network becomes available](https://flowfuse.com/blog/2025/11/images/flow-error.png){dataZoomable=""}*Change node resetting error state when network becomes available*

10. Drag a **Link Out** node onto the canvas and connect it to the "Set Network Online" node. Name it "Trigger Forward".

Your connectivity monitoring is now complete. When the network is available, the system will trigger the forwarding logic to send buffered data.

### Step 5: Build the Forwarding Logic

The forwarding logic retrieves unsent data from the buffer, prepares it for transmission, and sends it to the destination. This section shows how to build a forwarding system that processes buffered data in batches.

#### Retrieve and Prepare Unsent Records

1. Drag a **Link In** node onto the canvas and name it "Trigger Forward". Link this to the **Link Out** node from Step 4.
2. Drag an **SQLite** node onto the canvas and connect it to the **Link In** node. Name it "Get Unsent Data" and configure it by selecting your database, setting SQL Query mode to **Fixed statement**, and entering the following SQL:

```sql
   SELECT * FROM data_buffer 
   WHERE sent = 0 
   ORDER BY timestamp ASC 
   LIMIT 50;
```

3. Click **Done** to save.
4. Drag a **Split** node onto the canvas and connect it to the SQLite node. Configure it to split **msg.payload** and click **Done**.
5. Drag a **Change** node onto the canvas and connect it to the **Split** node. Name it "Prepare Forward Message" and add the following rules:
   - **Rule 1**: Set `msg.record_id` to `msg.payload.id`
   - **Rule 2**: Set `msg.payload` to `msg.payload.payload`

![Change node extracting record ID and payload for forwarding](https://flowfuse.com/blog/2025/11/images/prepare-forward-msg.png){dataZoomable=""}*Change node extracting record ID and payload for forwarding*

6. Click **Done** to save.
7. Drag a **JSON** node onto the canvas and connect it to the **Change** node. Configure it by setting Action to **Always Convert to JSON Object** and Property to `msg.payload`, then click **Done**.

![JSON node configured to parse stored JSON string back to object](https://flowfuse.com/blog/2025/11/images/parse-json.png){dataZoomable=""}*JSON node configured to parse stored JSON string back to object*

8. Click **Done** to save.
9. Drag a **Link Out** node onto the canvas and connect it to the **JSON** node. Name it "Send to Destination".

Your forwarding logic now retrieves unsent records, prepares them for transmission, and passes them to the next stage for sending.

### Step 6: Send Data and Handle Errors

This step implements data transmission to your destination with comprehensive error handling and buffer management.

#### Send Data to Destination

1. Drag a **Link In** node onto the canvas and link it to the **Link Out** node from Step 5. Name it "Send to Destination".
2. Drag a **Switch** node onto the canvas and connect it to the **Link In** node. Name it "Check Network Online", set the Property to `flow.networkOnline`, add a condition `is true`, and click **Done** to save.

![Switch node verifying network connectivity before sending data](https://flowfuse.com/blog/2025/11/images/is-network-online.png){dataZoomable=""}*Switch node verifying network connectivity before sending data*

3. Drag another **Switch** node onto the canvas and connect it to the first switch node's output. Name it "Check Flow Error", set the Property to `flow.flowError`, add a condition `is false`, and click **Done** to save.

![Switch node checking for error-free state before transmission](https://flowfuse.com/blog/2025/11/images/if-no-error.png){dataZoomable=""}*Switch node checking for error-free state before transmission*

4. Drag a **Change**node onto the canvas and connect it to the second switch node's output. Configure it to append the record ID into the payload for transmission confirmation:
   - Rule 1: Set `msg.record_id` to `msg.payload.record_id`

![Change node preserving record ID for transmission confirmation](https://flowfuse.com/blog/2025/11/images/add-record-id-to-payload.png){dataZoomable=""}*Change node preserving record ID for transmission confirmation*

5. Drag a **Project Out** node onto the canvas and connect it to the **Change** node. Double-click the node to open its configuration. Select "Send to specified node" as the mode, then enter select target "broadcast message" and enter topic (for example: `acme_manufacturing/plant_01/floor_2/cell_a/machine_A12/measurements`). Click **Done** to save the configuration.

> **Note:** you can use any output node that suits your architecture instead of Project Out, such as **MQTT Out** for publishing to MQTT brokers, **HTTP Request** for sending data to REST APIs, **Database** nodes for writing directly to databases or other protocol-specific nodes depending on your destination requirements.

6. Deploy the flow.

#### Mark Records as Sent and Clear Buffer

1. Drag a **Project In** node onto the canvas, double-click the node to configure it with source set to "Listen for broadcast messages", and configure it to listen on all instances and devices with the topic that should match the same topic you configured in the Project Out node earlier to subscribe to your data that was sent before.

> **Note:** The Project In node is used here to confirm successful transmission when using Project Out nodes. If you are using other output nodes such as MQTT Out, HTTP Request, or database nodes, replace the Project In node with the corresponding confirmation mechanism for your chosen protocol. For example, if your output node such as HTTP Request responds with a status code or success message, you can use that response directly for confirmation instead of the Project In node.

2. Drag a **Change** node onto the canvas and connect it to the **Project In**node. Name it "Prepare Record ID" and configure the following rules:
   - **Rule 1**: Set `msg.params` to `{}` (JSONata expression: `{}`)
   - **Rule 2**: Set `msg.params.$record_id` to `msg.record_id`

![Change node preparing parameters for marking record as sent](https://flowfuse.com/blog/2025/11/images/set-params-step-5.png){dataZoomable=""}*Change node preparing parameters for marking record as sent*

3. Click **Done** to save.
4. Drag an **SQLite** node onto the canvas and connect it to the **Change** node. Name it "Mark as Sent", then double-click it to configure. Select your database, set SQL Query mode to **Prepared Statement**, and enter the following SQL:

```sql
   UPDATE data_buffer 
   SET sent = 1 
   WHERE id = $record_id;
```

5. Click **Done** to save.
6. Drag another **SQLite** node onto the canvas and connect it to the previous SQLite node. Name it "Delete Record", then double-click it to configure. Select database, set SQL Query mode to **Prepared Statement**, and enter the following SQL:

```sql
   DELETE FROM data_buffer
   WHERE id = $record_id
   AND sent = 1;
```

7. Click **Done** to save and deploy the flow.

#### Handle Errors and Disconnections

1. Drag a **Catch** node onto the canvas. Configure it to catch errors from all nodes.
2. Drag a **Change** node onto the canvas and connect it to the **Catch** node.
3. Name it "Set Flow Error" and configure it:
   - **Rule 1**: Set `flow.flowError` to `true` (boolean)

![Change node setting error flag when transmission fails](https://flowfuse.com/blog/2025/11/images/set-flow-error-flag.png){dataZoomable=""}*Change node setting error flag when transmission fails*

4. Click **Done** to save.
5. Drag a **Status** node onto the canvas and configure it to monitor the **Project** node's status.
6. Drag a **Switch** node onto the canvas and connect it to the status node.
7. Name it "Check Disconnected", set the Property to `msg.status.text`, add a condition `==` with value `disconnected`, and click **Done** to save.
8. Drag a **Change** node onto the canvas and connect it to the **Switch** node.
9. Name it "Set Network Failure Flag" and configure it:
   - **Rule 1**: Set `flow.networkOnline` to `false` (boolean)
10. Click **Done** to save and deploy your flow.

## Conclusion

You now have a working store-and-forward system that protects your data during network failures.

When the network is up, data flows through the buffer and transmits immediately. When the network goes down, data accumulates in SQLite. When connectivity returns, the buffered data forwards automatically while new data continues collecting. No data is lost, regardless of how long the outage lasts.

This pattern solves a common problem in industrial environments: maintaining complete time-series data when network infrastructure fails. Your production systems can now operate independently of network reliability.

The system you've built is production-ready as-is, but you can extend it based on your requirements, add monitoring for buffer capacity, implement data validation rules, or configure forwarding to multiple destinations. The core mechanism remains the same.

If you want to get the flow template that you can use directly and modify according to your needs, check out our [latest blueprint](https://flowfuse.com/blueprints/getting-started/store-and-forward/).

Store-and-forward is just one part of a complete PLC integration. For the full picture, connecting Siemens, Allen-Bradley, Omron, and other PLCs to MQTT, cloud, and enterprise systems, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).


# 5 Whys Root Cause Analysis: Steps, Template & Example

The 5 Whys is a root cause analysis technique where you ask "why" repeatedly, typically five times, until you identify the underlying systemic cause instead of just symptoms.

Your equipment fails on Tuesday. The maintenance team fixes it. It fails again on Friday. Three weeks later, same failure. This cycle continues because everyone treats the symptom, the broken part, instead of asking why it broke.

The 5 Whys breaks this pattern. Developed by Sakichi Toyoda at Toyota in the 1930s, it's the standard root cause analysis method across manufacturing, healthcare, and software development. Systematic questioning strips away symptoms to expose the process gaps, training deficiencies, and procedural weaknesses that let problems persist. Applied correctly, it takes under an hour.

## What Is the 5 Whys Root Cause Analysis Method?

The 5 Whys is a questioning technique: ask "why" a problem occurred, ask "why" that condition existed, and keep going until you hit something fixable at a systemic level, not just a symptom.

The technique is deceptively simple. Start with a specific problem, ask why it happened, then take that answer and ask why again. Keep going until asking "why" one more time would just be splitting hairs. That usually takes about five iterations, hence the name, but effective analyses sometimes stop at three and others run to eight.

## Why the 5 Whys Works When Other Methods Don't

Organizations often spend weeks on elaborate root cause analyses using [fault trees](https://en.wikipedia.org/wiki/Fault_tree_analysis){rel="&#x22;nofollow&#x22;"}, [fishbone diagrams](https://flowfuse.com/blog/2026/07/ishikawa-fishbone-diagram/), and [statistical process control charts](https://flowfuse.com/blog/2025/07/quality-control-automation-spc-charts), only to implement solutions that don't stick. The 5 Whys succeeds where these often fail, for three reasons.

It's fast: a thorough analysis takes under an hour, while problems are still fresh and evidence hasn't been cleaned up. It's accessible: the operator who saw the problem doesn't need statistical training, just honest answers about what they observed. And it forces a single causal chain all the way down, instead of the analysis-paralysis that comes from mapping every possible contributing factor at once. You can always circle back and explore alternatives if your first path doesn't hold up.

:cta-image{alt="Arch Systems scales automation across complex manufacturing environments with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/arch-systems-book-demo.png"}

## The 5 Whys Checklist: What You Need Before You Start

Most failed 5 Whys sessions fail before they even begin because people skip the setup. You need four things in place before you ask the first question:

- **A specific problem statement.** "Quality issues in Department B" won't work. "Thirty-seven units failed final inspection on December 18th due to incomplete welds" will. Specificity disciplines your thinking and keeps the analysis focused.
- **The right people.** That means at least one person who directly observed or experienced the problem, someone who understands the process well enough to spot abnormal conditions, and a facilitator who can keep the questions moving forward. Three to five people is ideal. More than that and you'll spend more time managing the discussion than conducting the analysis.
- **Location at the gemba.** Conduct the analysis close to where the problem occurred. This principle, which Toyota calls [gemba](https://en.wikipedia.org/wiki/Gemba){rel="&#x22;nofollow&#x22;"}, matters more than most people realize. Conference rooms encourage abstract thinking. The shop floor, the customer service desk, or the server room keeps everyone grounded in physical reality. You can point at things. You can test hypotheses on the spot.
- **Commitment to honest answers.** If the real reason your new hires keep making mistakes is that your training program is inadequate, you need people willing to say that out loud. If your preventive maintenance schedule was designed fifteen years ago and never updated, someone needs to acknowledge it. The Five Whys only works if people tell the truth about what they see.

## 5 Whys Template: How to Complete the Analysis

The mechanics are straightforward, but execution requires more care than most people expect.

![Five Whys funnel diagram from problem to root cause](https://flowfuse.com/blog/2025/12/images/5-Why-Funnel.jpg)*Five Whys funnel diagram from problem to root cause*

Use this simple template to run the analysis, filling in each line with a verified fact, not a guess:

- **Problem:** What happened, where, when, and how you know it. ("Line 3 produced 847 units against a target of 1,000 during first shift on Dec 20th," not "production was slow.")
- **Why 1:** Why did this specific problem occur?
- **Why 2:** Why did *that* condition exist?
- **Why 3–5 (as needed):** Keep asking why of the previous answer.
- **Root cause:** The systemic gap you can actually fix.
- **Corrective action:** The specific fix, owner, and deadline.

Each answer should be something you can verify: a physical observation, sensor data, a log, or direct testimony, not speculation. "Probably the operator forgot" isn't an answer; "the feed line was clogged, confirmed by checking oil flow" is. Stop once you reach a process failure or systemic gap you can fix with a clear corrective action, revising a maintenance procedure or adding a training step, rather than "operator error" or "equipment failure," which are symptoms, not causes.

The number of whys is a guideline, not a rule. Some analyses reach the root cause in three questions; others need eight. What matters is reaching something you can actually fix.

## When to Use the 5 Whys (and When Not To)

The 5 Whys is most effective for problems with one dominant causal chain: equipment failures, quality defects, process bottlenecks, safety incidents, and customer complaints. Ask it here and you'll typically reach the fix quickly.

It's less effective for complex problems with multiple simultaneous, interacting causes, like a major product recall spanning design, materials, and distribution, where fishbone or fault tree analysis lets you map several pathways at once. It also struggles with deep organizational or cultural roots: if people don't report problems for fear of retaliation, asking "why" five times might surface that fact, but fixing it needs change management, not a questioning technique.

## The Toyota Origin of the 5 Whys

[Sakichi Toyoda](https://en.wikipedia.org/wiki/Sakichi_Toyoda){rel="&#x22;nofollow&#x22;"} developed the 5 Whys in the 1930s as part of what became the [Toyota Production System](https://en.wikipedia.org/wiki/Toyota_Production_System){rel="&#x22;nofollow&#x22;"}, insisting that problems were symptoms of deeper issues that could be identified and eliminated rather than accepted as inevitable. His son [Kiichiro Toyoda](https://en.wikipedia.org/wiki/Kiichiro_Toyoda){rel="&#x22;nofollow&#x22;"} and engineer [Taiichi Ohno](https://en.wikipedia.org/wiki/Taiichi_Ohno){rel="&#x22;nofollow&#x22;"} refined it in the decades after World War II, formalizing the practice of observing problems firsthand at the [gemba](https://en.wikipedia.org/wiki/Gemba){rel="&#x22;nofollow&#x22;"} and asking why until reaching something systemic.

The method spread beyond automotive manufacturing in the 1970s-80s as Western companies studied Toyota's success, though often without the cultural foundation that made it work: it only survives in an environment where people feel safe identifying systemic problems and management is committed to fixing them, not one that shoots the messenger.

## 5 Whys Best Practices

- **Focus on processes, not people.** If your analysis points to an individual's mistake, keep going: why didn't training or a verification step catch it? A well-designed process assumes people will make mistakes and builds in safeguards.
- **Verify every answer.** The 5 Whys fails when it becomes brainstorming instead of investigation. Each answer needs evidence, a log, a measurement, a witness, not a guess.
- **Stay on one causal chain at a time.** Resist branching into every contributing factor at once; follow the most likely path to the end first, then circle back if it doesn't hold up.
- **Keep questions neutral.** "Why wasn't the pressure checked?" surfaces procedural gaps; "why did the operator forget?" just points toward blame.
- **Know when to stop.** You're done when the answer is something fixable through a procedural, training, or design change, not a philosophical statement about culture or budget.

## Common 5 Whys Mistakes

The most frequent mistake is stopping at a symptom: a part fails, the team replaces it, logs "component failure," and moves on without asking why it failed. Close behind is accepting "human error" as the root cause, when the real question is why that error was possible and why existing safeguards didn't catch it. Teams also rush through the questions when they're uncomfortable, quickly blaming an operator instead of investigating, or branch off into several causal chains at once and never follow any of them to a concrete root cause. Each of these produces an analysis that looks complete but changes nothing.

## 5 Whys Example: The Original Toyota Case

Here's the classic example from Taiichi Ohno, one of the architects of the Toyota Production System, documented in his book "Toyota Production System: Beyond Large-Scale Production" (1988, p. 17).

**The problem:** A machine stopped functioning on the factory floor.

**Why #1:** "Why did the machine stop?" :br&#x2A;Answer:* There was an overload and the fuse blew.

**Why #2:** "Why was there an overload?" :br&#x2A;Answer:* The bearing was not sufficiently lubricated.

**Why #3:** "Why was it not lubricated sufficiently?" :br&#x2A;Answer:* The lubrication pump was not pumping sufficiently.

**Why #4:** "Why was it not pumping sufficiently?" :br&#x2A;Answer:* The shaft of the pump was worn and rattling.

**Why #5:** "Why was the shaft worn out?" :br&#x2A;Answer:* There was no strainer attached and metal scrap got in.

**Root cause:** No strainer in the lubrication system allowing debris contamination.

**Corrective action:** Install a strainer in the lubrication system to prevent metal scrap from entering the pump.

This example demonstrates the fundamental questioning pattern. Modern Five Whys analyses typically include more detailed evidence documentation at each step (inspection reports, sensor data, maintenance logs), but the core approach of following a single causal chain to reach a systemic issue remains unchanged. Notice how the analysis moved from a symptom (blown fuse) through intermediate causes (overload, insufficient lubrication, worn shaft) to arrive at a fixable process gap (missing strainer).

## Implementing the 5 Whys in Your Organization

Start with a pilot program, one department or one type of problem, rather than a company-wide rollout, and train a small group thoroughly rather than everyone superficially. Expect the first few analyses to feel awkward: people will want to skip to solutions or struggle to phrase neutral questions. That's normal and improves with practice. After each analysis, debrief on the process itself (did we gather evidence or speculate? follow one chain or branch off?), and track whether corrective actions actually get completed, since root cause analysis without follow-through is worse than no analysis at all. Give it six months before judging whether it's working; a shortfall by then is usually an implementation problem, not a flaw in the method.

## Measuring Whether the 5 Whys Is Working

Four metrics tell the story: **problem recurrence** (do issues that used to recur monthly or quarterly stop appearing?), **cycle time** from problem to implemented fix (this should shrink with practice), **quality of corrective actions** (systemic fixes, not "be more careful" reminders), and **staff engagement** (are frontline staff bringing problems forward and suggesting causes on their own?).

## 5 Whys Limitations

The method assumes a roughly linear cause-and-effect chain, so it struggles with modern failures that result from several systems interacting at once (software, sensors, mechanical wear) rather than one dominant path. It also depends entirely on the honesty and knowledge of whoever answers: people who don't know will speculate, and people worried about blame will stop at a superficial answer. It's prone to confirmation bias if the team already suspects a cause, and it won't tell you which of twenty recurring problems to tackle first, that needs a separate prioritization framework based on risk, cost, or frequency. None of this makes the method useless, but it does mean recognizing when a problem needs a different or additional approach.


# FlowFuse 2.25: Interacting with MCP Resources in FlowFuse Expert, Improved Update Scheduling, and lots of UI improvements!

This release comes with some big updates for the FlowFuse Expert.

## Interact with MCP Resources in FlowFuse Expert

![Image of MCP in FlowFuse](https://flowfuse.com/blog/2025/12/images/mcp-in-flowfuse.png)&#x2A;[FlowFuse Expert Interface]*

Our [MCP nodes](https://flowfuse.com/node-red/flowfuse/mcp/) make is super easy to extend AI Agents with tools and resources in your environment. With this release, we're introducing the ability to interact your MCP servers directly within the FlowFuse Expert.

Previously, when setting up an MCP server in FlowFuse, you would first designate your tools, resources, and servers in side of Node-RED using the MCP nodes. Then, to interact with them, you needed a separate tool like VSCode to query and perform operations.

We want you to be able to access your resources as quickly and easily as possible, and reduce the manual overhead involved in managing and querying your MCP resources.

We've greatly simplified this process. You can now set everything up in Node-RED and then use the FlowFuse expert to designate your tools and interact with them, without ever leaving FlowFuse. This will speed you up and simplify your operations.

## FlowFuse Expert Assistant in Node-RED

![FlowFuse Expert Assistant in Node-RED](https://flowfuse.com/blog/2025/12/images/ff-assistant-nr.png)&#x2A;[FlowFuse Expert UI]*

We're very excited to announce that all Node-RED users can now use our FlowFuse Expert Assistant. The ASsistant will help you create Function nodes, Template nodes, and explain highlighted flows using the Flow Explainer.

Previously, this was only available in Node-RED managed directly by the FlowFuse platform. Now everyone using Node-RED, whether they are a FlowFuse user or not, can make use of this technology and speed the development of their Node-RED workflows.

You will need an account on FlowFuse Cloud to connect it to, but for this release, it does *not* require a paid subscription to use.

Check the FlowFuse Expert Assistant docs for [how to get started](https://flowfuse.com/docs/user/expert/).

## Improved Update Scheduling

![Image of Scheduled Updates UI](https://flowfuse.com/blog/2025/12/images/updates.png)&#x2A;[Scheduled Updates Interface]*

We added the ability to schedule updates for your instances in the last release. Based on user feedback, we've now also added the ability to schedule restarting of your instance regardless of whether an update is available.

## Lots of small updates for a better user experience

When we plan our releases, we look for what will make good headlines in our release annoucements - the big, shiny features that can get lots of attention. Sometimes we also take an opportunity to clear lots of little issues that ultimately are less headline-worthy, but all make for a better user experience.

For example, this release sees lots of small improvements to the FlowFuse Tables user experience; adding the ability to refresh the displayed data, more accessible column table names, an improved layout. Nothing to set the socials buzzing, but genuine quality of life improvements to our users.

## What else is new?

For a complete list of everything included in our 2.25 release, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.25.0){rel="&#x22;nofollow&#x22;"}.

Your feedback continues to be invaluable in shaping FlowFuse's development. We'd love to hear your thoughts on these new features and any suggestions for future improvements. Please share your experiences or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Which of these new features are you most excited to try? Reach out on GitHub or social media!

## Try FlowFuse

### FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in the cloud within minutes.

### Self-Hosted

Get FlowFuse running locally in under 30 minutes using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# Building a Weather Dashboard in Node-RED (2026)

A weather dashboard is honestly the best first project if you're getting into Node-RED. Takes about 10-15 minutes from start to finish, and by the end you'll understand how the whole thing works - connecting to APIs, processing data, and displaying it visually.

This isn't one of our typical deep-dive industrial posts, it's a straightforward starter tutorial. You'll be building something real: calling an actual weather API, handling JSON responses, and watching live data appear on your dashboard. It's the kind of project that makes Node-RED's flow-based approach suddenly make sense. Once you've built it, you'll have a solid foundation for more complex projects.

We'll use FlowFuse Dashboard for the UI since it's modern and easier to work with. If you know how to drag nodes around and hit the deploy button, you're ready to start.

## What You'll Need

Before you start, make sure you have:

- **Node-RED Instance:** You need Node-RED running somewhere. Easiest option is FlowFuse, [grab a free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and you get a cloud-hosted instance ready to go. No server setup, no port forwarding hassles.
- **OpenWeatherMap Account:** Sign up at `openweathermap.org`. The free tier gives you enough API calls for this project.

## Installing FlowFuse Dashboard

First, get the dashboard package installed:

1. Click the hamburger menu in the top right corner
2. Select Manage palette
3. Go to the Install tab
4. Type `@flowfuse/node-red-dashboard` in the search box
5. Click the install button next to it

Wait for it to finish. You'll see a bunch of new dashboard nodes pop up in your left sidebar, things like **ui-gauge**, **ui-text**, **ui-chart**. That's how you know it worked.

## Getting Your API Key

Log in to your OpenWeather account. Once you're signed in:

1. Go to your account section
2. Find API keys
3. Copy the default key (or generate a new one)
4. Save it in a text file or a note app.

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

## Setting Up the API Connection

First, we need to connect to the weather API and make sure it's working.

1. Drag an **inject** node onto the canvas
2. Double-click to configure it
3. Change **Repeat** from "none" to "interval"
4. Set it to repeat every 5 seconds (or whatever interval you prefer)
5. Check the box for **Inject once after** and set it to 0.1 seconds, this will trigger the flow immediately when you deploy
6. Click Done

![Inject node configured to trigger the weather API every 5 seconds](https://flowfuse.com/blog/2025/12/images/trigger-weather-api.png){dataZoomable=""}*Inject node configured to trigger the weather API every 5 seconds*

7. Drag an **http request** node to the right of it
8. Drag a **debug** node to the right of the **http request** node
9. Double-click the **http request** node to open its settings:
10. Make sure **Method** is set to GET
11. In the **URL** field, paste: `https://api.openweathermap.org/data/2.5/weather?q=London&appid=YOUR_API_KEY&units=metric`
12. Replace `YOUR_API_KEY` with the actual API key you copied from OpenWeatherMap
13. Replace `London` with your city if you want
14. Select the Return as **parsed JSON**.

![HTTP request node configured to fetch weather data from OpenWeatherMap API](https://flowfuse.com/blog/2025/12/images/http-request.png){dataZoomable=""}*HTTP request node configured to fetch weather data from OpenWeatherMap API*

14. Click Done

The `units=metric` gives you Celsius. Change it to `units=imperial` for Fahrenheit. For more details on what parameters you can use, check out the [OpenWeatherMap API documentation](https://openweathermap.org/current){rel="&#x22;nofollow&#x22;"}.

Now wire the nodes together by clicking and dragging from the **inject** node's right side to the **http request** node's left side, then from the **http request** node to the **debug** node.

Click the **Deploy** button in the top right and open the debug panel on the right sidebar if it's not already open.

You should see a JSON object with weather data, temperature, humidity, wind speed, description, and more. This is the raw data coming back from the API.

If you see a 401 error, your API key may still be activating. Wait 10–15 minutes and try again, or verify the key again in case it’s invalid or mistyped.

## Processing the Weather Data

Now that you're getting data from the API, you need to extract the specific values you want to display. We'll use a **function** node to pull out temperature, humidity, weather description, and wind speed.

1. Drag a **function** node and add following code into it and connect it to the **http request** node:

```javascript
// Extract the data we need
const temp = msg.payload.main.temp;
const humidity = msg.payload.main.humidity;
const description = msg.payload.weather[0].description;
const windSpeed = msg.payload.wind.speed;
const city = msg.payload.name;

// Create separate messages for each value
return [
    { payload: city, topic: "city" },
    { payload: description, topic: "description" },
    { payload: temp, topic: "temperature" },
    { payload: humidity, topic: "humidity" },
    { payload: windSpeed, topic: "wind" },
];
```

> **Tip:** If you're using FlowFuse, you don't need to write this JavaScript manually. You can use the FlowFuse Expert to generate the function code for you, just describe what you want the **function** node to do. Check out the [article](https://flowfuse.com/blog/2025/07/flowfuse-ai-assistant-better-node-red-manufacturing/) for more details.

2. Set the **function** node's **Outputs** (in the Setup tab) to 5, since the function will return five separate messages.

![Function node configured with 5 outputs to split weather data](https://flowfuse.com/blog/2025/12/images/function-setup-tab.png){dataZoomable=""}*Function node configured with 5 outputs to split weather data*

3. Click Done

This **function** node splits the API response into separate outputs - one for temperature, one for humidity, and so on. Each output gets its own topic label so you can track what's what.

## Building the Dashboard

Now you'll see your weather data displayed on screen. This demonstrates how Node-RED connects data sources to visual components. We'll organize the dashboard into separate groups for better visual organization.

### Configuring the City Name Display

Start by displaying which city you're tracking:

1. Drag a **ui-text** node onto the canvas
2. Connect it to **output 1** of your **function** node (the city output)
3. Double-click the **ui-text** node to open its settings
4. Set **Label** to "City"
5. For **Group**, click the pencil icon to create a new group called "Weather Info"
6. Click Add, then Done

![UI text node configured to display city name in Weather Info group](https://flowfuse.com/blog/2025/12/images/city-display.png){dataZoomable=""}*UI text node configured to display city name in Weather Info group*

You've just created your first dashboard element and dashboard group. Groups organize widgets on the page and function as containers.

### Configuring the Weather Description

Add a text field to show current conditions:

1. Drag another **ui-text** node onto the canvas
2. Connect it to **output 2** of your **function** node (description output)
3. Double-click to configure
4. Set **Label** to "Conditions"
5. Use the same "Weather Info" group
6. Click Done

![UI text node configured to display weather conditions](https://flowfuse.com/blog/2025/12/images/condition-display.png){dataZoomable=""}*UI text node configured to display weather conditions*

The API returns descriptions like "scattered clouds" or "light rain" - human-readable conditions.

### Configuring the Temperature Gauge

Next, add a circular gauge for temperature:

1. Drag a **ui-gauge** node onto the canvas
2. Connect it to **output 3** of your **function** node (the temperature output)
3. Double-click to open settings
4. Set **Label** to "Temperature (°C)"
5. Set **Min** to 0 and **Max** to 50 (adjust these based on your climate)
6. Add the color segments you want, as shown in the reference image.
7. For **Group**, click the pencil icon to create a **new group** called "Temperature & Humidity"
8. Click Add to create the group
9. Under the **Appearance** tab, you can select a color scheme if desired
10. Click Done

![Temperature gauge configured with color-coded segments in Temperature & Humidity group](https://flowfuse.com/blog/2025/12/images/temperature-gauge.png){dataZoomable=""}*Temperature gauge configured with color-coded segments in Temperature & Humidity group*

The gauge will automatically color-code based on the value - cooler temperatures display in blue tones, warmer in orange/red.

### Configuring the Humidity Gauge

Add the humidity gauge to the same group:

1. Drag another **ui-gauge** node onto the canvas
2. Connect it to **output 4** of your **function** node (humidity output)
3. Double-click to configure
4. Set **Label** to "Humidity (%)"
5. Set **Min** to 0 and **Max** to 100 (humidity is always a percentage)
6. Add the color segments you want, as shown in the reference image.
7. Use the same "Temperature & Humidity" group from the dropdown
8. Click Done

![Humidity gauge configured to display percentage values with color coding](https://flowfuse.com/blog/2025/12/images/humidity-gauge.png){dataZoomable=""}*Humidity gauge configured to display percentage values with color coding*

The two gauges will display side by side in the same group, making it easy to compare both metrics at once.

## Configuring the Wind Speed Display

Next, create a dedicated chart to display wind speed trends over time:

1. Drag a **ui-chart** node onto your flow.
2. Connect it to **output 5** of your **function** node (the wind speed output).
3. Double-click the **ui-chart** node to configure it.
4. Set **Label*&#x2A; to &#x2A;*"Wind Speed (m/s)"**.
5. Set **Type** to **Line chart**.
6. For the **X-axis**, select **Timestamp**.
7. Set **Y-axis** to use **msg.payload**.
8. Set **Series** to **msg.topic**.
9. Under **Group**, click the pencil icon and create a **new group*&#x2A; named &#x2A;*"Wind Speed"**.
10. Click **Add**, then **Done** to save the configuration.

![Wind speed chart configured as a line chart to show trends over time](https://flowfuse.com/blog/2025/12/images/wind-speed-chart.png){dataZoomable=""}*Wind speed chart configured as a line chart to show trends over time*

## Viewing Your Dashboard

Hit the Deploy button in the top right corner.

Then, open the Dashboard 2.0 sidebar and click the Open Dashboard button. You should now see a dashboard similar to the one shown below.

![Complete weather dashboard displaying real-time weather data](https://flowfuse.com/blog/2025/12/images/weather-dashboard.png){dataZoomable=""}*Complete weather dashboard displaying real-time weather data*

Below is the complete flow. Import it, enter your API URL with your API key in the **http request** node, and deploy the flow:

::render-flow{:height='300'}
```json
[{"id":"f4c08591654c29ef","type":"inject","z":"9cf82b68bb89e8ce","name":"Trigger Weather API","props":[],"repeat":"5","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":100,"y":1300,"wires":[["70d3dab532802c97"]]},{"id":"70d3dab532802c97","type":"http request","z":"9cf82b68bb89e8ce","name":"OpenWeather Request","method":"GET","ret":"obj","paytoqs":"ignore","url":"","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":340,"y":1300,"wires":[["849a9025bb2f8a78"]]},{"id":"849a9025bb2f8a78","type":"function","z":"9cf82b68bb89e8ce","name":"Process Weather Data","func":"// Extract the data we need\nconst temp = msg.payload.main.temp;\nconst humidity = msg.payload.main.humidity;\nconst description = msg.payload.weather[0].description;\nconst windSpeed = msg.payload.wind.speed;\nconst city = msg.payload.name;\n\n// Create separate messages for each value\nreturn [\n    { payload: city, topic: \"city\" },\n    { payload: description, topic: \"description\" },\n    { payload: temp, topic: \"temperature\" },\n    { payload: humidity, topic: \"humidity\" },\n    { payload: windSpeed, topic: \"wind\" },\n];","outputs":5,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":580,"y":1300,"wires":[["b32ec3dc036c981e"],["d6a1cfaa374bf3e9"],["5313d0217f55e2cf"],["fca37c757fb4d69d"],["b668bf185e686847"]]},{"id":"5313d0217f55e2cf","type":"ui-gauge","z":"9cf82b68bb89e8ce","name":"Temperature","group":"9470e51a8ec86d8e","order":1,"value":"payload","valueType":"msg","width":"3","height":"3","gtype":"gauge-half","gstyle":"needle","title":"Temperature","alwaysShowTitle":false,"floatingTitlePosition":"top-left","units":"°C","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#008cb4","text":"","textType":"value"},{"from":"15","color":"#00a3d7","text":"","textType":"value"},{"from":"25","color":"#fec700","text":"","textType":"value"},{"from":"35","color":"#ffaa00","text":"","textType":"value"},{"from":"50","color":"#ff6251","text":"","textType":"value"}],"min":0,"max":"50","sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":790,"y":1300,"wires":[[]]},{"id":"b32ec3dc036c981e","type":"ui-text","z":"9cf82b68bb89e8ce","group":"5a89ac7171f51cc3","order":1,"width":"0","height":"0","name":"City Display","label":"City:","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"Arial,Arial,Helvetica,sans-serif","fontSize":"21","color":"#000000","wrapText":false,"className":"","value":"payload","valueType":"msg","x":790,"y":1220,"wires":[]},{"id":"d6a1cfaa374bf3e9","type":"ui-text","z":"9cf82b68bb89e8ce","group":"5a89ac7171f51cc3","order":3,"width":"0","height":"0","name":"Conditions Display","label":"Conditions:","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"Arial,Arial,Helvetica,sans-serif","fontSize":"21","color":"#000000","wrapText":false,"className":"","value":"payload","valueType":"msg","x":810,"y":1260,"wires":[]},{"id":"fca37c757fb4d69d","type":"ui-gauge","z":"9cf82b68bb89e8ce","name":"Humidity Gauge","group":"9470e51a8ec86d8e","order":2,"value":"payload","valueType":"msg","width":"3","height":"3","gtype":"gauge-half","gstyle":"needle","title":"Humidity","alwaysShowTitle":false,"floatingTitlePosition":"top-left","units":"%","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#d95000","text":"","textType":"value"},{"from":"30","color":"#6f7608","text":"","textType":"value"},{"from":"80","color":"#fec700","text":"","textType":"value"},{"from":"100","color":"#d95000","text":"","textType":"value"}],"min":0,"max":"100","sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":800,"y":1340,"wires":[[]]},{"id":"b668bf185e686847","type":"ui-chart","z":"9cf82b68bb89e8ce","group":"7b2025c104cd506e","name":"Wind Speed","label":"Wind Speed (m/s)","order":1,"chartType":"line","category":"topic","categoryType":"msg","xAxisLabel":"","xAxisProperty":"","xAxisPropertyType":"timestamp","xAxisType":"time","xAxisFormat":"","xAxisFormatType":"auto","xmin":"","xmax":"","yAxisLabel":"","yAxisProperty":"payload","yAxisPropertyType":"msg","ymin":"","ymax":"","bins":10,"action":"append","stackSeries":false,"pointShape":"circle","pointRadius":4,"showLegend":true,"removeOlder":1,"removeOlderUnit":"3600","removeOlderPoints":"","colors":["#0095ff","#ff0000","#ff7f0e","#2ca02c","#a347e1","#d62728","#ff9896","#9467bd","#c5b0d5"],"textColor":["#666666"],"textColorDefault":true,"gridColor":["#e5e5e5"],"gridColorDefault":true,"width":"12","height":"4","className":"","interpolation":"linear","x":790,"y":1380,"wires":[[]]},{"id":"9470e51a8ec86d8e","type":"ui-group","name":"Temperature & Humidity","page":"f1eb99b1e714d411","width":6,"height":1,"order":2,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"5a89ac7171f51cc3","type":"ui-group","name":"Weather Info","page":"f1eb99b1e714d411","width":"6","height":"4","order":1,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"7b2025c104cd506e","type":"ui-group","name":"Wind Speed","page":"f1eb99b1e714d411","width":"12","height":1,"order":3,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"f1eb99b1e714d411","type":"ui-page","name":"Weather Dashboard","ui":"afea04ce8735c0a6","path":"/weather","icon":"home","layout":"grid","theme":"93822a7b43673c58","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":true,"disabled":false},{"id":"afea04ce8735c0a6","type":"ui-base","name":"UI Name","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-control","ui-notification"],"headerContent":"page","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":5,"showDisconnectNotification":true,"allowInstall":true},{"id":"93822a7b43673c58","type":"ui-theme","name":"Default Theme","colors":{"surface":"#00a3d7","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"950b3b399ea22ea6","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.29.0"}}]
```
::

## What's Next?

That's it! You've built a real-time weather dashboard and learned the basics of Node-RED, connecting to APIs, processing data, and building visual interfaces.

Throughout this tutorial, you used FlowFuse to host Node-RED and FlowFuse Dashboard for the UI. If you're just starting out, FlowFuse makes things easier, no server setup, no port forwarding, and your dashboard works anywhere. Plus, when you're ready to build bigger projects, features like team collaboration, DevOps pipelines, RBAC, snapshots, and audit logs are already built in.

Try expanding your dashboard by adding more cities, creating historical charts, or setting up weather alerts. The pattern stays the same, you're just swapping data sources and visualizations.

This same pattern scales to a global level, too: [the World Meteorological Organization uses Node-RED to modernize how meteorological data is shared between national weather services worldwide](https://flowfuse.com/customer-stories/un-wmo-nr-data-sharing/).

[Start your free FlowFuse trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and keep building.


# MQTT vs Kafka: Complete Comparison Guide 2026

Building IoT systems means making hard choices about how messages flow through your infrastructure. Apache Kafka and MQTT couldn't be more different in their approaches. MQTT came from the world of sensors and resource-constrained devices. Kafka was designed to push massive data streams between backend systems. Getting this choice right early determines whether your architecture scales smoothly or hits a wall.

## What Makes MQTT Different

MQTT (Message Queuing Telemetry Transport) showed up in 1999 when engineers needed to monitor oil pipelines with SCADA systems over unreliable satellite links. The whole point was squeezing messages through terrible networks without killing battery life.

The protocol uses binary encoding with headers as small as 2 bytes. That's it. This matters when you're running on an ESP32 with 520KB of RAM or sending data over a 2G connection that costs per kilobyte. MQTT runs over TCP/IP and supports TLS when you need encryption.

![Image: How MQTT Works](https://flowfuse.com/blog/2025/12/images/mqtt.png)

Here's how it works: A central broker sits in the middle. Devices publish messages to topics like `factory/line-1/temperature`. Other devices subscribe to those topics. The broker figures out who gets what. Topics use forward slashes to create hierarchies, so you can subscribe to `factory/#` and catch everything happening in the factory. You can also use wildcards: `#` matches multiple levels (like `factory/# `for everything under factory), while `+` matches exactly one level (like `sensors/+/temperature` for temperature readings from any single sensor).

MQTT has three Quality of Service levels:

**QoS 0** - Fire and forget. Send the message once, hope it arrives. No acknowledgment, no retry. Fast but unreliable.

**QoS 1** - At least once delivery. The broker acknowledges receipt and retries if needed. You might get duplicates.

**QoS 2** - Exactly once through a four-way handshake. Slowest but guaranteed.

:cta-image{alt="Power Workplace relies on FlowFuse for scalability, reliability and security audits - book a demo" cta="demo" src="https://flowfuse.com/images/cta/power-workplace-book-demo.png"}

Pick based on what you're sending. Temperature readings every 10 seconds? QoS 0 is fine. Critical alarm messages? QoS 2.

## How Kafka Works

LinkedIn built Kafka in 2011 because they were drowning in activity streams and operational metrics. Traditional message queues couldn't keep up. So they designed something that acts more like a distributed database than a message broker.

Kafka organizes everything into topics, and topics split into partitions. Each partition is just an ordered log of messages that never changes once written. Producers append messages to the end. Consumers track where they are in each partition using offsets. Multiple producers and consumers can hammer different partitions simultaneously, which is how Kafka gets ridiculous throughput.

![Image: How Kafka Works](https://flowfuse.com/blog/2025/12/images/kafka.png)

The architecture spreads partitions across multiple broker servers. Each partition gets replicated to other brokers based on your replication factor. If a broker crashes, another one takes over for its partitions immediately. No data loss, no downtime.

Unlike MQTT, messages don't disappear after delivery. Everything writes to disk. You configure retention policies, keep messages for 7 days, 30 days, or forever. This means you can replay messages, let new consumers read historical data, or reprocess everything if your analytics code had a bug.

Early Kafka needed Apache Zookeeper for cluster coordination, which added complexity. Recent versions support KRaft mode that removes this dependency, though many production systems still run Zookeeper.

## The Real Differences

### Architecture Philosophy

MQTT keeps things simple with a central broker. Devices connect, the broker routes messages, everyone's happy. You can get started with a single Raspberry Pi running Mosquitto. The 2-byte headers and compact binary format mean your sensor data flows efficiently even on constrained networks.

Kafka is distributed by design. Topics partition across brokers. Consumers track offsets themselves. Everything replicates for fault tolerance. You need coordination infrastructure (Zookeeper or KRaft), multiple brokers for production, and someone who knows distributed systems. But this complexity buys you throughput that single-broker systems simply can't match.

### Performance Reality

MQTT delivers messages in milliseconds. It runs on microcontrollers with kilobytes of RAM. A sensor reading might be 10-20 bytes including protocol overhead. A decent broker handles thousands to tens of thousands of messages per second, which works fine when you have hundreds of thousands of devices sending data every few seconds.

Kafka sacrifices latency for volume. Messages take tens to hundreds of milliseconds because of disk writes, replication, and consumer polling. But a single broker can handle hundreds of thousands of messages per second. Clusters process billions daily. You need real hardware, multiple cores, 32GB+ memory, fast SSDs, but you get data movement at enterprise scale.

### How Messages Get Delivered

MQTT's three QoS levels give you options. QoS 0 is fast but lossy. QoS 1 guarantees delivery but might duplicate. QoS 2 does exactly-once with a four-way handshake. Brokers can queue messages for offline subscribers, but they're not designed for long-term storage.

Kafka writes everything to disk based on your retention policy. Producers pick acknowledgment levels: wait for the leader broker (fast, less safe) or wait for all replicas (slower, fully durable). Consumers commit offsets after processing messages. Modern Kafka supports exactly-once semantics through transactions and idempotent producers. The persistence model enables message replay and handles consumer failures completely differently than MQTT.

### Running This Stuff in Production

Setting up an MQTT broker is straightforward. You can start with something like Mosquitto for development, or choose from production-ready brokers that support clustering and high availability. Configure authentication, add redundancy as needed, and monitor connection counts, message rates, and queue depths, most brokers expose metrics via REST APIs or monitoring endpoints.

> FlowFuse includes a managed MQTT broker built right into the platform, no separate infrastructure to set up or maintain. It connects directly with your Node-RED flows, so you can publish and subscribe to topics without leaving the environment. Check out the [details](https://flowfuse.com/blog/2025/10/plc-to-mqtt-using-flowfuse/#step-3-set-up-mqtt-with-flowfuse) to see how it works.

Kafka demands more. You need at least three brokers plus coordination services. Monitor partition distribution, replication lag, consumer group status, disk usage. Plan capacity for both storage and network bandwidth. Rolling upgrades require care. Partition reassignment needs coordination. The learning curve is real, but the system handles failures gracefully once you understand it.

### Where to Use Each One

MQTT dominates in manufacturing plants with sensor networks, building automation, remote sites on cellular connections, and fleet tracking. It's the right call when devices have limited CPU and memory, networks constrain bandwidth, you're dealing with thousands of messages per second, and you don't need long-term storage.

Kafka powers financial transaction processing, e-commerce backends, infrastructure monitoring at scale, and data engineering pipelines. Use it when message volumes hit hundreds of thousands per second, multiple systems need independent access to the same data stream, you need replay capabilities, or you're feeding data into analytics platforms.

***Most real systems use both. MQTT handles the edge, Kafka moves data between central systems. You see this pattern everywhere, MQTT at factory sites, Kafka in the data center.***

## Making the Choice

Here's how to think about it:

**Pick MQTT when:**

- Your devices are resource-constrained (microcontrollers, embedded systems)
- Network bandwidth is limited or expensive
- You're handling thousands of messages per second
- Simple deployment matters
- You need efficient edge device communication
- Long-term message storage isn't a requirement

**Pick Kafka when:**

- Message volumes hit hundreds of thousands per second or more
- Multiple applications need independent access to message streams
- You need message replay or event sourcing capabilities
- Stream processing is part of the architecture
- Integration with big data tools matters
- Your ops team knows distributed systems

Neither is "better." They solve different problems. Your requirements drive the decision.

## Integrating MQTT and Kafka

As mentioned, real production systems don’t choose between these, they use both. Devices and sensors typically publish data over MQTT, while analytics platforms, data lakes, and stream processors consume events from Kafka. The real challenge lies in bridging the two reliably and cleanly.

Most teams write custom bridge services or deploy Kafka Connect with MQTT source connectors. Custom bridges give you complete control but require development and maintenance. Kafka Connect reduces code but adds configuration complexity, especially when you need transformation logic beyond simple field mapping.

FlowFuse takes a different approach using Node-RED's visual programming model. [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/) and [Kafka](https://flowfuse.com/blog/2024/03/using-kafka-with-node-red/) nodes connect through flows that define routing and transformation logic. The platform manages protocol connections and flow execution without separate bridge infrastructure.

As mentioned before, FlowFuse includes a managed MQTT broker built directly into the platform. Beyond MQTT and Kafka, it supports industrial protocols like Modbus, OPC UA, and HTTP. Device connections, message processing, and Kafka integration all happen in one environment. You get built-in version control, deployment management, team collaboration, and much more.

FlowFuse offers a free trial for testing MQTT-Kafka workflows. [Start building](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"} or [schedule a consultation](https://flowfuse.com/contact-us/) to discuss your specific needs.

## Conclusion

MQTT and Kafka solve different problems. MQTT gives you efficient device connectivity with minimal overhead. Kafka delivers high-throughput event streaming with persistence and replay.

Understanding these differences helps you pick the right tool for the job. Most production systems use both, leveraging each where it provides the most value. Base your decision on message volumes, device capabilities, operational requirements, and team expertise, not on whatever's trending on Hacker News.


# MTTF vs MTBF vs MTTR: Formulas, Calculations & Key Differences

A motor bearing assembly rated for a year fails after six months. Is that an MTTF problem, an MTBF problem, or something you should be tracking as MTTR instead? Attach the wrong metric to the wrong type of equipment, and your maintenance planning is built on a number that was never meant to apply.

MTTF, MTBF, and MTTR all measure reliability, but they answer different questions. MTTF (Mean Time to Failure) tracks how long a non-repairable part lasts before it's replaced. MTBF (Mean Time Between Failures) tracks how long a repairable system runs between fixes. MTTR (Mean Time to Repair) tracks how long those fixes take. Confuse the three and you end up comparing numbers that were never meant to be compared, and basing replacement schedules, spare parts inventory, and supplier decisions on the wrong one.

These metrics emerged as core reliability engineering concepts in the 1950s during the development of military and aerospace reliability theory, and remain essential across industries where component and system reliability determine operational success, from semiconductor manufacturing to data centers to industrial automation.

This guide breaks down what each metric measures and when to use which one, then dives into how to calculate MTTF correctly with real examples and how to use that data for strategic maintenance planning.

## MTTF vs MTBF vs MTTR: What's the Difference?

These three acronyms measure fundamentally different aspects of reliability.

### What is MTBF (Mean Time Between Failures)?

MTBF is the average operating time between failures for a **repairable** system, one that gets fixed and returned to service rather than discarded. It's the metric to use for motors, pumps, HVAC units, and vehicles.

```text
MTBF = Total Operating Time / Number of Repair Events (excluding repair time)
```

### What is MTTR (Mean Time to Repair)?

MTTR is the average time it takes to complete a repair once a failure happens, covering diagnosis, parts sourcing, and the fix itself. It applies to any equipment that gets repaired rather than replaced.

```text
MTTR = Total Repair Time / Number of Repairs
```

### MTTF vs MTBF vs MTTR at a glance

| Metric   | What It Measures                     | Use For                                          | Example                                              |
| -------- | ------------------------------------ | ------------------------------------------------ | ---------------------------------------------------- |
| **MTTF** | Average time until permanent failure | Non-repairable items replaced when they fail     | Light bulbs, batteries, hard drives, sealed bearings |
| **MTBF** | Average time between repair events   | Repairable systems fixed and returned to service | Motors, pumps, HVAC systems, vehicles                |
| **MTTR** | Average time to complete repairs     | Any equipment requiring repair                   | All repairable systems                               |

**The key distinction**: MTTF applies when you discard and replace it. MTBF applies when you fix it and keep using it. MTTR tells you how long the fixing takes.

A facility might track MTTF for LED bulbs in their fixtures (replace when burned out) while tracking MTBF for the fixtures themselves (repair when they fail). Both metrics serve different planning purposes.

## What is Mean Time to Failure (MTTF)?

Mean Time to Failure (MTTF) is a reliability metric that measures **the average operating time of a non-repairable component before it fails permanently**. Once the component fails, it is **replaced, not repaired**.

MTTF is commonly used for items such as light bulbs, batteries, sealed bearings, hard drives, electronic modules, and disposable filters. It helps teams understand how long a part typically lasts under normal operating conditions, enabling better planning for replacements, spare parts management, and reduction of unexpected downtime.

MTTF is a core concept in reliability engineering and is widely used in maintenance planning, lifecycle cost analysis, and dependability studies. It is formally supported by industry standards such as &#x2A;*[MIL-HDBK-217](https://www.sre.org/mil-hdbk-217-the-perceived-standard/){rel="&#x22;nofollow&#x22;"}*&#x2A;, &#x2A;*[IEEE Standard 1413](https://standards.ieee.org/ieee/1413/3764/){rel="&#x22;nofollow&#x22;"}*&#x2A;, and &#x2A;*[IEC 60300-3-1](https://webstore.iec.ch/en/publication/1294){rel="&#x22;nofollow&#x22;"}**, which provide guidance on reliability and dependability analysis across the equipment life cycle.

**Important**: MTTF represents a statistical average, some components will fail earlier while others last longer. Use it for planning and forecasting, not for predicting exact failure times of individual components.

:cta-image{alt="Arch Systems scales automation across complex manufacturing environments with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/arch-systems-book-demo.png"}

## Mean Time to Failure (MTTF) Formula

The MTTF calculation is straightforward:

```text
MTTF = Total Operating Time / Number of Failures
```

**Total Operating Time** is the sum of all hours every unit ran before failing. **Number of Failures** is how many units failed permanently and were replaced (not repaired).

### Example

You have 50 light bulbs. Ten bulbs burn out after 8,000 hours (that's 80,000 total hours). Fifteen more fail at 10,000 hours (150,000 hours). The remaining 25 bulbs last 12,000 hours each (300,000 hours). Add it all up and you get 530,000 hours across 50 bulbs.

MTTF = 530,000 / 50 = **10,600 hours**

This means on average, each bulb lasts 10,600 hours before it fails.

The failure rate is simply the inverse of MTTF. If MTTF is 10,000 hours, your failure rate is 0.0001 failures per hour, which means you expect 1 failure every 10,000 hours.

### What This Formula Assumes

The basic MTTF formula works when you're tracking non-repairable parts, failures occur randomly during their normal lifespan, and operating conditions remain roughly consistent. You also need enough failures to make the average meaningful, ideally 30 or more data points.

**When basic MTTF doesn't apply**: If you have components still running at the end of your observation period, or if failure patterns follow a bathtub curve (high early failures, stable middle period, increasing wear-out failures), you'll need advanced statistical methods like Weibull analysis or censored data techniques.

## How to Calculate Mean Time to Failure (MTTF)

### Example 1: Data Center Hard Drives

A data center operates 100 identical hard drives. Over 18 months of operation, they track which drives fail and need replacement:

- **Month 6:** 3 drives fail after 4,380 hours each = 13,140 hours
- **Month 9:** 5 drives fail after 6,570 hours each = 32,850 hours
- **Month 12:** 4 drives fail after 8,760 hours each = 35,040 hours
- **Month 15:** 6 drives fail after 10,950 hours each = 65,700 hours
- **Month 18:** 7 drives fail after 13,140 hours each = 91,980 hours

Total operating time = 238,710 hours :br
Total failures = 25 drives

**MTTF = 238,710 / 25 = 9,548 hours**

This tells the data center they can expect each hard drive to last roughly 9,548 hours (just over 1 year). The remaining 75 drives are still running, so the actual MTTF might be higher, but this gives them a working estimate for planning replacements and maintaining spare inventory.

### Example 2: Manufacturing Plant Conveyor Belts

A factory runs 20 conveyor lines, each with identical drive belts. The maintenance team tracks belt failures over 2 years:

All 20 belts start fresh. After 8,000 hours of operation, 4 belts have failed. After 12,000 hours, 6 more fail. After 16,000 hours, another 5 fail. The remaining 5 belts are still running at the 2-year mark (17,520 hours).

Simplified calculation using all belts (including those still running):

Total time = 20 belts × 17,520 hours = 350,400 hours :br
Total failures = 15 belts

**MTTF = 350,400 / 15 = 23,360 hours**

The plant now knows these belts typically last about 23,360 hours (roughly 2.7 years in continuous operation). They can schedule preventive replacements at around 20,000 hours to avoid unexpected breakdowns during production runs.

## Common Calculation Mistakes to Avoid

One of the most common mistakes when calculating MTTF is confusing calendar time with actual operating hours. A component that runs only part of the day will accumulate operating hours much more slowly than calendar time passes, so it’s critical to measure true runtime rather than elapsed days or months. Another frequent error is including repaired equipment in MTTF calculations. If a component is fixed and returned to service, it belongs in MTBF calculations, not MTTF, which only applies to items that are permanently replaced after failure.

Small sample sizes also lead to misleading results. Calculating MTTF from just a few failures can produce numbers that fluctuate widely and don’t reflect real performance. In practice, at least 20 to 30 failures are needed to produce meaningful averages, with larger datasets providing more reliable insight. Operating conditions are another major source of error. The same component can have very different lifespans depending on factors like temperature, dust, vibration, and load, so MTTF values should always be compared under similar conditions.

Finally, MTTF is often misunderstood as a guaranteed lifespan. It is only an average. Some components will fail much earlier than the MTTF value, while others will last significantly longer. Maintenance planning should account for this natural variation instead of treating MTTF as a minimum life expectancy.

## Where to Find Reliable MTTF Data

Manufacturer datasheets are a useful starting point, but they're measured under controlled lab conditions, so real-world component life is often shorter or more variable. Industry databases like [ISO 14224](https://www.iso.org/standard/64076.html){rel="&#x22;nofollow&#x22;"} offer more realistic benchmarks compiled across many facilities, but still won't fully match your specific environment.

The most reliable MTTF data comes from your own facility. Track installation dates and failure times, and after 20-30 failures your internal MTTF numbers will typically be more accurate and actionable than any external source.

## Using MTTF for Better Maintenance Planning

MTTF delivers the most value when it drives proactive replacement rather than reactive repair. If a component typically fails around 20,000 operating hours, scheduling replacement at 15,000 hours during a planned maintenance window prevents the unexpected breakdown, and replacing parts slightly early is almost always cheaper than absorbing unplanned downtime.

It also sharpens spare parts planning and supplier selection. Estimating expected failures per year from operating hours and installed quantity tells you how many spares to stock without tying up excess working capital, and comparing components by total cost per operating hour, rather than purchase price alone, often favors a pricier part with a longer MTTF once labor and downtime are factored in.

## When MTTF Isn't the Right Metric

MTTF has limitations. Don't use it when:

- **Equipment gets repaired, not replaced** - Use MTBF instead
- **Failure patterns show wear-out** - Components with bathtub curves (high early failures, then stable, then increasing wear-out failures) need Weibull analysis
- **You need real-time reliability** - MTTF describes past performance; it doesn't predict when the next specific unit will fail
- **Safety-critical applications** - Statistical averages aren't appropriate for systems where a single failure could cause injury or environmental harm. Use fault tree analysis or failure mode effects analysis instead

## Bottom Line

Stop guessing when parts will fail. Track installation dates and failure times, and after 20-30 failures you'll have data that beats any manufacturer spec sheet, because it reflects your actual operating conditions rather than laboratory ideals.

Use that data to schedule replacements during planned downtime instead of waiting for a 2am breakdown. Unplanned failures typically cost 3-5x more than scheduled replacements once overtime labor, rush shipping, and lost production are factored in, so the only MTTF numbers that really matter are the ones you measure yourself.

As your equipment base grows, manual tracking becomes cumbersome. [FlowFuse](https://flowfuse.com) automates this by connecting to [PLCs](https://flowfuse.com/blog/2025/12/what-is-plc/), [SCADA](https://flowfuse.com/use-cases/scada/) systems, [MES](https://flowfuse.com/use-cases/mes/) platforms, and your CMMS, pulling operating hours directly from equipment through industrial protocols like [Modbus](https://flowfuse.com/node-red/protocol/modbus/), [OPC UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/), and [EtherNet/IP](https://flowfuse.com/blog/2025/10/using-ethernet-ip-with-flowfuse/), then capturing failure events to recalculate MTTF in real-time across your entire facility.


# Node-RED Buffer Parser Guide: Decode Modbus and Industrial Device Data (2026)

Legacy industrial devices communicate in bytes. Your temperature sensor doesn't send you `{"temp": 23.5}` - it sends you `[1, 3, 4, 1, 44, 0, 200, 190, 125]`. Those numbers are meaningless unless you know how to decode them.

This is what makes working with legacy PLCs and Modbus sensors challenging. You're not dealing with modern APIs that return JSON. You're dealing with raw binary data where byte 3 might be temperature and byte 4 might be humidity, and if you read them in the wrong order, everything breaks.

Node-RED's Buffer Parser node solves this problem. Instead of writing JavaScript to manually decode every buffer, you configure it once visually and it handles the conversion automatically. In this article, we'll learn how to use this node effectively.

## Understanding Buffer Data

When your Modbus sensor responds to a query, Node-RED shows you something like this in the debug panel:

```text
[1, 3, 4, 1, 44, 0, 200, 190, 125]
```

Nine bytes. Each one is a number between 0 and 255. This data is completely meaningless without context.

Byte 0 might be a device address. Bytes 3 and 4 together might encode temperature. But the buffer itself doesn't tell you any of this - you need the device manual to figure out what goes where.

Take bytes 3 and 4: `1` and `44`. If you're supposed to read them as a 16-bit integer, that's either 300 or 11265 depending on byte order. If the device uses a scale factor of 10, the actual temperature could be 30.0°C or 1126.5°C. Get any part of this wrong and your dashboard shows nonsense.

So why do devices work this way? Why not just send `{"temperature": 30.0}`?

That JSON message takes 21 bytes. The same information in binary takes 2 bytes. When you're on a serial connection running at 9600 baud, sending thousands of sensor readings per day, those extra bytes add up fast.

More importantly, this is how industrial hardware has worked since 1979. Modbus was designed when PLCs had kilobytes of memory. Modern factories still run equipment from the 90s. The protocol isn't going to change because it would be more convenient for us.

You work with what's on the factory floor, this means you need to parse buffers.

## Example: Temperature and Humidity Sensor

Suppose you have a temperature and humidity sensor connected via Modbus RTU. When you query it for data, you get this buffer:

```text
[1, 3, 4, 1, 44, 0, 200, 190, 125]
```

The device manual says this buffer breaks down as:

- Byte 0: Device address (1)
- Byte 1: Modbus function code (3 = read holding registers)
- Byte 2: Data length in bytes (4)
- Bytes 3-4: Temperature reading
- Bytes 5-6: Humidity reading
- Bytes 7-8: CRC checksum

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

You need to extract temperature and humidity. Everything else is Modbus protocol overhead.

The manual also specifies:

- Temperature: 16-bit unsigned integer, big-endian, divide by 10 for actual value in °C
- Humidity: 16-bit unsigned integer, big-endian, divide by 10 for actual value in %RH

Without Buffer Parser, you'd write a function node like this:

```javascript
const buffer = Buffer.from(msg.payload);
const temperature = buffer.readUInt16BE(3) / 10;
const humidity = buffer.readUInt16BE(5) / 10;

msg.payload = { temperature, humidity };
return msg;
```

This works, but it's also fragile. When you need to add a pressure reading next month, you're editing code and hoping you don't break the offset calculations. When someone else looks at this flow, they have no idea what's happening without reading the function and if they don't understand JavaScript, they're stuck.

Buffer Parser turns this into configuration you can see and modify without touching code. Let's walk through a practical example.

> But before you start, make sure you have a Node-RED instance running on your edge device. The fastest, easiest, and most production-ready way is using FlowFuse. If you don't have an account yet, create one with our [free trial](https://app.flowfuse.com/){rel="&#x22;nofollow&#x22;"}. FlowFuse simplifies managing remote instances and provides the ability to create hosted instances, no matter how many you need to manage, it makes it easy. There are no deployment headaches either; everything is managed by FlowFuse with built-in security. You'll also get access to tools such as DevOps pipelines, snapshots for recovery, audit logs, real-time collaboration with granular role-based access control (RBAC), and much more.

## Setting Up the Buffer Parser

The Buffer Parser node is part of the `node-red-contrib-buffer-parser` package. To install it:

1. Open your Node-RED editor
2. Click the menu icon (three horizontal lines) in the top-right corner
3. Select **Manage palette**
4. Go to the **Install** tab
5. Search for `node-red-contrib-buffer-parser`
6. Click **Install**

## Building the Flow

Now let's create a flow to parse the buffer data. For this example, we'll use an Inject node to simulate Modbus data, so while reading you can follow along and learn.

1. Drag an **Inject** node from the palette onto the canvas
2. Double-click the Inject node to open its configuration
3. Set **msg.payload** to "Buffer" from the dropdown
4. In the field, enter: `[1, 3, 4, 1, 44, 0, 200, 190, 125]`

![Node-RED Inject node configuration showing payload set to a Buffer array for simulating data.](https://flowfuse.com/blog/2025/12/images/simulate-data-inject.png){dataZoomable=""}&#x2A;Node-RED Inject node configuration showing payload set to a Buffer array for simulating data.*

5. Click **Done**
6. Drag a **Buffer Parser** node from the palette onto the canvas
7. Drag a **Debug** node onto the canvas
8. Connect the Inject node output to the Buffer Parser node input
9. Connect the Buffer Parser node output to the Debug node input

## Configuring the Buffer Parser

Now let's configure the Buffer Parser node to extract temperature and humidity.

1. Double-click the **Buffer Parser** node to open its configuration panel

![Buffer Parser Configuration](https://flowfuse.com/blog/2025/12/images/buffer-parser.png){dataZoomable=""}

You'll see several fields. Most of them you can ignore for basic parsing. Here's what matters:

**Property**: Leave this set to `msg.payload`. This tells the node where to find your buffer data.

**Specification:** Keep this set to UI Specification. This is the visual method, allowing you to configure everything directly within the node.

**Result Type**: Set this to "Key/value". This gives you clean JSON output like `{"temperature": 30.0, "humidity": 20.0}`.

**Byte Swap**: Leave this set to "No swap" for now. Byte swapping reorders bytes within multi-byte values and is only needed when your device stores data in an unusual format that doesn't match standard big-endian or little-endian conventions. If you've selected the correct endianness (like uint16be or uint16le) and values still look wrong, you might need swap16 (for 16-bit values), swap32 (for 32-bit values), or swap64 (for 64-bit values). Most devices won't require this.

Now let's configure the actual data extraction.

## Extracting Temperature

Let's add the first field to extract temperature from bytes 3-4.

1. Click the **add** button at the bottom of the configuration panel to create a new row in **buffer parser** node

You'll see several fields appear in the row. Let's fill them in:

2. In the **Name** field, enter `temperature`. This is what you'll see in your output JSON.
3. In the **Type** dropdown, select `uint16be`
   - This breaks down as:
     - `uint16` = 16-bit unsigned integer (positive values only)
     - `be` = big-endian (reads bytes in order: first byte is high, second is low)
   - The manual specified "16-bit unsigned integer, big-endian" so this is a direct match
4. In the **Offset** field, enter `3`. Temperature data starts at byte 3. Offset counts from zero, so byte 0 is first, byte 3 is fourth.
5. In the **Length** field, enter `1`. We're reading one value, not an array of values. Length stays at 1 for single values.
6. In the **Scale** field, enter `0.1`. Here's the important part: the Buffer Parser **multiplies** by the scale value, so to divide by 10, you need to multiply by 0.1. Raw value 300 × 0.1 = 30.0.

> Note: Beyond simple multiplication, the Buffer Parser also supports scale equations for more complex transformations. You can use operators like >> for bit shifting (e.g., >>4 to shift right 4 bits), + or - for offsets (e.g., +42 to add 42), / or \* for division/multiplication, \*\* for exponents, and comparison operators like ==, !=, >, < for boolean results. These equations are applied after any mask, giving you powerful options for handling bit-packed data or applying formulas without writing JavaScript.

Let's verify this works with a simple calculation. Bytes 3 and 4 in our buffer are `1` and `44`. Big-endian means we read them in order: (1 × 256) + 44 = 300 in decimal. Multiplied by 0.1 gives 30.0°C. Perfect.

## Extracting Humidity

Now let's add the second field to extract humidity from bytes 5-6.

1. Click the **add** button again to create a second row
2. In the **Name** field, enter `humidity`. This will appear as the key in your output JSON.
3. In the **Type** dropdown, select `uint16be`
   - Same as temperature:
     - `uint16` = 16-bit unsigned integer (no negative values)
     - `be` = big-endian (reads bytes in order)
4. In the **Offset** field, enter `5`. Humidity data starts at byte 5.
5. In the **Length** field, enter `1`. We're reading a single humidity value.
6. In the **Scale** field, enter `0.1`. Again, multiply by 0.1 to effectively divide by 10.

![Buffer Parser configuration rows defining temperature and humidity extraction using uint16be with offsets and scale values.](https://flowfuse.com/blog/2025/12/images/buffer-parser-temp-and-hum.png){dataZoomable=""}&#x2A;Buffer Parser configuration rows defining temperature and humidity extraction using uint16be with offsets and scale values.*

7. Click **Done** to save the configuration

Let's verify this. Bytes 5 and 6 are `0` and `200`. Big-endian reads them in order: (0 × 256) + 200 = 200. Multiplied by 0.1 = 20.0% RH. Perfect.

## Testing the Configuration

Now let's test if everything works correctly.

1. Click **Deploy** in the top-right corner of the Node-RED editor
2. Click the button on the left side of the Inject node to trigger it
3. Open the Debug panel on the right side of the editor

Your Buffer Parser output should look like:

```json
{
  "temperature": 30.0,
  "humidity": 20.0
}
```

This example should work as shown, but with your actual device data, the output may differ. If the values in your JSON don't match what you expect, you're likely running into one of a few common issues. Here's how to recognize and fix them.

If your values are way off, for example, you expect 300 but see 11265, or expect 100 but see 25600, you've got the endianness backwards. Change `int16le` to `int16be` (or vice versa) in the Type field. Alternatively, try setting Byte Swap to `swap16` (or `swap32`/`swap64` for larger data types).

If you're seeing negative numbers when you know the value should be positive, you're using signed integers when you need unsigned. Change `int16` to `uint16` (or `int32` to `uint32`) in the Type field.

If your values are exactly 256 times too large or too small, you're using the wrong data type size. If you're using `int8` but the device sends 16-bit values, change it to `int16be` or `int16le`. If you're using `int16` but the device sends 32-bit values, change it to `int32be` or `int32le`. Check your device manual for the correct bit size.

If you're getting raw values instead of scaled values (for example, 300 instead of 30.0), it means you either forgot to set the Scale field or set it incorrectly. If the device manual says ‘divide by 10,’ enter 0.1 in the Scale field (not 10). Remember: the Buffer Parser multiplies by the scale, so to divide by 10, you must multiply by 0.1

If every number looks completely wrong, recount your offsets carefully. Check each Offset value and verify against your device manual. Remember that byte 0 is first, byte 1 is second, byte 3 is fourth, and so on. The most common mistake is being off by one byte.

If you're getting only one value when the device sends multiple, check the Length field. If your device sends an array of 5 temperature readings starting at byte 10, set Offset to `10` and Length to `5`. The node will return an array of values instead of a single value.

## What About Those Other Fields?

The configuration screen has more fields we didn't touch:

**Bit Offset** only matters when you're using the `bool` type to extract a single bit from a byte. This field is only visible when the bool type is selected. If you need to check whether bit 3 of byte 7 is set (like a "pump running" status flag), you'd set Offset to 7, Type to bool, and Bit Offset to 3. For reading whole numbers, ignore this field.

**Mask** is for when multiple values are packed into the same byte. Industrial protocols do this to save space - why waste 8 bits on a simple on/off flag when you can pack eight flags into one byte? If bits 0-3 hold one sensor reading and bits 4-7 hold another, you use masks like `0x0F` (binary: 00001111, lower 4 bits) and `0xF0` (binary: 11110000, upper 4 bits) to extract each value separately. You'll know when you need this because the manual will say something like "status bits 0-3 contain pump speed, bits 4-7 contain valve position."

For more details on the Buffer Parser node, you can also explore the official [Buffer Parser node documentation](https://flows.nodered.org/node/node-red-contrib-buffer-parser){rel="&#x22;nofollow&#x22;"}, it's comprehensive, well-maintained, and a great reference when working with more advanced parsing options.

## When You Need More Complex Parsing

Buffer Parser handles most industrial protocols, but not everything.

If you need conditional parsing where the structure changes based on values in the buffer itself, you'll need JavaScript. For example, if byte 2 tells you how many temperature readings follow and that number varies, Buffer Parser can't handle variable-length structures dynamically.

If you're dealing with bit-packed data where individual bits within bytes have meaning (common in PLC memory maps), you can use the `bool` type with Bit Offset, but extracting many bits gets tedious. Sometimes a function node doing bitwise operations is cleaner.

> If you're using FlowFuse, you don’t even need to write JavaScript yourself. You can simply ask the [FlowFuse Expert](https://flowfuse.com/blog/2025/07/flowfuse-ai-assistant-better-node-red-manufacturing/) in plain English, paste what your device manual says, and it will generate the Function node directly on your Node-RED canvas.

For standard Modbus registers, serial sensor protocols, and fixed-structure PLC memory layouts - which covers most industrial data, Buffer Parser does exactly what you need.

## Final Thoughts

Binary data from industrial devices isn’t going anywhere. Modbus isn’t disappearing. Neither are PLCs from the 90s or sensors that still speak in raw bytes. This is the reality of factory floors, and it will be for a long time.

The Buffer Parser makes that reality manageable. You don't need to be a buffer expert or master bitwise operations. You just need your device manual, a few minutes to configure the node, and, occasionally, the patience to flip the endianness when a value looks strange. The buffers are still just arrays of bytes, but now you have a tool that turns them into meaningful data without rewriting JavaScript every time you add a new sensor. That's worth something.

And if you’re managing industrial devices at scale, handling remote Node-RED instances, deploying updates across fleets of edge hardware, or keeping everything secure and consistent, FlowFuse can remove much of the daily friction. With features like remote deployment, snapshots, secure device connectivity, and the FlowFuse AI Expert built right into the editor, you can &#x2A;*[book a free demo](https://flowfuse.com/book-demo/)**. Our team will understand your requirements, show you exactly how FlowFuse fits into your workflow, and guide you on getting the most out of your industrial data pipelines.


# Node-RED Timer Tutorial: Create Stopwatch and Countdown Timers

Timers are everywhere in industrial automation. You need them to track how long a machine has been running, measure downtime, schedule maintenance, or coordinate processes that happen in sequence.

Through my work as a technical writer covering IIoT, building industrial applications, and being part of a company where our customers deploy real-world automation systems, I've observed that **timers** are ubiquitous in production environments. Whether it's a production floor display showing machine runtime, a maintenance terminal counting down to the next service window, or an operator interface tracking downtime by reason code, timers are foundational to industrial visibility. Here's an example of a performance operator terminal with timer functionality:

![Performance Operator Terminal](https://flowfuse.com/blog/2025/12/images/performance-operator-terminal.png){dataZoomable=""}*Performance operator terminal displaying real-time production metrics with timer functionality*

If you want to explore this interface yourself, you can [deploy this blueprint](https://flowfuse.com/blueprints/manufacturing/performance-operator-terminal/) to your **FlowFuse** instance and start experimenting immediately.

In this article, we'll build two types of timers in [Node-RED](https://flowfuse.com): **stopwatches** that measure elapsed time and countdowns that trigger actions after a set duration. Both are straightforward to implement and essential for most automation projects.

## Prerequisites

Before following this tutorial, you should have:

- A running **Node-RED instance*&#x2A;. For professional development and production deployments, &#x2A;*[FlowFuse](https://flowfuse.com)** is the recommended platform. If you don’t have an account, [start your free trial](http://app.flowfuse.com){rel="&#x22;nofollow&#x22;"} today.

> FlowFuse provides enterprise-grade Node-RED hosting with managed infrastructure, built-in [DevOps tools](https://flowfuse.com/blog/2024/10/how-to-build-automate-devops-pipelines-node-red-deployments/), [MQTT broker](https://flowfuse.com/blog/2025/10/plc-to-mqtt-using-flowfuse/#step-3-set-up-mqtt-with-flowfuse), [database](https://flowfuse.com/blog/2025/08/getting-started-with-flowfuse-tables/), [team collaboration](https://flowfuse.com/blog/2024/12/flowfuse-team-collaboration/) with [granular access control](https://www.youtube.com/watch?v=mb1s1YQIpZY){rel="&#x22;nofollow&#x22;"}, and seamless scaling capabilities. Whether you need cloud-hosted instances managed by FlowFuse or remote instances running on your edge devices, the platform provides unified management for both. FlowFuse also includes AI-powered features that accelerate flow development and streamline automation projects. From prototyping to mission-critical production deployments, FlowFuse handles the infrastructure complexity so you can focus on building flows.

That's all you need to get started.

# Getting Started

We'll use two Node-RED community nodes for this tutorial: **node-red-contrib-hourglass** for stopwatch timers and node-red-contrib-countdown for **countdown timers**. Both are simple to configure and work reliably in production environments.

Let's start with installing and building a stopwatch.

### Installing the Hourglass Node

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

First, install the **hourglass node** in your Node-RED instance:

1. Open the Node-RED editor
2. Click the **hamburger menu** (top right) and select "Manage palette"
3. Go to the "Install" tab
4. Search for `node-red-contrib-hourglass`
5. Click &#x2A;*"Install"**

The **hourglass node** will appear in your palette under the function category.

## Understanding Hourglass Commands

The hourglass node responds to control commands sent via `msg.command`. The available commands are:

- **start** - Begins timing operation
- **stop** - Stops the timer and outputs elapsed time
- **pause** - Pauses timing without resetting
- **reset** - Clears timer state and stops operation
- **status** - Outputs current timer state without stopping

These commands control timer behavior.

### Implementing a Stopwatch Timer

Build a basic **stopwatch flow**:

1. Drag four inject nodes onto the canvas
2. Add four **change nodes**, one after each inject node, and connect them
3. Configure the change nodes to set `msg.command`:
   - First **change node**: set to `"start"`
   - Second change node: set to `"status"`
   - Third **change node**: set to `"stop"`
   - Fourth change node: set to `"reset"`
4. Drag an **hourglass node** onto the canvas
5. Connect all four change nodes to the **hourglass node** input
6. Add a debug node and connect it to the hourglass node output
7. Deploy the flow

When you trigger the first inject node, the **stopwatch starts**. The second inject node checks current elapsed time without stopping the timer, you can configure this inject node to repeat at intervals for continuous time monitoring. The third inject node stops the **stopwatch** and outputs the total elapsed time. The fourth inject node resets the stopwatch back to zero.

The node outputs a message containing timing information:

![Hourglass node output message showing elapsed time in multiple formats](https://flowfuse.com/blog/2025/12/images/hourglass-output.png){dataZoomable=""}*Hourglass node output message showing elapsed time in multiple formats*

The `elapsed` object provides multiple formats: a human-readable string, total milliseconds, and broken-down time components. This flexibility supports different display requirements and calculation needs.

This basic example demonstrates the pattern. In production applications, replace the inject nodes with actual process triggers, **machine status signals** from PLCs or MQTT messages from sensors. The **hourglass node output** then connects to databases for logging, dashboards for visualization, or notification systems for alerts when thresholds are exceeded.

Below is the complete flow.

::render-flow{:height='300'}
```json
[{"id":"a8e05e4b1a8a8e5e","type":"group","z":"b446dfa04d79d359","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["81365fac1ccf6299","65cf5a523eaee926","560a9271f2b46687","4c5449af7a4dd6ef","e8400461cd50b356","55a008aab6204565","18630deedc38af9f","9ef4a745bd0194cf","cf84add540c079ce","35ab3bbb1674b4f6"],"x":194,"y":2231,"w":892,"h":230},{"id":"81365fac1ccf6299","type":"hourglass","z":"b446dfa04d79d359","g":"a8e05e4b1a8a8e5e","name":"","humanizeLocale":"","x":820,"y":2340,"wires":[["9ef4a745bd0194cf"]]},{"id":"65cf5a523eaee926","type":"inject","z":"b446dfa04d79d359","g":"a8e05e4b1a8a8e5e","name":"Auto Start","props":[{"p":"payload","v":"","vt":"date"},{"p":"topic","v":"","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":310,"y":2272,"wires":[["560a9271f2b46687"]]},{"id":"560a9271f2b46687","type":"change","z":"b446dfa04d79d359","g":"a8e05e4b1a8a8e5e","name":"Start","rules":[{"t":"set","p":"command","pt":"msg","to":"start","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":570,"y":2272,"wires":[["81365fac1ccf6299"]]},{"id":"4c5449af7a4dd6ef","type":"change","z":"b446dfa04d79d359","g":"a8e05e4b1a8a8e5e","name":"Status","rules":[{"t":"set","p":"command","pt":"msg","to":"status","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":570,"y":2320,"wires":[["81365fac1ccf6299"]]},{"id":"e8400461cd50b356","type":"change","z":"b446dfa04d79d359","g":"a8e05e4b1a8a8e5e","name":"Stop","rules":[{"t":"set","p":"command","pt":"msg","to":"stop","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":570,"y":2368,"wires":[["81365fac1ccf6299"]]},{"id":"55a008aab6204565","type":"inject","z":"b446dfa04d79d359","g":"a8e05e4b1a8a8e5e","name":"Read every 1 seconds","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":350,"y":2320,"wires":[["4c5449af7a4dd6ef"]]},{"id":"18630deedc38af9f","type":"inject","z":"b446dfa04d79d359","g":"a8e05e4b1a8a8e5e","name":"Manual Stop","props":[{"p":"payload","v":"","vt":"date"},{"p":"topic","v":"","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":310,"y":2369,"wires":[["e8400461cd50b356"]]},{"id":"9ef4a745bd0194cf","type":"debug","z":"b446dfa04d79d359","g":"a8e05e4b1a8a8e5e","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":990,"y":2340,"wires":[]},{"id":"cf84add540c079ce","type":"change","z":"b446dfa04d79d359","g":"a8e05e4b1a8a8e5e","name":"Reset","rules":[{"t":"set","p":"command","pt":"msg","to":"reset","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":570,"y":2420,"wires":[["81365fac1ccf6299"]]},{"id":"35ab3bbb1674b4f6","type":"inject","z":"b446dfa04d79d359","g":"a8e05e4b1a8a8e5e","name":"Manual Reset","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":310,"y":2420,"wires":[["cf84add540c079ce"]]},{"id":"5191dd25898c631c","type":"global-config","env":[],"modules":{"node-red-contrib-hourglass":"1.5.0"}}]
```
::

## Implementing a Countdown Timer

Countdown timers trigger actions after a specified duration. Common applications include scheduled maintenance windows, batch process timeouts, and timed equipment shutdowns.

To implement a countdown, we will use `node-red-contrib-countdown`.

#### Installing the Countdown Node

Install the **countdown node** in your Node-RED instance:

1. Open the Node-RED editor
2. Click the hamburger menu (top right) and select &#x2A;*"Manage palette"**
3. Go to the "Install" tab
4. Search for `node-red-contrib-countdown`
5. Click &#x2A;*"Install"**

The countdown node will appear in your palette.

### Building a Countdown Timer

Create a **countdown timer flow** in Node-RED:

1. Drag an **Inject** node onto the canvas.
2. Add a Change node and configure it to:
   - Set `msg.payload` to the countdown duration in **seconds** (for example, `50` for 50 seconds).
   - Set `msg.topic` to `"control"`.
   - You can configure the countdown duration either in the **Change** node or directly in the Inject node, as long as `msg.payload` is in milliseconds and `msg.topic` is `"control"`.
3. Drag a **Countdown** node onto the canvas and configure it with the following settings:
   - **Timer On payload**: The message payload sent when the countdown starts (for example, `true`).
   - **Timer Off payload**: The message payload sent when the countdown completes (for example, `false`).
   - **Restart countdown if message is received while running**: Enable this to restart the countdown if a new control message is received.
   - **Send output message on Reset**: Enable this to send a message when the countdown is reset.
   - **Set time to new duration if control message is received while running**: Enable this to update the countdown duration while it is running.
   - **Start countdown if control message is received while not running**: Enable this to start the countdown using a control message, enable it for this example to allow starting countdown when control message recived
4. Connect the Change node to the **Countdown** node.
5. Add a **Debug** node and connect it to the Countdown node output.
6. Click **Deploy** to activate the flow.

When you trigger the Inject node, the **countdown starts**. The Countdown node outputs messages at regular intervals, and the **second output** shows the remaining time.

![Countdown node output showing remaining time updates](https://flowfuse.com/blog/2025/12/images/countdown.png){dataZoomable=""}*Countdown node output showing remaining time updates*

From the first output, it will send the message you configured at the start of the count and at the end of the countdown.

Below is the flow implementation that you can use as a starting point.

::render-flow{:height='300'}
```json
[{"id":"13e3937b0555d34d","type":"group","z":"b446dfa04d79d359","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["0a7fdceb7b844c76","b1d36b608bafb531","e7e0894b2832e93e","52d0abe15e3533c8","c48dcaec998440aa"],"x":134,"y":3419,"w":692,"h":122},{"id":"0a7fdceb7b844c76","type":"countdown","z":"b446dfa04d79d359","g":"13e3937b0555d34d","name":"","topic":"","payloadTimerStart":"true","payloadTimerStartType":"bool","payloadTimerStop":"false","payloadTimerStopType":"bool","timer":"30","resetWhileRunning":false,"outputOnReset":false,"setTimeToNewWhileRunning":false,"startCountdownOnControlMessage":true,"x":550,"y":3480,"wires":[["e7e0894b2832e93e"],["52d0abe15e3533c8"]]},{"id":"b1d36b608bafb531","type":"inject","z":"b446dfa04d79d359","g":"13e3937b0555d34d","name":"Start","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":230,"y":3480,"wires":[["c48dcaec998440aa"]]},{"id":"e7e0894b2832e93e","type":"debug","z":"b446dfa04d79d359","g":"13e3937b0555d34d","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":690,"y":3460,"wires":[]},{"id":"52d0abe15e3533c8","type":"debug","z":"b446dfa04d79d359","g":"13e3937b0555d34d","name":"Countdown","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":710,"y":3500,"wires":[]},{"id":"c48dcaec998440aa","type":"change","z":"b446dfa04d79d359","g":"13e3937b0555d34d","name":"Set Countdown","rules":[{"t":"set","p":"payload","pt":"msg","to":"50","tot":"num"},{"t":"set","p":"topic","pt":"msg","to":"control","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":380,"y":3480,"wires":[["0a7fdceb7b844c76"]]},{"id":"66be08ead79304bf","type":"global-config","env":[],"modules":{"node-red-contrib-countdown":"1.3.2"}}]
```
::

For this demonstration, we used an inject node to manually trigger the countdown. In production environments, you would replace this with actual process triggers, **equipment status signals** from [PLCs](https://flowfuse.com/blog/2025/10/plc-to-mqtt-using-flowfuse/), [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/) messages from sensors, or completion signals from upstream operations. For example, you might start a **maintenance window countdown** when equipment reaches a scheduled service interval, or initiate a cleanup cycle timer when a batch process completes.

While these examples cover the essential timer operations, both nodes offer additional configuration options. For comprehensive documentation, visit the [node-red-contrib-hourglass](https://flows.nodered.org/node/node-red-contrib-hourglass){rel="&#x22;nofollow&#x22;"} and [node-red-contrib-countdown](https://flows.nodered.org/node/node-red-contrib-countdown){rel="&#x22;nofollow&#x22;"} pages on the **Node-RED flows library**.

# Conclusion

That's it, you now have working **stopwatch** and **countdown timers** in Node-RED. The hourglass node tracks elapsed time, and the countdown node triggers actions after a set duration.

These implementations are ready for production use. Start with these basic patterns, test them in your environment, and expand as needed. Connect them to your **PLCs**, add dashboard displays, or integrate with your existing automation workflows.

Both nodes are actively maintained and used in real industrial systems, so you're building on proven foundations.


# How to Access Optimized Data Blocks in TIA Portal (S7-1200/1500)

When working with Siemens S7-1200 and S7-1500 PLCs, you’ll notice that TIA Portal creates optimized data blocks by default. Unlike the classic S7-300/400 controllers, optimized blocks do not use fixed memory offsets. Instead, the PLC compiler reorganizes the data internally for better performance and memory efficiency. This architectural change often creates confusion when trying to read PLC data from external systems.

FlowFuse simplifies this challenge by providing a modern way to connect OT and IT systems and build industrial applications using a low-code, drag-and-drop approach. However, reading optimized data blocks still requires a different access method than traditional S7 communication.

You can disable optimization in TIA Portal by unchecking the "Optimized block access" option in your data block properties. This gives you the old-style addressing where you can read data using fixed offsets like `DB1.DBW0`. However, this approach has several drawbacks. Optimized blocks run faster, use less memory, and follow Siemens' current best practices. If you're working on existing projects with thousands of tags, converting everything to standard blocks isn't practical. Many companies also require optimized blocks as part of their coding standards.

This guide shows you how to read optimized data blocks directly without disabling optimization. You'll learn to use symbolic addressing, which is the proper way to access data from modern Siemens PLCs.

## Why Reading Optimized Data Blocks Is Challenging

**The S7 Protocol Problem**

Traditional S7 communication, which most Node-RED S7 nodes use, relies on absolute memory addresses. You read data by specifying exact locations like `DB1,INT0` (read integer at byte 0) or `DB5,REAL10` (read real at byte 10).

This worked fine with classic S7-300/400 controllers where memory layout was predictable. If you declared an integer first in your data block, it always started at byte 0. Simple and reliable.

**What Optimization Breaks**

Optimized data blocks rearrange variables for better performance and memory efficiency. The compiler groups variables by type, adds alignment padding, and reorders declarations. Your variable positions become unpredictable and can change with each recompile.

Example: You create variables Temperature (Real), Status (Bool), Pressure (Real), Alarm (Bool). Instead of sequential storage, the optimizer might group the two Real values together and pack Bools elsewhere. The Status boolean isn't at byte 4 anymore, it could be anywhere.

**Why S7 Nodes Fail**

Node-RED packages like `node-red-contrib-s7` need exact memory addresses. With optimized blocks:

- TIA Portal doesn't show you the actual memory layout
- Offsets can't be reliably determined
- Recompiling your PLC program silently breaks all your addresses
- The S7 protocol has no way to read variables by name

You're stuck guessing at memory locations that keep changing.

## The Solution: OPC UA

OPC UA reads variables by name, not memory address. Instead of asking "what's at byte 10?" it asks "what's the value of Temperature\_Sensor\_01?"

Siemens S7-1200 and S7-1500 PLCs have built-in OPC UA server. Activate it in TIA Portal, mark which variables to expose, and the PLC handles all memory mapping internally. FlowFuse connects and reads data by variable name, regardless of how the PLC organizes memory.

When you modify your data block or recompile, your flows keep working because they reference variable names, not memory locations that might shift.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

## Prerequisites

Before you begin, make sure you have:

- TIA Portal V13 or later, and you know how to download a program to your PLC
- A Siemens S7-1200 or S7-1500 PLC with OPC UA server support
- A [FlowFuse Agent](https://flowfuse.com/blog/2025/09/installing-node-red/) running on your edge device
- The PLC and edge device connected to the same network

## Step 1: Activate OPC UA Server on Your PLC

First, you need to activate the OPC UA server that's built into your S7-1200/1500 PLC.

1. Launch TIA Portal and open your project
2. In the project tree on the left, select your PLC and double-click it
3. Find **OPC UA** in the device properties (usually under General or Properties section)
4. Check **Activate OPC UA Server**

![Activate OPC UA server option in TIA Portal](https://flowfuse.com/blog/2025/12/images/enable-opcua-server.png){dataZoomable=""}*Activate OPC UA server option in TIA Portal*

5. Set **Port** to `4840` (the standard OPC UA port)
6. Set **Security Policy** to **None** (for testing only)
7. Enable **Guest authentication**.

> *Note that we've disabled security entirely in steps 6-7 to get you up and running quickly. This is fine for learning and testing, but don't leave it this way. Before moving to production, configure proper authentication with certificates and user credentials. Get the communication working first, then secure it.*

## Step 2: Add OPC UA Server Interface

Before exposing variables, you need to create an OPC UA server interface in your PLC configuration.

**For S7-1500 PLCs (firmware V2.5 or higher):**

If you're using an S7-1500 PLC with firmware version 2.5 or higher, you have the option to enable the standard SIMATIC server interface. Simply check **Enable standard SIMATIC server interface** in the OPC UA settings. This automatically makes all PLC tags that are marked as accessible available through OPC UA.

**For S7-1200 PLCs (or manual configuration for S7-1500):**

For S7-1200 PLCs, you must manually create a server interface and add the tags you want to expose:

1. In TIA Portal, navigate to **OPC UA communication** in the project tree
2. Right-click on **Server interfaces**
3. Select **Add new server interface**

![Adding OPC UA server interface in TIA Portal](https://flowfuse.com/blog/2025/12/images/add-server-interface.png){dataZoomable=""}*Adding OPC UA server interface in TIA Portal*

4. Leave the default settings and click OK
5. The server interface will be created (you can rename it if needed)

Now this interface needs to know which data blocks to expose.

## Step 3: Expose Your Data Block Variables

For OPC UA to access your data blocks, you need to mark them as accessible.

**First, enable OPC UA access on your data blocks (required for all methods):**

1. Open your data block in TIA Portal
2. Right-click on the data block name in the project tree
3. Select **Properties**
4. Go to the **Attributes** tab
5. Check **Accessible from HMI/OPC UA** and **Optimized Block Access**
6. Click **OK**

![Attribute settings for optimized and OPC UA accessible data blocks](https://flowfuse.com/blog/2025/12/images/optimized-db-and-accessbile-via-opcua-option.png){dataZoomable=""}*Attribute settings for optimized and OPC UA accessible data blocks*

**If using S7-1500 with standard SIMATIC server interface:**

You're done. All variables in data blocks marked as accessible are now automatically available through OPC UA.

**If using manual server interface (S7-1200 or S7-1500):**

You need one more step to add specific variables to your server interface:

1. In the project tree, expand **OPC UA communication**
2. Expand your server interface
3. Drag and drop variables from the **OPC UA elements** panel (on the right) into your server interface table
4. Alternatively, right-click **Variables** and select **Add new variable**, then browse to select them

![Tags added inside OPC UA server interface](https://flowfuse.com/blog/2025/12/images/tags-added-in-the-server-interface.png){dataZoomable=""}*Tags added inside OPC UA server interface*

**Compile and download:**

5. Click **Compile** in TIA Portal
6. Download the program to your PLC

Your OPC UA server is now running with the exposed variables ready for access.

## Step 4: Install OPC UA Client in FlowFuse

Now switch to your FlowFuse instance to set up the connection to your PLC.

1. Open your FlowFuse editor
2. Click the menu icon (three horizontal lines, top right)
3. Select **Manage palette**
4. Go to the **Install** tab
5. In the search box, type `node-red-contrib-opcua`
6. Find the package in the results and click **Install**
7. Confirm the installation when prompted
8. Close the palette manager

The OPC UA nodes will now appear in your node palette on the left side under the "opcua" category.

## Step 5: Configure OPC UA Connection

Create a new flow to connect to your PLC and read data.

1. Drag an **OpcUa-Client** node onto your canvas
2. Double-click it to open the configuration
3. Click the pencil icon next to **Endpoint** to add a new connection
4. Enter the endpoint URL: `opc.tcp://[YOUR_PLC_IP]:4840`
   - Replace `[YOUR_PLC_IP]` with your actual PLC IP address (e.g., `opc.tcp://192.168.1.10:4840`)
5. Set **Security Policy** to **None**
6. Set **Security Mode** to **None**
7. Under **Authentication**, select **Anonymous**
8. Click **Add** to save the endpoint
9. Click **Done** to close the node configuration

Your OPC UA client is now configured to connect to your PLC.

## Step 6: Browse Available Variables

Now it's time to discover what's actually available on your PLC. Think of this like opening a file explorer to see what's inside.

1. Drag an **Inject** node onto your canvas
2. Drag an **OpcUa-Browser** node onto the canvas
3. Drag a **Debug** node onto the canvas
4. Connect the Inject node to the OpcUa-Browser node, then connect the OpcUa-Browser node to the Debug node
5. Double-click the **OpcUa-Browser** node to open its configuration
6. In the **Endpoint** dropdown, select the connection you created in Step 5
7. Leave the **Action** field set to **browse**
8. Click **Done**
9. Click **Deploy** in the top-right corner
10. Click the inject node button
11. Open the **Debug** panel on the right side
12. You'll see a structured tree showing everything your PLC is sharing

## Step 7: Read Your First Variable

Let's prove this actually works by reading real data from your PLC.

1. Drag an **Inject** node onto your canvas
2. Double-click the Inject node to configure it
3. Change **Repeat** from "none" to **interval**
4. Set it to repeat **every 5 seconds**
5. In the **Topic** field, enter the NodeId you copied (e.g., `ns=3;s="Demo_Datablock"."Temperature"`)
6. Click **Done**
7. Drag an **OpcUa-Client** node onto the canvas
8. Double-click the OpcUa-Client node to open its configuration
9. Select your endpoint from the **Endpoint** dropdown
10. Change **Action** to **read**
11. Click **Done**
12. Drag a **Debug** node onto the canvas
13. Double-click the Debug node
14. Change the output to **complete msg object**
15. Click **Done**
16. Connect the Inject node to the OpcUa-Client node, then connect the OpcUa-Client node to the Debug node
17. Click **Deploy**
18. Open the Debug panel on the right side
19. You'll see messages appearing every 5 seconds with your variable's value in `msg.payload`

Try changing the value in your PLC through TIA Portal and watch the updates appear in FlowFuse. No memory addresses, no offset calculations, just the variable name.

To explore more OPC UA capabilities like subscribing to value changes, writing data back to your PLC, and working with complex data types, check out our [article](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/).

## Scale Your Industrial Applications with FlowFuse

You've successfully read data from your Siemens PLC, but FlowFuse does much more than connect to a single device. The platform helps you build complete industrial applications that connect to any equipment, collect and transform data from across your factory floor, visualize it in real-time dashboards, and take automated actions based on what's happening in your operation.

FlowFuse makes deployment and management simple, even at scale. Develop your application once, then deploy it to thousands of edge devices across multiple facilities. Manage all your instances from one central platform, push updates, monitor performance, and troubleshoot remotely without visiting each site. Built-in security features protect your industrial data, while horizontal and vertical scaling ensures your applications grow with your business needs.

Whether you're building a predictive maintenance system, a production monitoring dashboard, or a complete MES solution, FlowFuse provides the unified platform to connect, collect, transform, visualize, and act on your industrial data.

Ready to scale beyond a single PLC? [Book a demo](https://flowfuse.com/book-demo/) to see how FlowFuse can transform your industrial operations.


# What Is a PLC (Programmable Logic Controller)? What It Does, How It Works, and Where It's Used

***A PLC (Programmable Logic Controller) is an industrial computer that continuously monitors sensors, executes control logic, and operates motors, valves, and equipment in real time, serving as the reliable backbone of modern manufacturing and industrial automation.***

On New Year's Day 1968, [Dick Morley](https://en.wikipedia.org/wiki/Dick_Morley){rel="&#x22;nofollow&#x22;"} woke up with a brutal hangover and wrote the specification that would replace relay logic in factories worldwide. Nursing what he later described as a wicked headache, he defined a device that could run a production line, survive a factory floor, and be reprogrammed without anyone touching a wire.

Before that morning, changing how a factory operated meant physically rewiring thousands of electromagnetic relays. General Motors was losing weeks of production and millions in labor costs every time it retooled a line. Morley's design turned that into a software change.

Today PLCs control the assembly of the car you drive, the batch that produced your medication, and the pumps that treat your drinking water. They run power substations, traffic systems, and semiconductor fabs. It is a [$13 billion market](https://www.mordorintelligence.com/industry-reports/programmable-logic-controller-plc-market){rel="&#x22;nofollow&#x22;"}, and most people have never heard of the technology.

This article covers what a PLC actually is, what sits inside one, how the scan cycle works, how PLCs are programmed, the types available, where they run, and the problem that dominates industrial automation projects today: getting controllers from different vendors to share their data.

## What is a PLC (Programmable Logic Controller)?

A Programmable Logic Controller is an industrial computer built for one job: controlling machines and processes in real time with high reliability. Unlike a laptop or a cloud server, a PLC operates in conditions that destroy standard computers, including temperature extremes, constant vibration, electrical noise, dust, and humidity.

The concept is simple. A PLC reads inputs from sensors and switches, executes logic from its stored program, and updates outputs that drive motors, valves, lights, and equipment. It repeats that loop continuously, hundreds or thousands of times per second. Read inputs. Run logic. Update outputs. Repeat.

What sets a PLC apart is not computing power. Your phone outperforms every PLC ever built. It is deterministic execution. The program runs the same way, in the same order, in a predictable amount of time, on every single scan. No operating system decides to install an update. No background process steals a time slice. In a plant where a missed decision means a ruined batch, a damaged machine, or an injured operator, that predictability is the entire product.

The hardware reflects the same priority. Industrial-grade components tolerate heat and electrical interference. Power supplies absorb the voltage sags and spikes that come with starting large motors. I/O modules interface directly with field devices at industrial voltages and currents, with isolation so a fault in the field does not reach the processor. The programming languages are visual and built around relay diagrams, because the people who commission and maintain these systems are controls engineers and electricians, not software developers.

That design has barely changed since 1968, and the reason is straightforward: it works. A PLC installed in a chemical plant runs for decades. A controller in an automotive body shop executes millions of cycles without a fault. Industrial automation never adopted "move fast and break things." The operating principle here is narrower: do not break.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

## History of PLCs: from relay rooms to smart controllers

Before PLCs, control logic lived in walls of electromagnetic relays. Thousands of mechanical switches, wired together, defined how a machine behaved. Changing a process meant rewiring a cabinet by hand. Every model change brought weeks of downtime, crews of electricians, and a real chance that one wrong wire would stop the plant.

![Pre-PLC industrial relay control cabinet used in factories before programmable logic controllers replaced hard-wired relay logic](https://flowfuse.com/blog/2025/12/images/pre-plc-relay-cabinet.jpg){dataZoomable=""}&#x2A;A relay control cabinet of the kind PLCs replaced. Every logic change here meant physically rewiring the panel.*

By the late 1960s that inflexibility was becoming untenable, especially in automotive. Meanwhile Dick Morley was running Bedford Associates, a small consultancy helping machine tool firms move to solid-state controls. The work paid, but every project was a variation on the last.

On New Year's Day 1968, hungover and two weeks late on yet another proposal, Morley wrote a specification for something he called a Programmable Controller: a device that could replace relay logic, survive factory conditions, and be reprogrammed without rewiring. His requirements were specific. No processing interrupts. Direct memory mapping. A sealed, rugged enclosure cooled by heat sinks rather than fans. A programming language modeled on relay diagrams, which became ladder logic. He also specified that it should run slowly, a decision he later regretted.

Morley took the memo to his colleagues at Bedford Associates and gave them one rule: never call it a computer. If he found that word on a document, he threw the document away. They built a sealed unit with metal fin heat sinks and named it the Model 084, Bedford's eighty-fourth project.

To commercialize it, the team formed a new company in October 1968 and called it **Modicon**, short for Modular Digital Controller. Morley was never formally an employee, but he ran engineering. The Model 084 shipped in 1969, followed by the Model 184, which fixed the problems the first units exposed.

General Motors placed a million-dollar order, and in November 1969 its Hydramatic Division took delivery of the first batch. General Electric followed with an order of its own, planning to rebrand the controllers as OEM units. Within a year of Modicon's founding, the PLC had gone from a hungover memo to production deployment at the world's largest automaker.

![PLC Pioneers Richard Morley, Tom Bossevain, George Schwenk and Jonas Landau](https://flowfuse.com/blog/2025/12/images/First-modicon-084.png){dataZoomable=""}&#x2A;The team behind the first Modicon 084: Richard Morley, Tom Boissevain, George Schwenk, and Jonas Landau.*

Morley always called himself the father of the PLC rather than its inventor. He knew other groups were chasing the same problem and believed the technology invented itself out of necessity. Modicon was later acquired and now sits inside Schneider Electric, which still uses the number 84 on products as a nod to where it started.

## What's inside a PLC: the 7 main parts

Open a PLC cabinet and you will find a metal assembly on a DIN rail, covered in wire terminals, with no monitor, no keyboard, and no fan. Seven functional parts do all the work.

**1. Power supply.** Converts plant power into the clean, stable DC the processor and modules need. It is rated for abuse, because industrial power is chaotic: sags when large motors start, spikes from switching, and harmonics from variable frequency drives.

**2. Central processing unit (CPU).** Executes the control program. Modern PLCs use industrial microprocessors chosen for temperature tolerance and long-term availability rather than raw speed. The CPU also runs self-diagnostics and manages the scan cycle.

**3. Memory.** Holds the program and the data it works on. Non-volatile memory retains the compiled program and retentive values through a power cycle. Volatile working memory holds the I/O image table, timers, counters, and intermediate results for the current scan.

**4. Input modules.** Convert field signals into values the CPU can read. A limit switch closes a 24 V DC circuit. A temperature transmitter sends 4-20 mA. A pressure sensor outputs 0-10 V. Digital input modules report on or off. Analog input modules digitize a continuous range. Both provide electrical isolation so field noise and ground loops never reach the processor.

**5. Output modules.** Drive the physical world. When the program decides a motor should run, the output module closes a relay, switches a transistor, or sends an analog signal to a drive. Digital outputs handle contactors, solenoids, and indicators. Analog outputs set valve positions and drive speed references.

**6. Communication interface.** Connects the PLC to everything else: HMIs, SCADA systems, other PLCs, drives, remote I/O, and IT systems. This is usually an Ethernet port plus one or more fieldbus ports, and it is where most of the difficulty in modern automation projects lives.

**7. Programming device.** The laptop and vendor software you use to write, download, and debug the program. It also provides online monitoring, so you can watch logic execute live while the machine runs.

Small PLCs integrate all seven into one sealed housing. Large systems distribute them across a rack, so you can add I/O, swap a failed module, or scale the system without replacing the controller.

## How a PLC works: the scan cycle

Every PLC runs the same four-step loop, over and over, for as long as it is powered.

1. **Input scan.** The PLC copies the state of every input into memory at once. That snapshot is what the program reads, so a sensor changing mid-program cannot produce inconsistent behavior.
2. **Program execution.** The controller runs the control logic from first instruction to last, using the snapshot. &#x2A;If temperature exceeds 250 °F, open the cooling valve. If a part is present and the quality check passed, advance the conveyor.*
3. **Output update.** The PLC writes all calculated results to the physical output modules at once. Motors start. Valves move. Nothing updates partway through the logic.
4. **Housekeeping.** The controller handles communications, diagnostics, and error checking, then starts the next scan immediately.

A full cycle typically takes 1 to 50 milliseconds depending on program size and CPU. A 10 ms scan means the controller makes a hundred complete decisions per second, every second, for years.

This structure eliminates whole categories of software bug by design. Inputs cannot change mid-program. Outputs cannot update while logic is still evaluating. Race conditions do not occur. Two engineers reading the same program reach the same conclusion about what it will do, which matters enormously when the person troubleshooting at 3 a.m. is not the person who wrote it.

Scan time also sets a hard limit you have to design around. If the fastest event you need to catch is shorter than your scan time, the PLC will miss it. That is why high-speed counting, motion control, and safety functions typically move to dedicated modules that operate outside the normal scan.

## PLC programming languages

PLCs do not run Python or C++. They run the [IEC 61131-3](https://en.wikipedia.org/wiki/IEC_61131-3){rel="&#x22;nofollow&#x22;"} languages, designed for controls engineers.

**Ladder logic** looks like a relay wiring diagram, because it replaced relay wiring diagrams. Two vertical rails represent power. Contacts (conditions) and coils (outputs) sit on horizontal rungs between them. Here is a motor start/stop circuit, the first thing most engineers learn:

```text
    Start_PB      Stop_PB     Overload      Motor_Run
 ─────┤ ├──────────┤/├─────────┤/├────────────( )─────
      │
    Motor_Run
 ─────┤ ├──┘
```

Pressing the start button energizes `Motor_Run`. The parallel `Motor_Run` contact then holds the rung true after the operator releases the button, which is called a seal-in. Pressing stop or tripping the overload breaks the rung and the motor drops out. Ladder logic is clumsy for mathematics and excellent for exactly this kind of discrete, interlocked control.

**Function block diagram** wires together boxes representing timers, counters, math operations, and PID loops. Data flows left to right between blocks. It suits continuous process control, where analog values need scaling, filtering, and regulation.

**Structured text** is a Pascal-like textual language for calculations, loops, and algorithms that would be unreadable in ladder. Recipe handling, data manipulation, and communication logic usually end up here.

**Sequential function chart** models a process as steps and transitions, which fits batch operations and machine sequences with clearly defined states.

The standard is common, but the implementations are not. Siemens uses TIA Portal. Rockwell uses Studio 5000. Schneider uses EcoStruxure Control Expert. Mitsubishi uses GX Works. Programs are theoretically portable between platforms and practically are not, which is the first form of vendor lock-in an automation team encounters.

## PLC vs PC, PAC, microcontroller, and DCS

"Why not just use a PC?" is a reasonable question with a specific answer, and the same applies to the other options.

|                     | Best at                                                          | Determinism                                         | Environment                                     | Typical lifespan  |
| ------------------- | ---------------------------------------------------------------- | --------------------------------------------------- | ----------------------------------------------- | ----------------- |
| **PLC**             | Discrete machine and line control                                | Guaranteed scan time                                | Panel-mounted, -20 to 60 °C, vibration tolerant | 20-30 years       |
| **PAC**             | Control plus data handling, motion, and vision in one controller | Guaranteed for control tasks                        | Same as PLC                                     | 15-25 years       |
| **Industrial PC**   | Data processing, analytics, visualization, edge workloads        | Not guaranteed under a general-purpose OS           | Rugged variants available                       | 5-10 years        |
| **Microcontroller** | Embedded control inside a product                                | Deterministic, but no industrial I/O or diagnostics | Depends entirely on the board                   | Product-dependent |
| **DCS**             | Continuous process control across a whole plant                  | Guaranteed, with plant-wide engineering             | Control room and field cabinets                 | 20-30 years       |

The practical read: a PC will out-compute a PLC by orders of magnitude and still be the wrong choice for driving a press, because an operating system that can pause your logic for 200 milliseconds is not a control system. Conversely, a PLC is the wrong place to run a machine learning model or a historian. Well-designed plants use both and connect them, which is where the rest of this article ends up.

## Types of PLCs

All PLCs run the same scan cycle. The hardware scales enormously depending on what they control.

### Micro PLCs

Micro PLCs handle very small tasks, typically 8 to 20 I/O points: a single conveyor, pump, sorter, or door. They generally cost [[]{.katex-mathml}[[[]{.strut style="height:0.6444em;"}[100]{.mord}[t]{.mord.mathnormal}[o]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 500 and appear in car washes, vending machines, irrigation systems, and OEM equipment. Programming environments are simplified and focused on basic logic.

**Examples:** Unitronics Jazz, AutomationDirect CLICK, IDEC SmartRelay

### Compact PLCs

Compact PLCs integrate the CPU, I/O, and power supply into one fixed unit, usually covering 10 to 100 I/O points. They suit packaging machines, pump stations, and HVAC plant. Many accept a limited number of add-on I/O modules, but once you exhaust that expansion you are looking at a modular platform instead.

**Examples:** Siemens S7-1200, Rockwell Micro800, Schneider Modicon M221

### Modular PLCs

Modular PLCs separate the CPU from I/O modules mounted on expandable racks. Need several hundred I/O points? Add modules. Need motion control, high-speed counting, redundancy, or a specific fieldbus? There is a module for it. This is the standard for automotive assembly, chemical processing, and large material handling. Costs run from roughly $10,000 to well into six figures depending on scale and redundancy.

**Examples:** Siemens S7-1500, Rockwell ControlLogix, Schneider Modicon M580

### Safety PLCs

Safety PLCs protect people and equipment. They handle emergency stops, light curtains, safety interlocks, and guard door monitoring using redundant processors and continuous self-diagnostics. Certified architectures reach SIL 3 and Performance Level e, with failure rates in the range of 10⁻⁸ to 10⁻⁷ per hour for continuous operation. In most plants the safety PLC runs alongside the standard controller: production logic on one, safety functions on the other, with the safety system able to override everything the instant it detects a hazard.

**Examples:** Pilz PNOZmulti, Siemens F-series, Rockwell GuardLogix

### Choosing the right PLC

Selection comes down to I/O count, logic complexity, safety requirements, and how much you expect the system to grow. Fewer than 20 I/O points with simple logic points to micro or compact. Production lines with hundreds of points, motion control, or serious networking need modular. Anything protecting a person requires a safety-rated controller, without exception.

One factor outweighs the technical comparison: most organizations standardize on a single vendor and stay there for decades, because retraining engineers and rewriting a program library is more expensive than the hardware. That decision is usually made once and lived with for a very long time.

Worth separating, though, is the control layer from the data layer. Committing to Siemens or Rockwell for the next twenty years of machine control is a defensible engineering decision. Letting that choice also dictate how production data reaches your historian, your ERP, or your quality team is not, and it is the part teams tend to concede without noticing. Keeping [the integration layer vendor-neutral](https://flowfuse.com/use-cases/it-ot-middleware/) means the controller standard you pick today does not decide what you can build on top of it in five years.

## PLC, HMI, and SCADA: how they work together

A PLC executes logic in milliseconds and has no screen. It cannot show an operator what is happening, log history, or send an alert. That is where HMIs and SCADA systems come in, and the three form distinct layers.

**PLCs** control equipment in real time: read sensors, run logic, drive actuators.

**HMIs** (Human-Machine Interfaces) are the touchscreens mounted at the machine. They display what the PLC is doing and let operators start equipment, adjust setpoints, and acknowledge alarms. The HMI sends a request; the PLC evaluates interlocks and decides whether to act. One HMI typically covers one machine or one section of a line.

**SCADA** (Supervisory Control and Data Acquisition) operates at facility level. It polls dozens or hundreds of PLCs, stores trends, generates reports, and coordinates system-wide operations. A water utility with 50 pump stations runs a PLC at each one and a SCADA system in the control room that shows all 50 at once.

In practice: PLCs sit in cabinets, HMIs sit at machines, SCADA runs on servers. When a PLC detects a high temperature, the local HMI raises an alarm and SCADA logs it with a timestamp and notifies maintenance.

This hierarchy works well for operations. It starts to strain the moment someone outside operations wants the data, and that request always comes. Quality wants defect rates by shift. Maintenance wants runtime hours per asset. Finance wants energy cost per unit. None of those systems speak to a PLC, and SCADA was never designed to feed them.

> Most teams solve this one request at a time, and a year later they have thirty point-to-point connections nobody can map. The decision that saves the most rework is how you structure PLC data before you wire up the first system, not after. That is what a [unified namespace](https://flowfuse.com/use-cases/uns/) is for: every application reads from one place, so adding the next one costs a topic subscription instead of another integration project.

## Where PLCs actually run: real-world applications

PLCs control processes where reliability is not negotiable. They are invisible by design and often outlast the engineers who commissioned them.

**[Automotive assembly](https://flowfuse.com/industries/automotive/)** lines coordinate welding robots, conveyors, and quality gates. A body shop may run 50 or more PLCs managing hundreds of welds per vehicle. Retooling for a new model means reprogramming controllers instead of rewiring panels, which is precisely what GM needed in 1968.

**[Pharmaceutical production](https://flowfuse.com/industries/life-sciences/)** relies on PLCs for batch reactors where temperature, pressure, and timing must stay inside validated ranges. Every parameter is logged for regulatory compliance, and the controller flags any batch that drifts out of specification.

**[Food and beverage](https://flowfuse.com/industries/food-beverage/)** plants run mixing, cooking, filling, capping, labeling, and case packing. A single bottling line coordinates all of it, executing the same programs millions of times.

**Water treatment** plants manage pumps, chemical dosing, and filtration against flow and quality sensors. These systems commonly run 20 to 30 years, absorbing daily demand swings automatically.

**Power substations** use PLCs for load monitoring, breaker control, and grid coordination, adjusting within milliseconds as generation and demand shift. The same controllers run inverter and turbine skids across [renewable generation sites](https://flowfuse.com/industries/renewables/), where output varies by the minute.

**Refineries and chemical plants** manage temperatures, pressures, and emergency shutdown sequences in environments where a control failure is a safety event.

**Distribution centers** run conveyor networks, sorters, and automated storage. A package is scanned, routed, and diverted to the correct lane through thousands of decisions per hour.

**Airport baggage systems** are entirely PLC-controlled, moving bags from check-in through screening to the right carousel by destination and departure time.

**Mining operations** run conveyors, crushers, and separation equipment continuously with minimal supervision, monitoring equipment health and shutting down automatically on fault.

The common thread is long-term reliability in demanding conditions. Controllers installed in the 1990s are still running in many of these facilities, executing the same logic, scan after scan, exactly as designed.

## How PLCs communicate

A PLC on its own is a closed loop. The moment you want data out of it, or want two controllers to coordinate, you enter the protocol layer, and this is where most automation projects actually spend their budget.

PLC communication happens at four rough levels.

**Fieldbus, device level.** Modbus RTU, Profibus DP, DeviceNet, and IO-Link connect sensors, drives, and remote I/O over serial or dedicated cabling. Still everywhere in brownfield plants, and often the only interface on older equipment.

**Industrial Ethernet.** Profinet (Siemens), [EtherNet/IP](https://flowfuse.com/blog/2025/10/using-ethernet-ip-with-flowfuse/) (Rockwell and Omron), EtherCAT (Beckhoff), and Modbus TCP carry real-time control traffic over standard Ethernet hardware with deterministic timing. This is what new installations use.

**Vendor-native protocols.** Each manufacturer has a protocol for reading and writing its controller's memory directly: S7comm for Siemens, CIP for Rockwell, ADS for Beckhoff, MC Protocol for Mitsubishi, FINS for Omron. Fast, well-documented, and completely incompatible with each other.

**Standards-based and IT-facing.** [OPC UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/) provides a vendor-neutral, secure, structured interface that most modern PLCs expose directly. MQTT, often with Sparkplug B, carries data to brokers, cloud platforms, and unified namespaces. REST APIs and SQL connections handle the rest.

Here is what that looks like in a plant with mixed equipment:

| Vendor           | Common controller           | Native protocol      | Standards option                     |
| ---------------- | --------------------------- | -------------------- | ------------------------------------ |
| Siemens          | S7-1200 / S7-1500           | S7comm, Profinet     | OPC UA server built in               |
| Rockwell         | CompactLogix / ControlLogix | EtherNet/IP (CIP)    | OPC UA via gateway or newer firmware |
| Beckhoff         | CX series                   | ADS, EtherCAT        | OPC UA server available              |
| Mitsubishi       | MELSEC iQ-R / FX            | MC Protocol, CC-Link | OPC UA via module                    |
| Omron            | NX / NJ                     | FINS, EtherNet/IP    | OPC UA on select models              |
| Legacy equipment | Various                     | Modbus RTU/TCP       | None                                 |

Most facilities run at least three of these rows simultaneously. A line installed in 1998, a cell added in 2012, and a machine commissioned last quarter all need to appear in the same production report.

> Reading about protocols only gets you so far. If you have a controller on the bench, or a spare hour on a live line, this walkthrough goes tag by tag: [connect any PLC to MQTT in under an hour](https://flowfuse.com/blog/2025/10/plc-to-mqtt-using-flowfuse/). It handles Siemens S7, Allen-Bradley, OPC UA, and Modbus in a single flow, runs on a free account, and needs no gateway hardware sitting in the middle.

## The interoperability problem: when PLCs won't talk

Dick Morley solved machine control in 1968. As manufacturers raced to capture the market he created, each built a closed ecosystem around it, and vendor lock-in became the PLC's unintended legacy.

The consequences show up on every project.

**Every connection is a custom build.** Reading a production count from a Siemens controller and acting on it in a Rockwell one means writing a gateway, configuring a protocol converter, or buying a middleware licence. Do that for every pair of systems and the integration layer becomes larger than the applications it serves.

**Licensing scales with tags, not value.** Traditional data access is often priced per tag or per connection. A pilot on one line is affordable. Rolling out to forty lines rewrites the business case.

**Brownfield is the normal case, not the exception.** Because PLCs last 20 to 30 years, no plant gets to standardize. There is always a controller nobody wants to touch, running critical logic, with an interface that predates the current engineering team.

**Nobody owns the middle.** OT owns the controllers and will not accept anything that risks uptime. IT owns the databases and cloud and cannot get a route to the data. Integration work stalls in the gap between them.

**Each project starts from zero.** Solve production monitoring at one plant and the next plant rebuilds it, because the solution was wired to that site's specific mix of vendors. Twelve plants produce twelve incompatible "snowflake" implementations and no shared standard.

The cost is not only technical debt. It is strategic paralysis. Teams stay on one vendor not because it is the best fit, but because the switching cost has quietly become unpayable.

## Solving the PLC integration problem

Modern PLCs are not the hard part. Getting forty controllers from five vendors, installed across three decades, to feed one production report is.

[FlowFuse](https://flowfuse.com) is the open-source Industrial Application Platform built for exactly that layer. It connects any controller, whether that is Siemens, Allen-Bradley, Omron, Mitsubishi, or a legacy Modbus device, without proprietary gateways or per-tag licensing, then routes the data to MQTT, historians, databases, [dashboards](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/), and ERP systems. Your PLCs keep running their proven logic. What changes is that their data stops being trapped.

![FlowFuse platform for industrial data integration connecting PLCs, edge devices, and enterprise systems](https://flowfuse.com/blog/2025/12/images/flowfuse-platform.png){dataZoomable=""}&#x2A;FlowFuse connects controllers, edge devices, and enterprise systems from a single governed platform.*

Build the integration once, deploy it to every site, and manage it centrally instead of rebuilding a snowflake at each plant. See the [PLC integration overview](https://flowfuse.com/landing/plc/) for supported protocols and reference architectures, or [connect your first controller free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}.

Dick Morley's specification gave engineers a controller they could reprogram without touching a wire. The same freedom is now available for the integration layer above it.


# What is TEEP? Calculation, Benchmarks & TEEP vs OEE (2026)

Total Effective Equipment Performance (TEEP) is a manufacturing KPI used to understand how much of an equipment investment is actually being utilized. While most manufacturers rely on [Overall Equipment Effectiveness (OEE)](https://flowfuse.com/blog/2025/04/what-is-an-oee-dashboard/#what-is-oee) to assess shop-floor performance, years of real-world use have revealed a critical blind spot: OEE only measures how well equipment runs *when it is scheduled to run*. It says nothing about the many hours assets sit idle due to planning decisions, demand patterns, labor availability, or maintenance strategy.

This gap matters. In many factories, equipment represents the largest capital investment on the balance sheet, yet significant capacity remains unused outside scheduled production hours. TEEP addresses this gap by extending measurement beyond scheduled production and into total calendar time, providing visibility into both operational performance and unused capacity.

To understand how TEEP does this, it’s important to be precise about what the metric actually measures.

## What is TEEP?

TEEP measures the percentage of **total calendar time** that equipment spends producing good parts at the correct speed. Unlike OEE, which evaluates performance only during planned production, TEEP includes **every hour of the day**, whether production was scheduled or not. That means all 168 hours in a week and all 8,760 hours in a year are part of the calculation.

This distinction is fundamental. If a factory operates a single shift per day, OEE evaluates only those eight scheduled hours and ignores the remaining sixteen. TEEP counts them all. As a result, TEEP reveals how much of the equipment’s full potential is actually being used, not just how well it performs during active shifts.

## TEEP Formula and Calculation

The math works the same way as OEE:

**TEEP = Availability × Performance × Quality**

But availability now means operating time divided by total calendar time, not just scheduled time. If a production line runs 120 hours per week at full speed with no defects, it has 71.4% TEEP (120 divided by 168). The other 48 hours might be maintenance time, unplanned downtime, or time when no production was scheduled.

## Why TEEP Matters

TEEP matters because it connects operational performance to **business value**, not just shop-floor efficiency. While OEE shows how well equipment runs during scheduled shifts, it says nothing about how much of the asset you're actually using relative to what you paid for it. TEEP fills that gap.

:cta-image{alt="Arch Systems scales automation across complex manufacturing environments with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/arch-systems-book-demo.png"}

For capital-intensive manufacturing, this difference is critical. Equipment often represents millions in investment, yet much of that capacity may sit idle due to scheduling choices, demand patterns, labor availability, or maintenance strategy. TEEP makes this visible. It answers the executive-level question: &#x2A;*"Are we getting a return on our equipment, or is capacity hiding in plain sight?"**

TEEP is especially valuable when:

- Customer demand is increasing and capacity feels tight
- Management is considering adding shifts or buying new equipment
- Capital expenditure decisions need justification
- Different plants or lines need to be compared at a high level

In many cases, TEEP reveals that the fastest and cheapest way to increase output is not buying new machines, but better utilizing the ones already installed. A modest TEEP improvement can unlock significant production capacity without additional capital investment.

Importantly, TEEP is not about pushing equipment to run 24/7 at all costs. Instead, it provides the data needed to make **intentional, informed decisions** about scheduling, staffing, maintenance, and growth.

## TEEP vs OEE: Key Differences

OEE and TEEP both measure equipment performance, but they look at different things. The big difference is what time period they measure against.

| Feature                    | OEE                                              | TEEP                                               |
| -------------------------- | ------------------------------------------------ | -------------------------------------------------- |
| **What it measures**       | How well equipment runs during scheduled time    | How much of total time equipment actually produces |
| **Time counted**           | Only planned production hours                    | Every hour (24/7, all year)                        |
| **Who uses it**            | Production supervisors and operators             | Executives and plant managers                      |
| **Typical numbers**        | 60-85% is good                                   | 30-80% depending on shifts                         |
| **Main question answered** | "How efficiently did we use our scheduled time?" | "How much are we actually using this equipment?"   |

**Here's another simple example:**

Your packaging line runs one 8-hour shift per day, Monday through Friday. In one week:

- You scheduled 40 hours of production
- Equipment actually ran well for 34 hours
- **Your OEE: 85%** - Great! The production team did an excellent job during their shift.
- **Your TEEP: 20%** - The equipment was productive for 34 out of 168 total hours in the week.

Both numbers are correct and useful. OEE shows your production team is doing their job well. TEEP shows the equipment sits unused most of the time. Whether that's okay depends on customer demand, labor costs, and your business strategy.

## What Is a Good TEEP Score?

One of the most common questions manufacturers ask is: "What TEEP score should we target?" The answer depends entirely on your industry, shift strategy, and business model.

**Industry-Specific TEEP Benchmarks:**

- **Continuous process industries** (paper mills, chemical plants, refineries): 80-90% TEEP for critical equipment. These operations are designed for 24/7 production, and high TEEP reflects the economics of continuous processing.
- **Two-shift batch manufacturers** (automotive parts, packaging, electronics): 40-60% TEEP is typical. Even with excellent operational performance, running two 8-hour shifts five days per week caps theoretical maximum TEEP at 48%.
- **Single-shift operations** (job shops, specialized manufacturing): 25-35% TEEP is common and often optimal. Running one 8-hour shift per day limits maximum TEEP to about 24% even with perfect execution.

The key insight: **good TEEP is relative, not absolute**. A 35% TEEP might represent world-class performance for a single-shift custom manufacturer, while 65% TEEP could indicate serious underutilization for a continuous process line.

**What matters most is:**

1. **Trend analysis**: Is your TEEP improving or declining over time?
2. **Internal benchmarking**: How does similar equipment compare within your facility?
3. **Business alignment**: Does your TEEP support your capacity strategy and customer demand patterns?

Don't chase arbitrary TEEP targets. Instead, use TEEP to understand whether your equipment utilization matches your business strategy, identify capacity constraints before they become critical, and make informed decisions about shift additions or capital investments.

## How to Use Both Metrics

Most companies track both OEE and TEEP. OEE stays the main tool for production supervisors and operators who focus on running equipment well during scheduled time. TEEP gives executives information they need for planning capacity, deciding on equipment purchases, and analyzing whether to expand into new markets.

To calculate TEEP correctly, you need to track time carefully. Many manufacturing systems already sort downtime into planned and unplanned categories for OEE. TEEP needs more detail:

- **Scheduled production time**: When equipment runs or could start running right away
- **Planned maintenance**: Regular maintenance windows
- **Changeovers**: Time spent switching between different products
- **No orders**: Equipment sits idle because not enough customers want products
- **Operational limits**: Problems with other equipment, not enough workers, or other constraints

Without clear categories, TEEP can unfairly punish good operational decisions. Equipment that creates bottlenecks should show high TEEP. Other equipment may correctly show lower numbers.

## Real-World Examples

TEEP works best in industries where equipment can run around the clock. Paper mills, chemical plants, and steel factories typically target higher TEEP values for their main production equipment since continuous operation makes business sense for these processes.

Industries that make distinct products in batches usually see lower numbers. This makes sense when you think about it: a factory running two eight-hour shifts, five days per week, can only reach about 48% TEEP even if everything runs perfectly during those scheduled hours.

The automotive industry shows why context matters. Assembly lines often run two shifts per day. Even with excellent operational performance during scheduled production time, TEEP numbers naturally stay lower. This reflects intentional business decisions about shift schedules, labor costs, and maintenance planning rather than poor performance.

## Common Mistakes to Avoid

Several problems come up when companies use TEEP incorrectly. One major mistake is using TEEP to judge daily operations. Production workers cannot control customer demand or high-level scheduling decisions. Holding supervisors responsible for TEEP creates bad incentives to build unnecessary inventory or skip planned maintenance.

Another common error is ignoring the bigger picture. Equipment designed to handle product changes, quality testing, or work with other equipment should not be compared to equipment that runs continuously. A 35% TEEP might be the best possible number for a packaging line that serves multiple production lines.

Finally, many companies make the mistake of treating TEEP as a fixed target. TEEP helps you compare performance over time or across similar equipment. A dropping TEEP trend means you should investigate. But any single TEEP number needs context to understand what it means.

## Using TEEP for Capacity Planning

TEEP helps most when planning capacity. When customer demand gets close to what you can produce, companies face a big decision: spend money to expand capacity or accept slower growth. TEEP analysis clarifies this choice by showing how much extra capacity exists in current equipment.

A factory with 65% TEEP across major equipment could theoretically increase production by 54% without buying new equipment, assuming customer demand exists and operational problems can be solved. Whether this capacity can actually be used depends on shift schedules, worker availability, maintenance needs, and product mix, but TEEP shows the theoretical maximum.

## Setting Up TEEP Measurement

Companies that want accurate TEEP need good data collection systems. Writing down times by hand produces unreliable results. Automated data capture from equipment computers, control systems, or manufacturing software provides the foundation for accurate calculations.

The money spent on measurement systems should match decision-making needs. Companies making frequent capacity investment decisions benefit from real-time TEEP monitoring. Organizations with stable capacity and clear bottlenecks might find quarterly manual calculations work fine.

Building TEEP dashboards has become much simpler with modern tools. FlowFuse offers a practical solution for companies that want real-time equipment monitoring without complex programming. The platform bridges the gap between OT (Operational Technology) on the factory floor and IT systems in the office. It connects directly to your equipment, whether through [PLCs, SCADA systems](https://flowfuse.com/use-cases/scada/), or [machine controllers and MES platforms](https://flowfuse.com/use-cases/mes/), and creates visual dashboards that track performance metrics. You can see how straightforward the process is by looking at their [OEE dashboard blueprint](https://flowfuse.com/blueprints/manufacturing/oee-dashboard/). The same approach works for TEEP, connect your data sources, set up the calculations, and view your equipment utilization in real-time. This makes professional-grade monitoring accessible even for smaller manufacturers or companies without dedicated programming staff.

***Want to see how TEEP monitoring would work for your specific equipment and production environment? [Book a demo](https://flowfuse.com/book-demo/) with FlowFuse to explore how you can track equipment utilization, identify capacity opportunities, and make data-driven decisions about your manufacturing assets.***

## The Bottom Line

TEEP extends equipment measurement from operational efficiency to overall asset use. It does not replace OEE but adds to it by answering questions OEE cannot answer. When used carefully with proper context, TEEP gives manufacturing leaders clear visibility into total equipment productivity. It helps inform capacity investment decisions with solid numbers. The value is not in achieving high percentages but in understanding what those percentages reveal about equipment use, customer demand, and operational constraints.


# Agentic AI Reads OPC UA Servers So You Don't Have To

OPC UA servers store everything. Finding anything takes hours.

Your historian has six months of production data across 847 variables. Wednesday's batch failed quality checks. The root cause is in there, a sensor drift, a temperature anomaly, something that happened before the failure became visible. But variables are named `ns=2;s=Device1.PLC.DB1.Temp_Sensor_3`. The namespace structure was designed for PLC efficiency, not human investigation.

So you click through hierarchies. Cross-reference documentation that's two firmware versions out of date. Export data to Excel. Build correlation matrices. Check timing against process logs. Four hours later, you find it.

OPC UA gave machines a common language. It solved connectivity. But it created an accessibility problem: the data infrastructure that captures everything makes finding specific answers remarkably slow.

The solution isn't better visualization or more dashboards. It's removing humans from the navigation process entirely. AI agents can browse OPC UA servers, pull historian data, run correlations, and surface answers while you're still typing the question.

# Why Investigation Remains the Bottleneck

Implementation problems in industrial IoT are largely solved. Teams connect devices, configure historians, and establish data flows with impressive efficiency, especially on platforms like FlowFuse. The wheels fall off when someone actually needs to *use* that data.

Your monitoring dashboard flags a reject rate spike on Line 3. That's the easy part, alerts work. But dashboards show you *symptoms*, not *causes*. Finding the cause means reconstructing what happened in the hours leading up to the spike. Which of the seventy-three variables on Line 3 changed? What correlations exist between the temperature sensors and quality metrics? How does this week's pattern compare to normal operations?

Every operational question follows this pattern. Why did energy consumption spike Tuesday? Which sensor readings predict motor failures? What operating conditions maximize packaging throughput? The questions change. The investigative workflow doesn't, navigate namespaces, extract data, analyze patterns, interpret results. Manual. Every. Single. Time.

Here's what makes this a systemic crisis rather than an annoyance: the data exists. The infrastructure works. But converting data into operational intelligence requires hours of skilled labor *per question*. So people stop asking questions. They stick to pre-configured dashboards showing metrics someone decided to monitor six months ago. They don't explore. They don't investigate unexpected patterns. They definitely don't do the kind of exploratory analysis that actually drives improvement.

The standard solutions miss the fundamental problem. Hiring more analysts scales linearly at best, you get three people doing manual work instead of one. Building more dashboards only helps when you already know what to monitor. Neither solves for the unexpected question, the one-off investigation, the "something doesn't look right" hunch that requires pulling data you've never looked at before.

## What AI Changes

The value proposition is straightforward: Replace manual investigation workflows with automated execution.

Thursday afternoon, Line 3's reject rate spikes. The traditional approach takes six hours minimum if the data's clean and you know exactly where to look: Pull historian data for fifty variables that might matter. Build correlation matrices in Excel. Analyze sensor drift patterns. Cross-reference timing against process logs. Compare current performance against last month's baseline. Pull in a colleague to verify you didn't miss something obvious.

Ask an AI agent: &#x2A;"What changed in Line 3 before Thursday's spike?"*

The agent queries your historian across relevant subsystems. Runs timing correlations against the reject rate increase. Identifies statistical anomalies in sensor data. Tests relationships between variables. Flags causation with confidence intervals. Five minutes later you're reviewing root cause analysis, not building it from scratch.

This efficiency compounds across every investigative use case:

Predictive analysis that would take weeks becomes instant queries. Understanding how motor current relates to product quality typically requires extracting time-series data from your historian, cleaning datasets, running statistical tests, validating correlations, interpreting significance, three months of dedicated work. The agent returns correlation matrices with confidence intervals and outlier analysis while you're finishing your coffee.

Compliance documentation that takes weeks to compile generates on demand. Audits need complete OPC UA server documentation, node hierarchies, relationship mappings, system architecture, operational ranges calculated from historical performance. Manually, that's weeks of browsing address spaces and organizing specifications. The agent generates it directly from live server metadata and your historical data. Infrastructure changes next quarter? Regenerate the documentation instead of manually updating deprecated specs.

Pattern recognition at scale becomes feasible. Agents analyze patterns across days, weeks, months of continuous operation, patterns humans miss because they require simultaneous analysis of thousands of variables. "Show me every instance where Variable\_A spiked within ten minutes of Variable\_B changing" becomes a query you actually ask instead of a question you abandon because the manual investigation would take too long.

The mechanical work executes automatically: namespace navigation, data retrieval, correlation testing, anomaly detection. Your time goes to what requires actual judgment, interpreting analytical findings against operational knowledge, deciding whether to adjust processes or schedule maintenance. Questions you'd previously skip because investigation overhead exceeded potential value become queries worth asking.

## The Technology Behind It

FlowFuse makes this work through a straightforward architectural approach that connects AI reasoning to industrial data systems.

As an industrial data platform, FlowFuse already handles connectivity to OPC UA servers, historians, and other industrial systems. The new capability comes from MCP nodes that expose this connectivity through the Model Context Protocol, a standardized interface that lets AI systems interact with any data source using common operations like browse, read, query, and analyze.

Here's how it flows: You ask your AI agent a question in natural language. The agent translates that into MCP operations, browse this namespace, retrieve these variables, analyze this time range. FlowFuse receives those operations and executes them against your actual infrastructure, handling all the OPC UA protocol complexity, session management, and security. The agent gets back structured data, interprets it, and gives you an answer.

![High-level architecture diagram showing the interaction between Al agents and industrial systems via the FlowFuse Platform.](https://flowfuse.com/blog/2026/01/images/ai-mcp-opcua.png){dataZoomable=""}&#x2A;High-level architecture diagram showing the interaction between Al agents and industrial systems via the FlowFuse Platform.*

The architecture separates concerns cleanly. AI handles the reasoning, figuring out what data matters and how to interpret it. FlowFuse handles the execution, dealing with industrial protocols, data access, and system integration. Neither tries to do the other's job.

For teams building their own integrations, the implementation details are documented here: [Building MCP Server Using FlowFuse](https://flowfuse.com/blog/2025/10/building-mcp-server-using-flowfuse/)

**Watch It Work**

The video below shows an AI agent generating complete OPC UA server documentation on request, finishing in minutes what typically requires weeks of manual effort.

:lite-youtube{style="width: 100%; aspect-ratio: 16/9; background-image: url('/blog/2026/01/images/ai-opcua-document-generation.jpg'); background-size: cover; background-position: center;" title="AI Agent Generating OPC UA Documentation" videoid="agxAw4B91Nw"}

## What This Unlocks

Connecting agents to OPC UA infrastructure delivers capabilities manual investigation can't match at scale.

- **Autonomous navigation across address spaces.** Agents read node hierarchies, examine metadata, DisplayNames, EngineeringUnits, data types, access levels, follow references between nodes, build structural understanding of systems. You describe what you need, agent locates relevant nodes. No memorizing namespace paths or node IDs. Looking for a pump's discharge pressure sensor buried five levels deep in your hierarchy? Agent finds it by understanding equipment relationships, not because someone documented the exact path.
- **Automated data analysis across historians.** Agents pull historical data, run statistical tests, calculate correlations, detect anomalies, compare time periods, validate significance. Ask "How does ambient temperature affect motor current draw on Line 2?" and get months of historian data analyzed, variables correlated, confounding factors accounted for, confidence intervals calculated. Manual approach means days of Excel work: extraction, cleaning, statistical analysis, validation. Agent returns analyzed results in minutes while you're still drinking your coffee.
- **Pattern recognition at operational scale.** Agents analyze patterns across days, weeks, months of continuous operation, patterns humans miss because they require simultaneous analysis of thousands of variables. "Show me every instance where Variable\_A spiked within ten minutes of Variable\_B changing" becomes a query you actually ask instead of a question you abandon. Finding subtle leading indicators of equipment degradation across hundreds of sensors? Agent correlates every variable combination, identifies statistically significant patterns, surfaces predictions. Doing this manually would take months of dedicated work. Nobody attempts it because nobody has months to spare.

Investigation capabilities that previously required dedicated data science teams become natural language queries. Complex analyses finish in minutes instead of weeks. Questions you'd skip because the investigation wasn't worth the effort become routine operational intelligence you actually use.

## The Bigger Picture

The value in industrial data was never about collection, it was always about the questions that data could answer. Those questions just cost too much time to pursue. When investigation drops from hours to minutes, the economics change completely. Different questions become worth asking. Documentation stays current because updating it is on-demand instead of weeks of work. Pattern analysis across thousands of variables becomes routine instead of heroic.

This isn't about replacing people with automation. It's about making the data infrastructure you already built actually useful for the decisions it was meant to inform. Your team still interprets results, makes judgment calls, and takes action. The AI just handles the mechanical work of data access and analysis.

And it's not limited to OPC UA. FlowFuse's MCP approach works the same way across any industrial system, MQTT brokers, Modbus devices, SQL databases, REST APIs, whatever protocols you're running. Same natural language interface, same investigation capabilities, different underlying systems. The infrastructure you have becomes the infrastructure you can actually use.

For a complete guide to connecting PLCs via OPC UA, EtherNet/IP, Siemens S7, and Modbus to MQTT, cloud, and enterprise systems, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).


# FlowFuse 2.26: Bringing access-controls to your MCP nodes

With the holiday break sitting in the middle of this release cycle, it's a smaller release than usual this month. But that hasn't stopped us continuing to make the FlowFuse Expert even more useful.

## Role-based access control for your MCP tools

Following on the the introduction of [FlowFuse Expert MCP-Powered Insights](https://flowfuse.com/changelog/2025/12/ff-expert-mcp-insights/) we have added annotations to the FlowFuse MCP nodes and linked them up with the FlowFuse roles.
This permits a level of control over who can access what. This is just a first step, we will be working in the area over the next few iterations.

The MCP nodes now allow you to set some standard annotations to give the platform a hint as to what type of action the node performs. This lets you separate tools that provide read-only information from those that make potentially-destructive changes.

Within the FlowFuse team, you can then use the granular RBAC feature to configure what users have access to the different types of node.

For example, Viewer role users can have access to read-only nodes, whilst Owners get to access the full range of tools. These roles can be customised for each Application within the team.

The annotations we apply are part of the MCP standard, so will be recognised by your own Agents and LLMs.

![MCP Server Tool Node with new annotations](https://flowfuse.com/blog/2026/01/images/mcp-annotations.png){dataZoomable=""}*MCP Server Tool Node with new annotations*

## Integrating FlowFuse Expert with Node-RED

This release also brings some new abilities for the FlowFuse Expert to help you do things inside Node-RED itself.

- **Streamlined Node Installation:** When the Expert suggests a node module, it can now automatically open the Palette Manager and filter for the correct package, leaving you just one click away from installation.
- **Direct Flow Imports:** When the Expert provides demo flows, you no longer need to copy-paste JSON. The Expert can now inject those flows directly into your editor, ready for deployment.

Make sure you've updated the `@flowfuse/nr-assistant` module inside your instance to unlock these new capabilities.

:video{ariaLabel="FlowFuse Expert Install Node" autoPlay="true" height="850" loop="true" muted="true" playsInline="true" preload="none" width="1260"}*FlowFuse Expert integration with the Palette Manager*

## What else is new?

For a complete list of everything included in our 2.26 release, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases/tag/v2.26.0){rel="&#x22;nofollow&#x22;"}.

Your feedback continues to be invaluable in shaping FlowFuse's development. We'd love to hear your thoughts on these new features and any suggestions for future improvements. Please share your experiences or report any [issues on GitHub](https://github.com/FlowFuse/flowfuse/issues/new/choose){rel="&#x22;nofollow&#x22;"}.

Which of these new features are you most excited to try? Reach out on GitHub or social media!

## Try FlowFuse

### FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in the cloud within minutes.

### Self-Hosted

Get FlowFuse running locally in under 30 minutes using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# Integrating Git within Node-RED Workflow with FlowFuse

If you've been using Node-RED in production, you already know the pain points. Flows get complex. Teams grow. Someone makes a change that breaks production at 2 AM. You need to roll back, but which version was working? Who approved this deployment? How do you keep your dev environment in sync with production?

Traditional Node-RED doesn't have answers to these questions. But modern software development has solved these problems decades ago with version control and DevOps pipelines.

That's the gap FlowFuse fills.

## FlowFuse: DevOps for Node-RED

FlowFuse is a platform built specifically for running Node-RED at scale. It handles deployment, management, security, team collaboration, and more so you can focus on building flows instead of managing infrastructure.

Every FlowFuse can automatically create snapshots whenever flows are deployed. These snapshots let you track changes over time and roll back when needed. You can also create manual snapshots to mark important milestones.

The real power comes from DevOps pipeline stages. You set up stages like development, staging, and production, then push snapshots through them. Make changes in dev, test in staging, promote to production. Everything's tracked and auditable.

## Why Git Integration Matters

We realized that many organizations already use Git as their central version control system. Their CI/CD pipelines run on Git commits. Their backup systems rely on Git repositories. Their compliance tools track changes through Git history too. To fit seamlessly into these existing workflows, Node-RED flows needed to be in Git too.

That's why we built Git integration for FlowFuse. FlowFuse pipeline stages now connect directly to Git repositories. Push your snapshots to Git and pull changes back when you need them.

**Note:** Git integration currently supports GitHub repositories.

Git integration brings several key advantages. Your flows are backed up in Git repositories alongside your other code, so if an instance is accidentally deleted, your flows remain safe and recoverable. For some companies, having all code assets version-controlled in Git repositories is a compliance requirement they must meet.

Git integration works alongside FlowFuse's DevOps features, snapshots, pipelines, rollbacks, giving you the full power of both systems.

## Setting Up Git Integration

Let's walk through connecting your FlowFuse instances to a Git repository.

### Prerequisites

Before you begin, make sure you have:

- **FlowFuse Team Account**: Git integration is available exclusively to Enterprise users. If you don't have a Enterprise account, visit the [FlowFuse pricing page](https://flowfuse.com/pricing) or contact `sales@flowfuse.com` to upgrade.
- **GitHub Account**: You'll need a GitHub account with permission to create repositories and generate personal access tokens.

### Step 1: Create a GitHub Repository

First, set up a repository where your Node-RED flows will live:

1. Log in to your GitHub account
2. Click the &#x2A;*+** icon in the top right corner and select **New repository**
3. Name your repository (e.g., "nodered-flows" or "production-flows")
4. Choose **Public** or **Private** depending on your needs
5. You can initialize with a README if you'd like documentation
6. Click **Create repository**

Keep this repository URL handy, you'll need it later.

### Step 2: Generate a GitHub Personal Access Token

FlowFuse needs permission to push and pull from your repository. GitHub uses Personal Access Tokens for this:

1. Go to [GitHub Personal Access Tokens Settings](https://github.com/settings/tokens){rel="&#x22;nofollow&#x22;"}
2. Click **Generate new token** and select &#x2A;*Generate new token (fine-grained)**
3. Give your token a descriptive name like "FlowFuse Node-RED Integration"
4. Set an expiration date (we recommend 90 days for security)
5. Under **Repository access**, choose **Only select repositories** and pick which repos FlowFuse can access
6. Under Permissions, expand **Add permissions**, then locate **Contents** and set it to **Read and write**
7. Click **Generate token** at the bottom

**Critical**: GitHub shows this token only once. Copy it immediately and store it somewhere secure. You'll paste it into FlowFuse in the next step.

### Step 3: Add Your Token to FlowFuse

Now let's connect FlowFuse to your GitHub account:

1. Log in to your FlowFuse account
2. Navigate to **Team Settings** in the left sidebar
3. Click the **Integrations** tab
4. Find the Git integration section and click **Add Token**

![Screenshot showing the Team Settings page with the Integrations tab selected and add token button highlighted](https://flowfuse.com/blog/2026/01/images/team-settings-integrations.png){dataZoomable=""}*Team Settings - Integrations tab showing Git integration options*

5. Give your token a name (like "GitHub Production Flows")
6. Paste the Personal Access Token you copied from GitHub
7. Click **Add**

![Screenshot of the Add Token dialog where users enter their GitHub Personal Access Token](https://flowfuse.com/blog/2026/01/images/add-token.png){dataZoomable=""}*Adding a GitHub Personal Access Token to FlowFuse*

Your token is now available to all Node-RED instances in your FlowFuse team.

### Step 4: Configure a Pipeline Stage for Git

This is where it comes together. You'll configure a pipeline stage to push snapshots to your Git repository.

**Important**: A Git repository stage needs something to push. Make sure your pipeline has at least one stage before the Git stage, typically a Node-RED instance stage. The pipeline will take snapshots from that source stage and push them to Git.

1. In FlowFuse, navigate to your application
2. Go to the **DevOps Pipelines** section
3. Select the pipeline you want to add the Git stage to (or create a new one)
4. Click **Add Stage**
5. In the stage settings, select the Type **Git Repository**
6. Give the stage a name
7. Select the token you created earlier
8. Enter your repository URL (e.g., `https://github.com/your-username/nodered-flows.git`)
9. Enter the snapshot file name (e.g., `flow.json`). Leaving this blank will use the instance name. This is the name your flows will be saved as in the Git repository. When pulling changes back from Git, you must enter the exact same file name that exists in your repository to retrieve the correct flows.
10. Specify a branch name for pushing changes (like `main`). Make sure the branch already exists in your repository.
11. Optionally, specify a branch name for pulling changes (like `main`). Make sure the branch already exists in your repository.
12. Enter a secret credential key. This can be any strong passphrase. You'll need to re-enter it when pulling changes through the DevOps pipeline in FlowFuse.

![Screenshot showing the Git Repository stage configuration with fields for stage name, token, repository URL, and branch names](https://flowfuse.com/blog/2026/01/images/git-stage-adding.png){dataZoomable=""}*Configuring a Git Repository stage in a DevOps pipeline*

13. Click **Add Stage**

![Screenshot showing a DevOps pipeline with multiple stages including a Git repository stage successfully added](https://flowfuse.com/blog/2026/01/images/dev-pipeline.png){dataZoomable=""}*DevOps pipeline with Git repository stage added*

### Step 5: Push a Snapshot to Git

With the Git repository stage configured in your pipeline, you're ready to push your Node-RED flows to Git.

1. Open your Node-RED instance in FlowFuse that is part of the DevOps pipeline containing the Git repository stage
2. Make any required changes to your Node-RED flows, or keep them as-is if you want to push the current state
3. Navigate to the **DevOps Pipelines** section and select the pipeline that includes the Git repository stage
4. Create a **snapshot** to capture the current state of your flows
5. Click **Run Pipeline** and promote the snapshot through each stage until it reaches the Git repository stage
6. Once the pipeline completes successfully, FlowFuse automatically commits the snapshot to the configured Git repository

After the pipeline run finishes, you can open your Git repository and verify:

- A new commit containing your Node-RED flows
- A commit message linked to the snapshot
- A complete, auditable history of changes

At this point, your Node-RED workflows are version-controlled in Git and fully integrated into your existing CI/CD and DevOps processes.

### Step 6: Pull Changes from Git

FlowFuse's Git integration works both ways. You can push flows to Git and pull changes back from Git into your Node-RED instances.

The pipeline process is identical whether you're pushing or pulling, only the stage order changes. When pushing, your Git repository stage sits at the end of the pipeline. Snapshots flow from your Node-RED instance through intermediate stages and finally commit to Git. When pulling, the Git repository stage moves to the beginning. The pipeline fetches the latest commit from your configured branch, creates a snapshot, and promotes it through subsequent stages to your target instances.

This bidirectional workflow solves several common challenges. Teams can commit flow changes directly to the repository and pull them into FlowFuse. You can migrate flows from other systems by committing them to Git first. Your Git repository serves as both a backup destination and a source of truth.

## Conclusion

FlowFuse simplifies everything about running Node-RED at scale, deployment, security, scaling, and team management. Git integration bridges the gap between FlowFuse's DevOps features and your existing development infrastructure. Your flows stay version-controlled, your team stays synchronized, and your operations stay simple.


# Beyond Kepware: Why Modern Industrial Connectivity Demands a Second Look

Kepware isn't chosen, it's assumed. It appears in budgets like line items for electricity or insurance. No one questions it. No one compares it. It just... goes in.

And that's exactly the problem. You've been paying luxury car prices, often well into six figures, for a data shuttle bus. Reliable? Sure. But while Kepware moves your data, it also moves your money straight into per-tag, per-connection licensing fees that explode as you scale. Worse, you don't control your own data. And now, with TPG's $600 million acquisition closing in early 2026, you're betting on a company mid-transition, mid-uncertainty, mid-everything.

The question isn't whether Kepware works. It's whether you can afford to keep not asking better questions.

## Why You Picked Kepware (And Why That Made Sense)

Before we talk about why Kepware shouldn't be your next choice, let's acknowledge why it was your last one. Because the logic that got you here wasn't wrong, it was just incomplete.

You didn't choose Kepware. Kepware chose you.

Your integrator spec'd it. The equipment vendor had already validated it. Your boss signed off without discussion because "everyone uses Kepware." When you're staring down a plant expansion deadline with production breathing down your neck, safe beats optimal every time.

And Kepware was safe. Until the bills started compounding.

$15,000 for the initial license seemed reasonable. Then came additional tags for the new production line. New drivers for equipment you hadn't planned for. A redundant server because IT flagged single points of failure. Eighteen months later, you're at 20x annually, and nobody remembers approving half of it.

Here's what actually happened: Kepware didn't win on technical merit. It won on timing and driver ubiquity.

In the early 2000s, industrial connectivity was genuinely hard. Proprietary PLC protocols. Sparse documentation. Vendors actively hostile to third-party integration. Kepware invested aggressively in driver development, by 2010, if a PLC existed in North America, Kepware almost certainly supported it. That created a network effect system integrators couldn't ignore. Standardization followed. Equipment vendors tested against it. PTC's $100 million acquisition in 2016 cemented the strategy.

You didn't get tricked. Lock-in happened through entirely normal operations.

But here's what the sales process never highlights: escalating switching costs aren't a side effect. They're the business model.

Your goal was never "buy Kepware." Your goal was to move OT data where it matters, fast, reliably, without unnecessary drama.

## Kepware Pricing Explained: How Costs Escalate as You Scale

The ROI spreadsheet your vendor showed you was accurate. It just ended when the story was just beginning.

You approved Kepware because the first-year quote made sense: base license, sufficient tags for operations, drivers for your PLCs. Number aligned with budget. Decision closed.

Then your plant didn't stop.

New production line? More tags needed. Different PLC brand? New driver license. Maintenance kicks in at 18-20%, calculated not on your starting point, but on everything you've added since. IT finally gets redundancy approved. Operations wants visualization. Kepware doesn't do that, so you're buying elsewhere. New vendor. New purchase order.

Year two: more equipment, more expansion. Your historian works with Kepware. Your analytics tool doesn't. Middleware required. Management wants remote access. Cloud gateway added. Every item individually justified. Every purchase properly approved. All operationally necessary.

Year three: you're maintaining the entire accumulated infrastructure. Tag costs scaled with production capacity. Integration expenses compounded with each system added.

What wasn't emphasized during procurement: Kepware moves data. Full stop. You still need separate systems for storage (historian), translation (middleware), visualization (dashboards), and processing (analytics). The purchase order said "connectivity." The actual infrastructure required five different vendors.

The pricing model punishes scale. More capacity needs more tags. More tags mean higher licensing. Higher licensing means steeper maintenance. Your costs climb while the underlying technology expenses, bandwidth, compute, storage, have been dropping for years.

Per-tag pricing doesn't match infrastructure reality. It matches what the market has tolerated. The actual cost of transmitting ten thousand data points versus one thousand? Essentially identical. Cloud providers know this. Modern software companies abandoned this model. The technology doesn't require metered billing, it just permits it.

Kepware charges per-tag because nobody's forced them to change.

You thought you bought connectivity. What you actually got was a billing structure that monetizes your success. Every expansion. Every new line. Every added system. Kepware extracts revenue from it. This isn't a partnership, it's value extraction wearing an enterprise license agreement.

## Why Kepware Makes Less Sense in 2026

Five years ago, questioning Kepware meant gambling with production reliability. The alternatives weren't proven.

Today they are. And fundamental shifts made the old calculation obsolete.

**Protocol secrecy collapsed.** Kepware's advantage rested entirely on PLC manufacturers hiding their communication protocols. Documentation was unavailable. Reverse engineering was mandatory. Now every significant protocol specification is publicly published. Manufacturers provide detailed technical guides. Industry bodies standardized everything. What once demanded rare expertise is now freely available knowledge. The technical moat largely dried up. The pricing hasn't acknowledged it.

**Infrastructure economics flipped.** Handling 50,000 tags used to mean purchasing dedicated servers, implementing redundant hardware, staffing IT personnel. Real capital expenditure. Today that same capacity runs on $200 monthly cloud compute. The underlying cost dropped 90%. Kepware's licensing model operates as though nothing changed.

**Complexity barriers vanished.** Configuring Kepware required certified specialists. Three-day deployments minimum. Formal training requirements. Troubleshooting demanded protocol knowledge most engineers lacked. Modern platforms offer drag-and-drop setup, automatic device discovery, visual configuration. What took specialists three days, operations teams complete in two hours. The complexity that forced expensive integrator relationships disappeared.

**Fragmented purchases became unified platforms.** Kepware moved data. Full stop. You still needed separate historians, visualization tools, cloud gateways, middleware, analytics platforms. Five vendors. Five contracts. Five integration projects. Modern platforms ship unified, not assembled from parts, designed as integrated systems. The integration tax evaporated.

**And private equity bought Kepware for $600 million.** TPG's deal closes early 2026. Private equity doesn't maintain operations, it maximizes returns. That often means price increases, forced product bundles, or operational restructuring designed to extract more from existing customers. It's the same playbook every time.

You're not evaluating Kepware as it is. You're evaluating what it becomes under new ownership carrying $600 million in return expectations.

The window's narrow. Before new pricing hits. Before renewals reflect new ownership. While you control the timing instead of reacting to changes forced on you.

The safe choice five years ago became the risky bet today. Alternatives matured. Economics shifted fundamentally. Ownership transferred.

Evaluate now, or negotiate from weakness later.

## The Bottom Line

You didn't select Kepware after rigorous evaluation. You selected it because it was the path of least resistance.

Least resistance meant proven reliability. Integrator familiarity. Budget pre-approval. Zero pushback.

But resistance-free had costs. Not just licensing, per-tag economics that scale against you. Integration overhead that multiplies vendor relationships. Lock-in that monetizes every operational expansion.

And now adds new risk: private equity ownership with $600 million in performance expectations.

The fundamentals shifted. Protocols became open. Infrastructure costs dropped 90%. Modern platforms integrated what previously required assembly. The technical and economic moats that justified Kepware as default evaporated.

You're not constrained by technology. You're constrained by inertia.

Kepware functions reliably. That's not disputed. But reliability alone doesn't justify paying 2015 prices for 2026 infrastructure when alternatives provide more capability at lower total cost.

Evaluate alternatives now from strength. Or negotiate renewals later from weakness under new ownership terms.

Kepware won through early dominance and ecosystem lock-in. That's separate from being the right architecture for current operations.

See [how FlowFuse connects any PLC to MQTT, OPC UA, cloud, and enterprise systems](https://flowfuse.com/landing/plc/), without per-tag licensing or proprietary lock-in.


# The Node-RED Story: How Visual Programming Escaped the Lab and Conquered Industry

In late 2011, Nick O'Leary was a "plumber" of the digital age. As part of IBM's Emerging Technology Group, he spent his days building experimental projects that pushed the boundaries of what connected systems could do. But there was a problem: for every new experiment, he found himself writing the same boilerplate code over and over, the tedious "wiring" work needed to make different systems talk to each other.

## The Birth of Node-RED

The frustration was mounting. Each new project at IBM's Emerging Technology lab meant rewriting integration code from scratch. Nick knew there had to be a better way.

On a "wet January day in 2013," Nick decided to try something new. He wanted a way to visualize mapping messages across an MQTT infrastructure. He turned to Node.js, then a relatively new technology, as the foundation.

Over a single weekend, he built a rough prototype that allowed him to drag boxes and draw wires instead of writing endless integration code. When he showed it to his colleague Dave Conway-Jones on Monday morning, Dave’s response was immediate and world-changing: "Go on then."

![Dave Conway-Jones and Nick O'Leary, co-creators of Node-RED](https://flowfuse.com/blog/2026/01/images/nick-and-dave.png){dataZoomable=""}*Dave and Nick*

The name was a light-hearted play on words. "Node" reflected the Node.js runtime and the flow-based model, while "RED" was a cheeky nod to "Code Red." While some later suggested it stood for "Rapid Event Developer," Nick and Dave never felt the need to formalize it. It was simply a vibrant alternative to the "Big Blue" corporate standard.

![Early version of Node-RED interface showing visual flow-based programming with connected nodes](https://flowfuse.com/blog/2026/01/images/early-node-red-screenshot.png){dataZoomable=""}*Early Node-RED Screenshot*

Those two words meant everything. Dave didn't just approve, he joined in. Together, they started refining the tool, adding features, testing it on real IBM projects. What began as Nick's weekend hack became their shared mission. Within weeks, they had transformed a rough prototype into something that actually worked in production. The tool that was supposed to save Nick time on one project was now saving their entire team hours every week.

Node-RED offered something different: freedom. Drag boxes. Connect wires. Make anything talk to anything. No permission required.

## The Public Spark

The transition from a lab tool to a public project wasn't a corporate rollout; it was a grassroots explosion. By late 2013, Nick and Dave had seen enough: Node-RED was too useful to keep locked inside the walls of IBM.

### The First Commit: September 5, 2013

The public story of Node-RED began with a push, not a press release. On **September 5, 2013**, the first code was uploaded to GitHub. It was a "soft launch", a way to see if the world actually needed a visual tool for "wiring" the Internet of Things. Within weeks, the community responded with an intensity that caught even the creators by surprise.

### The "Workshop" Moment: Wuthering Bytes

The first external validation happened just a week after the GitHub release at the **Wuthering Bytes** technology festival. After Nick gave a brief, unprepared lightning talk, he walked into a workshop the following day and was stunned to see &#x2A;*Node-RED on every single screen.** A workshop facilitator had discovered the code on GitHub just days earlier and immediately scrapped his original plan. He realized that instead of teaching students how to troubleshoot line-by-line syntax, he could use Node-RED to let them actually *build* something. In thirty minutes, the class had achieved what usually took an entire day. It was the first time Nick saw people he had never met using his creation to solve real problems.

### The London Node.js User Group (LNUG)

While the hardware community was the first to adopt it, the &#x2A;*London Node.js User Group (LNUG)** was where the project faced its first true technical trial. Standing before a room of seasoned JavaScript developers, Nick had a 30-minute slot to prove that Node-RED wasn't just a visual toy, it was a powerful tool built on the very event-driven architecture they loved. The talk was a massive success, generating immediate buzz across social media and solidifying Node-RED’s reputation within the developer community.

::lite-youtube
---
params: rel=0&start=1740
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: "LNUG October 2013: Node-RED - Nick O'Leary"
videoid: CF7BGDj2_G8
---
::

### The Big Stage: ThingMonk 2013

While the September meetups provided the spark, **ThingMonk on December 3, 2013**, was the "Big Bang." This was the first major professional and industrial stage for Node-RED. It was here that the industry elite, the architects of the "Internet of Things", realized that Node-RED was the answer to the "glorious mess" of incompatible protocols.

In his presentation, "Wiring the Internet of Things," Nick showed that visual programming wasn't just a shortcut for beginners; it was a professional-grade solution for the most complex integration problems on the planet.

::lite-youtube
---
params: rel=0
style: "margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;"
title: "ThingMonk 2013: Wiring The Internet of Things"
videoid: zUoCJb0jzuo
---
::

### 2014: Proving the Concept

If 2013 was the spark, 2014 was the foundation. This was the year Node-RED moved from a lab experiment to a professional tool.

**IBM's launch of Bluemix** (now IBM Cloud) marked a pivotal moment, Node-RED became a flagship starter app, validating that visual programming could power enterprise-grade cloud applications. The year also saw multiple major version releases that enhanced the platform's capabilities.

![Node-RED featured as a flagship starter app on IBM Bluemix in 2014](https://flowfuse.com/blog/2026/01/images/ibm-bluemix.png){dataZoomable=""}*Node-RED featured as a flagship starter app on IBM Bluemix in 2014*

During this period, Nick took the project on the road, speaking at conferences and meetups to actively build the community around Node-RED. A major milestone came at QCon London 2014, a moment Nick has often described as especially meaningful. The talk marked a turning point, demonstrating to the professional software industry that visual programming could be a serious, scalable solution for complex data integration.

![Nick O’Leary presenting Node-RED at QCon London 2014](https://flowfuse.com/blog/2026/01/images/Q-CON-2014.png){dataZoomable=""}*Nick O’Leary presenting Node-RED at QCon London 2014*

## The Explosion: The Raspberry Pi Milestone

By November 2015, Node-RED was officially integrated into the Raspbian Jessie image, marking its transition from a manual install to a core component of the Raspberry Pi ecosystem. The [announcement was made by Simon Long](https://www.raspberrypi.com/news/latest-raspbian-update/){rel="&#x22;nofollow&#x22;"}, the Raspberry Pi Foundation's UX Engineer, who detailed the update in a blog post on December 2, 2015. This milestone meant that millions of $35 computers suddenly shipped with a visual programming tool built specifically for the "Internet of Things," sitting prominently in the application menu alongside educational staples like Scratch and Python.

![Screenshot of the Raspbian Jessie desktop menu showing Node-RED included by default with Scratch and Python on Raspberry Pi](https://flowfuse.com/blog/2026/01/images/node-red-on-pi.jpg){dataZoomable=""}*Screenshot of the Raspbian Jessie desktop menu showing Node-RED included by default with Scratch and Python on Raspberry Pi*

The impact was immediate and massive. Students learning to code on Raspberry Pi discovered Node-RED next to Python. Hobbyists building weekend projects found it pre-installed. Educators teaching IoT concepts had a visual tool ready to use. What had required hunting through forums and installation guides was now just a click away in the menu. The barrier to entry dropped to zero, and the community exploded.

Within months, Node-RED flows for Raspberry Pi projects flooded online forums. Home automation guides assumed you had it installed. The "install Node-RED" step disappeared from tutorials, it was just there. This wasn't just about convenience. It was about legitimacy. Being bundled with Scratch and Python signaled that Node-RED wasn't a niche hack, it was essential infrastructure for the IoT era.

## A Home for the Future: The OpenJS Foundation

By 2016, Node-RED had outgrown its "side project" status at IBM. To ensure the tool remained open and vendor-neutral, [IBM moved Node-RED into the newly formed JS Foundation](https://nodered.org/blog/2016/10/17/js-foundation){rel="&#x22;nofollow&#x22;"} (which merged in 2019 to become the OpenJS Foundation) as a founding project.

This was a pivotal moment for industrial adoption. By moving the project to a neutral foundation, Node-RED was no longer just an "IBM tool", it became a public utility. Large-scale industrial players like Hitachi and Siemens could now contribute to the code and build their own products on top of it without fear of "vendor lock-in." It signaled that Node-RED was a stable, world-class piece of software infrastructure, governed by the same community standards as jQuery and Node.js.

The foundation move unlocked something crucial: trust at scale. When a Fortune 500 manufacturer evaluates tools, vendor neutrality isn't optional, it's mandatory. The OpenJS Foundation gave Node-RED the governance structure, intellectual property protections, and community oversight that enterprises require. Companies that would never bet their production lines on an IBM internal tool could now build on Node-RED with confidence. The path from hobbyist workshops to factory floors was open.

## The Community Takes Over

The community didn't just use Node-RED, they built it. By 2023, the library contained over 4,300 nodes. Every new smart device gets a Node-RED node within weeks. Every protocol got wrapped. Forums filled with shared flows. Someone in Germany would solve a lighting problem at 2 AM, share the solution, and someone in California would adapt it for their garage door an hour later.

This wasn't just a user base, it was a movement. Makers, hobbyists, and tinkerers around the world were solving problems and sharing solutions freely. The barrier to contribution was low, anyone could create a node and publish it. The barrier to adoption was even lower, anyone could install a node with a single click.

The community's creativity extended across domains. Nodes were built for popular platforms, industrial protocols, cloud services, databases, messaging systems, AI services, and thousands of integrations beyond. If a technology existed, someone had already made it work in Node-RED.

But something unexpected was happening beneath the surface. While the community shared home automation flows in forums, engineers in factories were quietly watching. They saw the same drag-and-drop simplicity that connected smart lights could connect production equipment. They saw the protocol-agnostic approach that worked for hobbyists could work for industrial systems. They saw a tool that both IT and operations teams could actually understand.

The movement that began in living rooms was about to reach factory floors.

## The Bridge Nobody Planned

The movement reached Hitachi's factory floors in a way nobody anticipated. Node-RED emerged as a crucial communication tool bridging the gap between IT and factory engineers. Its intuitive interface allowed the entire flow to be visible on screen, facilitating discussions and collaborative efforts seamlessly.

For decades, IT and OT spoke different languages. IT managed databases and networks. OT ran machines and production lines. They needed each other but couldn't understand each other. Node-RED gave them a shared vocabulary, visual flows that both sides could read.

A factory engineer could build a flow reading data from a Modbus PLC. An IT engineer could look at that same flow and immediately understand what it did. No translation needed. The same visual language that connected smart home devices was now connecting industrial equipment to enterprise systems.

The movement had arrived in the industry. And it brought its community-driven, protocol-agnostic approach with it.

## The Numbers Prove It

[The 2019](https://nodered.org/about/community/survey/2019/){rel="&#x22;nofollow&#x22;"} survey captured the movement mid-expansion: 31.5% used it in manufacturing, and 24% had created PLC applications. Home automation remained strong, but the industry was already significant.

By [2023](https://nodered.org/about/community/survey/2023/){rel="&#x22;nofollow&#x22;"}, the industrial footprint had solidified. Manufacturing remained the second largest industry at 40%, up from 31.5%. Just over 40% now use Node-RED professionally. Home automation usage held steady at 70%, both sectors thriving, not competing.

The protocols revealed the depth of industrial adoption. MQTT and HTTP dominated both sectors. But Modbus and OPC-UA, industrial protocols, saw significant growth. These weren't hobbyists experimenting. These were engineers connecting real production equipment.

The movement had conquered two worlds simultaneously.

## FlowFuse: Conquering Industrial IoT

By 2021, the challenge had shifted. Node-RED worked brilliantly for individual developers, but enterprises needed more: how do you scale it across tens of thousands of factory instances? How do you secure it? How do you make teams collaborate on flows without stepping on each other's work? To solve these problems, Nick founded FlowFuse (formerly FlowForge).

But a technical revolution needs both an inventor and an architect. In January 2022, Zeger-Jan van de Weg (ZJ) joined as CEO. Drawing on his experience as an early GitLab employee, ZJ knew how to turn a successful open-source project into an enterprise-grade platform. While Nick continues to guide the technical direction as CTO, ZJ leads the effort to scale industrial automation for Fortune 500 companies.

![Nick and ZJ](https://flowfuse.com/blog/2026/01/images/zj-and-nick.png){dataZoomable=""}*Nick and ZJ*

Together, they have raised $14.5 million to build the infrastructure enterprises demand. With this funding, they assembled a talented team spanning engineering, product, customer success, marketing, sales, and community, each member contributing their unique expertise to drive FlowFuse's growth across every aspect of the business.

Between 2021 and 2025, FlowFuse evolved into a full industrial ecosystem through deliberate focus on operational maturity. The journey began with team collaboration and scaling, introducing version control, team permissions, and DevOps pipelines that let engineering teams work together on flows like software projects, then deploy updates across thousands of remote Node-RED instances with discipline. With collaboration and scale established, the focus shifted to enterprise security, adding SSO, RBAC, and SOC 2 compliance to meet strict governance requirements. Next came infrastructure independence, integrating a built-in MQTT broker and FlowFuse Tables to reduce reliance on external services. By 2025, as AI began reshaping industry, FlowFuse entered the intelligence era with MCP nodes, and FlowFuse Expert, an AI that converts plain-English industrial problems directly into working Node-RED flows.

FlowFuse's mission went beyond enterprise features. It invested continuously in Node-RED core development and community sustainability. When the original [Node-RED Dashboard was deprecated](https://discourse.nodered.org/t/announcement-node-red-dashboard-v1-deprecation-notice/89006/2){rel="&#x22;nofollow&#x22;"}, FlowFuse rebuilt [Node-RED Dashboard 2.0](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"} from the ground up.

That commitment extended to the ecosystem itself. Through the [Certified Nodes program](https://flowfuse.com/blog/2025/07/certified-nodes-v2/), FlowFuse identifies critical community nodes and subjects them to rigorous security and quality testing. To ensure long-term reliability, FlowFuse supports maintainers financially or assumes maintenance responsibility, an approach aligned with the expectations of large industrial organizations.

Education and community came next. FlowFuse launched [Node-RED Academy](https://node-red-academy.learnworlds.com){rel="&#x22;nofollow&#x22;"}, the first official Node-RED Academy offering Node-RED certification, providing a clear path from learning flows to building production-ready systems. This was followed by major investment in [modernizing the Node-RED editor UI](https://discourse.nodered.org/t/node-red-survey-shaping-the-future-of-node-reds-user-experience/98346/95){rel="&#x22;nofollow&#x22;"} through an open, community-driven process. The journey culminated in the Node-RED Conference, bringing together over 1,000 live attendees worldwide and transforming a distributed user base into a connected industrial community.

Five years into its journey, FlowFuse stands as a rare example of open source scaling into industrial reality without losing its soul. What started as a way to operate Node-RED at scale is now a production platform deployed in some of the world's largest factories, increasingly taking on responsibilities once dominated by legacy industrial platforms. It demonstrates that when community stewardship, engineering rigor, and long-term vision align, open source can form the backbone of modern industrial systems.

This vision has translated into explosive market adoption, with the company multiplying its annual recurring revenue and customer base by nearly 5x in the last year alone.

## Why It Succeeded

Node-RED won because it was simple when everyone else was complicated.

The smart home industry sold subscriptions and proprietary hubs. Industrial automation sold certifications and consulting contracts. Both pretended connecting systems required expertise only they could provide.

Node-RED proved them wrong. Drag a box. Draw a line. Done.

The same principles work everywhere. A homeowner connecting a thermostat to weather data uses the exact concepts an engineer uses connecting factory equipment to a data lake. Input. Logic. Output. The scale changes. The principles don't.

The visual interface removed the gatekeepers. You didn't need to understand APIs or write integration code. You could see the logic, understand it, and modify it, all on one screen. When both the factory floor worker and the IT manager can look at the same flow and grasp what it does, you've eliminated the translation layer that created vendor dependency.

## Today and Tomorrow

Today, Node-RED spans from living rooms to factory floors. FlowFuse has made it enterprise-ready.

Home users still rely on Node-RED to make incompatible smart devices work together. But FlowFuse has transformed industrial adoption, turning a powerful tool into production infrastructure with fleet management, enterprise security, and DevOps pipelines that Fortune 500 companies trust.

The scale is substantial. Manufacturing plants run FlowFuse across thousands of remote sites. Energy companies depend on it for critical infrastructure monitoring. What started as visual programming for hobbyists now handles mission-critical operations where downtime costs millions per hour.

The momentum continues building. FlowFuse is pushing Node-RED into new territory, AI-powered flow generation, advanced analytics, and capabilities that didn't exist two years ago. As AI reshapes manufacturing and operations, Node-RED is positioned at the center of that transformation.

The revolution that began in living rooms and reached factory floors is entering its next phase.

## Final Note

Writing this reminded me why I fell in love with Node-RED. But the real story isn't in these words, it's unfolding right now in someone's garage, on a factory floor, in a student's first "it works!" moment.

What amazes me most is the community's generosity. People don't just solve problems, they share them, celebrate each other's wins. Curiosity matters more than credentials. "I don't know, but let's figure it out together" is the standard response.

If this story touched you, please share it. Someone out there might need the reminder that the impossible is usually just the not-yet-possible.

Thank you for reading, and happy New Year!


# MQTT vs OPC UA: Why This Question Never Has a Straight Answer

The question itself is broken.

MQTT moves messages. OPC UA defines meaning. They operate at different layers of the stack. Comparing them is like comparing TCP to JSON.

Yet the debate persists. Vendors position them as competitors. Consultants bill by the complexity. Your procurement department demands a choice.

The industry knows better. OPC UA includes MQTT in its spec. Real factories use both: MQTT for telemetry, OPC UA for machine coordination. The technologies have been converging over time.

The persistent debate exists because the distinction between their purposes remains unclear to many decision-makers.

This article explains what each does, where they differ, and how to decide based on requirements instead of marketing.

## What Each Actually Does

The confusion starts with a category error. Asking "MQTT or OPC UA?" is like asking "HTTP or PostgreSQL?" One moves bytes. The other organizes meaning.

### MQTT: The Minimalist Messenger

MQTT is a publish-subscribe messaging protocol designed in 1999 for satellite oil pipeline monitoring. It does exactly one thing: &#x2A;move small messages between devices over unreliable networks with minimal overhead.*

**The entire protocol is remarkably compact:**

Publishers send messages to named topics. Subscribers express interest in topic patterns. A broker routes messages from publishers to matching subscribers. That's it.

```text
Device A publishes: "factory/line3/temperature" → 72.4
Device B subscribes: "factory/line3/#"
Broker delivers: Device B receives 72.4
```

MQTT's three quality-of-service levels handle network reality:

- **QoS 0**: Fire and forget. Message might arrive. Might not. Zero guarantees.
- **QoS 1**: At least once delivery. Message arrives one or more times. Duplicates possible.
- **QoS 2**: Exactly once delivery between client and broker, using a four-way handshake.

The protocol header is 2 bytes. A temperature reading with topic and payload fits in under 50 bytes. This efficiency matters when you're transmitting over cellular networks, paying per kilobyte, or running on battery-powered sensors.

**What MQTT doesn't provide:**

MQTT has no concept of data types. That "72.4" could be Celsius, Fahrenheit, or an error code; the protocol doesn't know or care. It doesn't validate message structure, enforce schemas, or understand relationships between data points. Topic namespaces are conventions, not specifications. `factory/line3/temp` and `factory/line3/temperature` and `line3/factory/temp` are entirely different topics with no semantic relationship.

The broker is a single point of failure unless you architect clustering separately. Security implementation depends on broker configuration; MQTT itself focuses on message transport. Discovery mechanisms must be implemented externally; subscribers must know exact topic names in advance or use wildcards and filter received messages.

MQTT is deliberately minimal. This simplicity at the transport layer enables its flexibility and efficiency.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

### OPC UA: The Semantic Framework

OPC UA (Unified Architecture) isn't primarily about moving data; it's about describing what data means, how it relates to other data, and what operations are valid.

Released in 2008, OPC UA replaced a fragmented collection of Windows-only industrial protocols with a platform-independent standard. Where MQTT is minimal, OPC UA is comprehensive. The specification spans 37 parts in the core specification covering everything from information modeling to historical data access to alarm conditions

**At its core is the address space, a hierarchical graph of nodes:**

Every piece of industrial equipment is modeled as a connected set of typed nodes. A motor isn't just a collection of variables; it's an object with defined properties, methods, and relationships.

```text
Motor (ObjectNode)
├── Speed (VariableNode: Double, Engineering Units: RPM)
├── Temperature (VariableNode: Float, Range: 0-150°C)
├── Status (VariableNode: Enum {Running, Stopped, Fault})
├── Start() (MethodNode: Returns StatusCode)
└── ConnectedTo → Pump_A (Reference: HasComponent)
```

The type system is rich. Variables carry metadata: engineering units, valid ranges, historical access, alarm limits. References define relationships: hierarchical containment, semantic associations, type inheritance.

**Companion specifications extend this model for specific industries:**

The Euromap 83 specification defines a complete injection molding machine in OPC UA terms: every sensor, every actuator, every state transition. A client connecting to any Euromap 83 compliant machine encounters the same address space structure. Software written for one machine works with any conforming machine, no custom integration required.

This semantic interoperability is OPC UA's primary value. Two systems can exchange meaningful information without prior coordination because the information model is standardized, not just the byte format.

**OPC UA provides multiple interaction patterns:**

- **Data access**: Read/write variables synchronously
- **Subscriptions**: Monitor variables, receive change notifications
- **Methods**: Execute operations on server objects (start motor, set recipe)
- **Events**: Structured alarm and event notifications
- **Historical access**: Time-series query interface
- **PubSub** (Part 14): Publish address space updates to message brokers, including MQTT

Security is integrated. Certificate-based authentication, message signing, and encryption are specification requirements, not implementation options. Every OPC UA server must support security policies.

**The tradeoff is implementation complexity:**

Implementing an OPC UA server requires managing an address space, handling multiple services, maintaining subscriptions, and processing security handshakes. Client libraries are measured in megabytes, not kilobytes. A simple "read a value" operation involves session establishment, service negotiation, and potentially certificate exchange.

This overhead is impractical for battery-powered sensors with infrequent reporting requirements. It's appropriate for a $2M manufacturing cell where understanding that a temperature reading represents "bearing temperature on the output shaft of motor 3, measured in Celsius, with a normal operating range of 40-65°C and critical alarm at 85°C" matters.

### The Layer Mismatch

Think about the OSI model, that seven-layer networking abstraction everyone learns and immediately forgets:

MQTT operates at the application layer of the OSI model. It is a messaging protocol that happens to carry application data, but what that data represents is outside its scope.

OPC UA also operates at the application layer. It defines data models, type systems, and semantic relationships. Transport is abstracted; OPC UA can run over TCP, HTTPS, WebSockets, or MQTT.

Comparing them is comparing different architectural concerns:

- MQTT answers: "How do I efficiently move this message from publisher to subscriber?"
- OPC UA answers: "What does this data represent, and how does it relate to other data?"

They're not competing solutions to the same problem. They're solving different problems that happen to intersect in industrial automation architectures.

### The Convergence

OPC UA [Part 14](https://reference.opcfoundation.org/Core/Part14/v104/docs/){rel="&#x22;nofollow&#x22;"} specifies OPC UA PubSub, a publish-subscribe model that can use MQTT as its transport mechanism. An OPC UA server publishes address space updates as MQTT messages encoded with OPC UA's type information.

MQTT Sparkplug B introduced structured payloads inspired by OPC UA’s semantic modeling concepts, adding type definitions and metric metadata to MQTT payloads. A Sparkplug message doesn't just carry "72.4"; it carries "Temperature (Float32, Engineering Units: °C, timestamp: 1704470400000) = 72.4".

The technologies are converging, not diverging. Industry 4.0 architectures increasingly use both: OPC UA for machine-to-machine communication where semantic interoperability matters, MQTT for high-frequency telemetry where bandwidth efficiency matters, and OPC UA PubSub over MQTT where both matter.

Yet vendor marketing, procurement processes, and consultant billable hours perpetuate the false choice. The question isn't "which one?"; it's "which one for what?"

## Where They Actually Differ

Understanding real differences requires moving past marketing claims to examine what each technology optimizes for and what constraints it accepts as tradeoffs.

### Network Assumptions

MQTT was designed for unreliable networks. The protocol was built for satellite links where latency is measured in seconds and packet loss is expected. QoS levels give explicit control over delivery guarantees versus bandwidth cost. The persistent session feature lets devices reconnect after network interruptions and resume exactly where they left off, receiving any messages published while offline.

OPC UA was designed for reliable networks and builds on that foundation. The request-response model expects millisecond response times. Session management assumes stable connections. Historical access and complex queries make sense when networks can support them. Running OPC UA over cellular or satellite links works, This operates outside the protocol’s primary design parameters.

This difference cascades into deployment patterns. MQTT excels when you're collecting data from thousands of remote assets: wind turbines, pipeline sensors, fleet vehicles. OPC UA excels when you're integrating systems within a plant where network quality is controlled and semantic understanding matters more than last-mile efficiency.

### Discovery and Configuration

Walk up to an OPC UA server with a generic client. Hit the discovery endpoint. The server returns its complete address space: every node, every relationship, every available operation. You can browse the hierarchy, inspect type definitions, and understand capabilities without reading documentation. The server is self-describing.

MQTT itself does not define a discovery mechanism; discovery is typically handled through external conventions or platform-specific tooling. Topic structures and available data must be known in advance or determined through external documentation. The broker doesn't know what topics exist until something publishes to them. Subscribers must know exact topic patterns in advance or use wildcards and filter everything they receive. Topic naming is pure convention with no enforcement.

This reflects philosophical differences. OPC UA optimizes for systems integration where understanding what's available matters. MQTT optimizes for data distribution where publishers and subscribers coordinate through external mechanisms: configuration files, documentation, human agreement.

In practice, MQTT deployments build discovery and schema management in separate layers. Sparkplug defines topic namespaces and birth certificates that announce available metrics. Cloud platforms provide device registries and schema repositories. These additions extend MQTT's core capabilities to address requirements in complex industrial systems.

### State and Synchronization

OPC UA maintains state. The server knows current variable values. Clients can read the current state at any time. Subscriptions detect changes and notify clients. If a client disconnects and reconnects, it can query what changed during the outage. The historical access service provides time-series queries.

MQTT focuses on message transport rather than state management. The broker routes messages but doesn't track values. If you want the current temperature, someone has to publish it after you subscribe. The "retained message" feature lets the broker store the last message per topic, but that's a single value with no history or change tracking. There's no way to query "what happened between 2PM and 3PM yesterday?"

This difference shapes architecture. OPC UA servers are often treated as authoritative sources of truth within an architecture. MQTT systems require separate databases if historical data or current state matters. Time-series databases like InfluxDB or Timescale became standard MQTT architecture components specifically because MQTT itself doesn't retain data.

### Security Models

OPC UA integrates security into the specification. Every implementation must support certificate-based authentication and encrypted sessions. Security policies are negotiated during connection establishment. Message signing and encryption are first-class protocol features. The specification defines exactly how certificates should be managed, what cipher suites are allowed, and how security auditing works.

MQTT delegates security implementation to the broker and transport layer rather than defining it within the protocol specification. MQTT 3.1.1 supports username/password authentication and expects TLS encryption to happen at the transport layer, but these are optional features. Securing an MQTT deployment means configuring the broker correctly, managing TLS certificates, implementing access control lists, and possibly adding an authentication service. Two MQTT brokers can have completely different security characteristics.

MQTT 5.0 added enhanced authentication mechanisms, but security remains a broker implementation concern rather than a protocol guarantee. In practice, MQTT security depends on broker configuration and deployment choices, ranging from open development environments to enterprise-grade implementations with full authentication and encryption.

For regulated industries (pharmaceuticals, food processing, utilities) OPC UA's integrated security approach often simplifies compliance documentation, as the protocol specification itself defines security requirements rather than depending on correct broker configuration.

### Bandwidth and Overhead

MQTT's 2-byte header and compact binary format minimize overhead. Publishing a temperature reading consumes roughly 50 bytes including topic and payload. Over a cellular connection transmitting 10,000 readings per day, that's under 500KB. At [[]{.katex-mathml}[[[]{.strut style="height:1.0019em;vertical-align:-0.25em;"}[1]{.mord}[p]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[m]{.mord.mathnormal}[e]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[ab]{.mord.mathnormal}[y]{.mord.mathnormal style="margin-right:0.0359em;"}[t]{.mord.mathnormal}[e]{.mord.mathnormal}[(]{.mopen}[t]{.mord.mathnormal}[y]{.mord.mathnormal style="margin-right:0.0359em;"}[p]{.mord.mathnormal}[i]{.mord.mathnormal}[c]{.mord.mathnormal}[a]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[M]{.mord.mathnormal style="margin-right:0.109em;"}[2]{.mord}[M]{.mord.mathnormal style="margin-right:0.109em;"}[ce]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[u]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[a]{.mord.mathnormal}[t]{.mord.mathnormal}[es]{.mord.mathnormal}[)]{.mclose}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[y]{.mord.mathnormal style="margin-right:0.0359em;"}[o]{.mord.mathnormal}[[u]{.mord.mathnormal}[[[[[[]{.pstrut style="height:2.7em;"}[[[′]{.mord.mtight}]{.mord.mtight}]{.sizing.reset-size6.size3.mtight}]{style="top:-3.063em;margin-right:0.05em;"}]{.vlist style="height:0.7519em;"}]{.vlist-r}]{.vlist-t}]{.msupsub}]{.mord}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[p]{.mord.mathnormal}[a]{.mord.mathnormal}[y]{.mord.mathnormal style="margin-right:0.0359em;"}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 0.50 per device per day just for bandwidth.

OPC UA's overhead varies by transport, but even optimized binary encoding uses hundreds of bytes per value due to security handshakes, message signatures, and type information. The same 10,000 readings might consume 5-10MB. At cellular data rates, that's $5-10 per device per day.

For battery-powered remote sensors, this difference determines project feasibility. For plant-floor equipment connected via ethernet, it's less significant. The question isn't which protocol has less overhead; it's whether that overhead matters in your deployment.

### Scalability Patterns

MQTT scales horizontally through broker clustering. Mosquitto, EMQX, and HiveMQ all support distributed deployments where multiple broker instances share message routing. Add brokers as subscriber count grows. Millions of devices can publish to a broker cluster, and the brokers handle distribution to subscribers.

OPC UA scales through federation and aggregation. An aggregation server connects to multiple OPC UA devices, presents a unified address space, and handles client connections. Clients connect to the aggregator instead of individual devices. Adding devices means configuring the aggregator, not changing the client.

These patterns fit different problems. MQTT's approach works when you're collecting data from massive device fleets. OPC UA's approach works when you're building a plant information system that integrates hundreds of machines.

## The Unified Namespace Question

"Just use Unified Namespace" appears in every MQTT versus OPC UA discussion, framed as the answer that makes protocol choice irrelevant.

It is not sufficient.

[UNS](https://flowfuse.com/blog/2023/12/introduction-to-unified-namespace/) is an integration pattern: all plant data flows through a central MQTT broker with hierarchical topics. Systems publish once. Systems subscribe to what they need. Instead of 200 point-to-point connections, you have one hub. Add systems without breaking existing integrations. This solves real problems in brownfield plants.

But UNS doesn't eliminate protocol choice. It relocates it.

Your OPC UA machines still speak OPC UA. Edge gateways consume that semantic data, translate it to MQTT Sparkplug, and publish to the UNS broker. Protocol choice happens at the edge. Your MES connects via OPC UA when it needs semantic precision, subscribes via MQTT when it just needs telemetry. Same downstream system, different protocols for different needs.

UNS centralizes data flow. It doesn't centralize protocol decisions; those still happen at every connection point based on the same factors: semantic requirements, bandwidth constraints, scale characteristics, native support.

The question changes from "MQTT or OPC UA for everything?" to "MQTT or OPC UA for this specific connection?"

UNS is valuable architecture. It's not a protocol substitute.

### How to Actually Decide

Most protocol comparisons start with feature matrices. Yours should start with data flow diagrams.

Map your requirements first, not your preferences. Draw every connection in your architecture. Each arrow represents a data flow with distinct characteristics that should guide protocol selection. A temperature sensor transmitting hourly readings over satellite has fundamentally different needs than a CNC machine coordinating with your MES where both systems must agree on what "cycle complete" means.

Consider four factors for each data flow:

**1. Semantic requirements**

Do the connected systems need shared understanding of what data means? If your MES and machines must coordinate on production states, downtime codes, and quality parameters, OPC UA's information modeling provides that common language. If you're collecting sensor data for ML analysis where patterns matter more than metadata, MQTT with basic context suffices.

**2. Network constraints**

Let the infrastructure decide. Gigabit plant ethernet makes protocol overhead less critical; choose based on semantic needs. Cellular links where you pay per megabyte make the difference between MQTT's 50-byte messages and OPC UA's kilobyte handshakes a line-item cost. Satellite connections with multi-second latency benefit from MQTT's QoS handling regardless of other factors.

**3. Native protocol support**

Work with your equipment, not against it. Siemens PLCs, Rockwell controllers, and Schneider drives speak OPC UA natively. AWS IoT expects MQTT. HiveMQ clusters scale MQTT efficiently. Leveraging native support reduces integration complexity.

**4. Scale characteristics**

Five hundred vibration sensors streaming to cloud storage align with MQTT's horizontal scaling through broker clusters. Fifty machines requiring discovered operations and validated method calls align with OPC UA's self-describing address spaces. Different problems, different optimal solutions.

For example, you're connecting 50 CNC machines, 500 environmental sensors, [MES](https://flowfuse.com/use-cases/mes/), predictive maintenance, and cloud analytics.

```text
- Machines → Edge: OPC UA (semantic interoperability for production coordination)
- Sensors → Edge: MQTT (efficient collection at scale)
- Edge → Cloud: MQTT Sparkplug (metadata preservation with bandwidth efficiency)  
- Edge → MES: OPC UA (shared understanding of manufacturing operations)
```

Four data flows, two protocols, zero false choices. The architecture reflects requirements, not vendor marketing.

The pattern emerges naturally: OPC UA where systems must share meaning. MQTT where efficiency and scale matter. OPC UA PubSub when you need both. Protocol choice becomes a local optimization within each data flow, not a global architecture decision that locks you into one approach.

## Moving Forward

The persistence of this debate reveals something: we're still thinking protocol-first instead of problem-first.

Stop asking "which protocol?" Start mapping your actual data flows and constraints. That pipeline sensor? [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/). That machine coordination? [OPC UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/). That edge-to-cloud telemetry? [Sparkplug](https://flowfuse.com/blog/2024/08/using-mqtt-sparkplugb-with-node-red/). The modern industrial stack uses multiple protocols because different problems have different optimal solutions.

The convergence technologies (OPC UA PubSub, MQTT Sparkplug, edge gateways) prove the industry already knows this. Protocol choice is becoming a local optimization, not a global architecture decision.

Your next project: map requirements first, select protocols second. Use semantic modeling where systems must share meaning. Use efficient messaging where scale and bandwidth matter. Use both when both matter.

The right question isn't "MQTT or OPC UA?"

It's "MQTT where? OPC UA where? Both where?"

Answer that based on your requirements, not vendor marketing.

For a practical guide to connecting PLCs via both OPC UA and MQTT in FlowFuse, alongside EtherNet/IP, Siemens S7, and Modbus, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).


# What Is a System Integrator? Understanding Manufacturing's Most Misunderstood Role

Most factories don't get built all at once. They evolve. Someone buys a robot in 2018. A conveyor system gets added when production ramps up. Last year, a vision system showed up because quality was slipping. Every piece from a different vendor, every piece with its own manual, its own software, its own way of doing things.

And somehow, it all has to work together.

That's what system integrators do. They look at what you've got and figure out how to make it run as one system. They write the code that connects it, wire the panels that power it, and test it until it works the way it needs to. When they're done right, everything just runs: the line moves, parts flow, production hits its numbers.

But here's what most people don't see: the complexity behind making that happen. Even if you work with system integrators regularly, the full scope of what they do often stays hidden beneath the surface. This article pulls back that curtain.

## What System Integrators Actually Do, and Why They Matter

A system integrator is a partner that takes separate pieces of technology (from factory floor equipment to business software) and makes them work as one system.

But that definition doesn't capture the scope. The work spans two worlds that don't naturally speak to each other.

On one side, you have operational technology (OT): the physical equipment that runs your factory. Robots, PLCs, conveyors, sensors, vision systems, SCADA systems. On the other side, you have information technology (IT): the software that runs your business. ERP systems, MES platforms, databases, analytics tools.

System integrators connect both. And that's where things get complicated.

### Discovery and Diagnosis

The work begins with understanding the actual problem. A line keeps jamming because two machines won't sync. Production data sits trapped in SCADA and can't reach your ERP for scheduling decisions. Quality defects have no connection to process parameters. These aren't isolated issues: they're integration failures.

A system integrator walks your plant with a specific lens. They document what equipment you're running, which protocols each device speaks, where IT and OT systems touch or fail to. They identify the gaps: a PLC speaking Modbus trying to feed a cloud platform, an MES that can't pull real-time SCADA status, a quality database disconnected from traceability. They map not just what's broken, but why, and what fixing it actually requires.

### Architecture and Design

Then comes architecture. They design how everything communicates: OPC-UA for machine data, MQTT for sensor networks, APIs for enterprise integration. They map data flow with an understanding of latency, volume, and the cybersecurity boundaries between factory and business networks. They specify edge computing where real-time decisions matter and cloud connectivity where analytics adds value. The result accounts for your existing infrastructure, your future needs, and the reality that factories can't afford downtime.

### Implementation

The build phase makes it real. Controls engineers program PLCs and configure SCADA. Electricians assemble panels and run cable. Network engineers deploy industrial Ethernet with the redundancy and determinism that production demands. Software developers write the middleware that translates between incompatible systems and build dashboards that turn raw data into decisions.

### Testing and Commissioning

Commissioning proves it works. They test components in controlled environments, verify equipment in your actual plant conditions, and stress the complete system under load. They simulate equipment failures, run at maximum throughput, validate data accuracy from sensor to business report. They tune controller performance and set alarm thresholds. Nothing goes live until it runs reliably across all shifts and your team knows how to operate it.

### Why This Matters

Modern manufacturing doesn't work without integration. You can't optimize production without data. You can't get data without connectivity. You can't connect systems that speak different languages and live in different networks. System integrators are the bridge builders who make your factory floor talk to your business systems. They turn equipment investments into operational capability. They make the difference between a factory that runs and one that competes.

But even for those familiar with the role, the true complexity often gets underestimated.

## Why System Integration Is More Complex Than It Appears

Most people who work with system integrators understand what they do at a high level. But the depth and breadth of the work often gets compressed into simple categories that don't capture reality.

"They install robots." That's maybe 10% of the work (and often not the hardest part). "They're industrial electricians." Electricians are crucial team members, but they're one specialty among many. "They handle automation projects." True, but that doesn't explain the challenge of making a 2015 Siemens PLC talk to a 2023 cloud analytics platform while maintaining cybersecurity boundaries and microsecond-level timing precision.

The real complexity comes from operating across multiple domains simultaneously. A single project might require technical breadth across both factory floor protocols (Modbus, Profinet, EtherNet/IP) and enterprise systems (REST APIs, SQL databases, message queues). Understanding when to use edge computing versus cloud processing. Balancing real-time control requirements with data analytics needs.

Different industries have different requirements. Food processing needs washdown-rated equipment and FDA compliance. Automotive requires high-speed deterministic networks and traceability. Pharmaceuticals demand validation documentation and 21 CFR Part 11 compliance. An integrator can't just transplant solutions between industries: domain expertise matters.

Modern factories still run equipment from the 1990s alongside brand-new IoT sensors. Integration means making 30-year-old systems participate in Industry 4.0 initiatives without replacing everything (because replacing everything isn't an option). Legacy systems present unique challenges that require both historical knowledge and modern techniques.

Integration projects touch production, IT, quality, maintenance, and management. Each group has different priorities, different vocabularies, and different success metrics. The integrator must translate between them and build systems that serve all stakeholders. This organizational complexity often proves harder than the technical challenges.

Factories can't stop for testing. Integration work happens around production schedules, often during limited downtime windows. A mistake can halt a production line costing thousands per minute. Every decision carries operational risk that must be carefully managed. The pressure to get it right the first time is immense.

This complexity (the need to work across multiple domains, technologies, and organizational boundaries) is also why the tools integrators use have had to evolve. The traditional approach that worked for decades simply can't keep up anymore.

## How Modern Tools Are Changing System Integration

System integration used to mean custom work every time. Integrators hard-coded point-to-point connections between machines and systems. Change a sensor, and you risk breaking the ERP connection. Scale that across a factory, and you end up with "spaghetti architecture," where everything depends on everything else.

That approach no longer works. Industry 4.0 has changed manufacturing priorities. Data isn't just a byproduct of production: it's the foundation for optimization, predictive maintenance, and competitive advantage. Modern factories generate massive amounts of data, evolve quickly, and can't afford brittle, one-off integrations.

The industry is moving toward architectures like the [Unified Namespace (UNS)](https://flowfuse.com/use-cases/uns/). Instead of systems talking directly to each other, data flows to a central hub. A PLC publishes data once. MES, ERP, analytics platforms all subscribe to it. Add a new system, and it just subscribes. No rewiring. No breaking existing connections.

This shift demands different tools. Tools that support many protocols without custom drivers. Tools that are quick to understand and easy to maintain. Tools where you can see how data flows at a glance instead of digging through legacy code.

Several approaches address these challenges. One that many integrators are adopting combines flow-based programming with enterprise management capabilities. [Node-RED](https://flowfuse.com/node-red/) provides the foundation for visual integration. Integrators build flows by connecting nodes instead of writing everything from scratch. Integrations that once took days can often be configured in hours. Node-RED already supports the protocols integrators rely on daily (MQTT, OPC-UA, Modbus, HTTP, and more) without custom development.

But Node-RED on its own presents challenges at scale. A single factory might run dozens of Node-RED instances across multiple production lines. Multiply that across multiple sites, and suddenly you're managing hundreds or thousands of separate installations. Version control becomes critical: you need to know which flows are running where. Updates need careful orchestration: you can't afford to push changes that break production systems. Teams need visibility into what's deployed and the ability to roll back when necessary.

This is where [FlowFuse](https://flowfuse.com) extends Node-RED's capabilities for production environments. It adds the enterprise management layer that large-scale deployments require: centralized control across all your Node-RED instances, version tracking for every flow change, and the ability to test updates in staging environments before they touch live equipment. What was once a prototyping tool becomes a platform you can trust in production.

The combination enables new patterns. Node-RED can run at the edge, close to machines, processing data locally and sending only what matters upstream. FlowFuse manages those edge deployments from a central location, giving you visibility and control without constant site visits. Teams can develop changes in one environment, test them against digital twins, then deploy systematically across production sites, reducing risk and eliminating the downtime that comes from untested changes.

The tools are also changing who can do integration work. Software developers and IT teams can now contribute meaningfully to industrial systems. The line between OT and IT continues to blur. Still, the core challenge remains the same. Someone must understand both the factory floor and the business systems. Someone must decide what runs at the edge, what belongs in the cloud, and how failures ripple across systems. The tools make integration faster and more scalable, but they don't replace the need for skilled system integrators.

That's why choosing the right integrator still matters.

## How to Choose a System Integrator

Finding a system integrator isn't like hiring a contractor. You're looking for a partner who can solve problems you might not fully understand yet. Here's what to look for and what to watch out for.

Start with relevant experience. An integrator who specializes in automotive won't necessarily fit food processing. The protocols, regulations, and problems are different. Look for integrators who've worked in your industry or on similar projects. Ask for specific examples: What were the challenges? How did they solve them? What would they do differently now?

Check their technical depth. Can they handle both OT and IT? Do they know the specific equipment you're using? Certifications matter (look for manufacturer certifications for your key equipment vendors) but hands-on experience matters more. Ask technical questions during the selection process. If they can't explain complex topics clearly, that's a red flag.

Consider their documentation standards. When they leave, will your team understand what was built? Can someone else maintain it? Good integrators document thoroughly because they know you'll need to modify the system later. Ask to see examples of their documentation. It should include network diagrams, logic descriptions, troubleshooting guides, and clear explanations of design decisions.

Look at their tooling approach. Are they building everything custom or using modern platforms that make systems easier to maintain and scale? Integrators using flow-based programming and remote management can iterate faster and handle updates without constant site visits. Ask what tools they use and why. Good integrators can explain the tradeoffs.

Talk to their references (especially clients from projects two or three years old). How did the system hold up? When issues came up, how did the integrator respond? Were they available for support? Did the system adapt to changing needs? A system that works on day one but can't evolve is a liability.

Pay attention to communication style in initial conversations. Do they ask good questions? Challenge your assumptions when needed? Explain clearly or hide behind jargon? A good integrator makes complex things understandable. They should be able to translate between technical teams and management, between OT and IT, between what you asked for and what you actually need.

Be wary of integrators who promise everything will be easy, cheap, and fast. Good integrators set realistic expectations about timeline, budget, and risks. They identify potential problems upfront rather than discovering them halfway through the project. They explain what could go wrong and how they'll handle it.

Watch for red flags:

- Reluctance to use standard protocols (proprietary solutions lock you in)
- No disaster recovery plan (what happens when something fails at 2 AM?)
- Unclear scope management (how do they handle change requests?)
- Limited cybersecurity knowledge (OT security is non-negotiable now)
- One-size-fits-all solutions (your factory isn't their last project).

Beyond all these factors, you'll eventually need to talk about price. And yes, price matters, but don't let it be your only decision factor. The cheapest bid often turns into the most expensive project once you add up the delays, rework, and ongoing maintenance issues. Look for value instead: an integrator with the right expertise, proven reliability, and an approach that matches your project's complexity. Yes, they might cost more upfront. But thorough documentation, proper testing, and real support usually cost far less over five years than hiring someone who cuts corners to win the contract.

Finally, remember that system integration projects rarely go exactly as planned. Equipment arrives late. Specifications change. Unexpected issues emerge during commissioning. You want a partner who'll work through problems with you, not one who disappears when things get complicated or immediately demands change orders for every small deviation. The best integrator relationships are collaborative. They bring technical expertise; you bring process knowledge. Together, you build systems that actually work for your operation.

## Moving Forward

System integrators bridge the gap between equipment and outcomes. They take the complexity of modern manufacturing (the mix of old and new equipment, the demands for data and flexibility, the need for reliability and innovation) and turn it into working systems.

The role is evolving. New tools make integration faster and more scalable. New architectures make systems more flexible and maintainable. But the fundamental challenge remains: connecting technologies that weren't designed to work together and making them serve business goals.

Whether you're trying to understand what system integrators do, evaluating one for a project, or working as an integrator yourself, the core principle stays the same: good integration makes complexity disappear. The factory runs, data flows, and production hits its numbers (not by accident, but because someone built the systems that make it possible).

### Work With Us

If you're a system integrator, FlowFuse helps you build integrations once and deploy them everywhere (across hundreds of sites, thousands of devices, without writing custom code for every project). Our platform gives you the tools to scale faster, reduce project complexity, and deliver more value to your clients.

[Learn about our partner program](https://flowfuse.com/partners/referral-sign-up/)


# Why Modbus Refuses to Die

Modbus is 47 years old and has no built-in security. By every measure, it should have been obsolete a decade ago. OPC UA, EtherNet/IP, MQTT, Profinet: modern protocols with semantic modeling, encryption, and real-time capabilities arrived backed by billions in vendor investment and industry standardization efforts.

Yet in 2026, new equipment still ships with Modbus as the primary interface. Not tucked away for backward compatibility, but front and center as the deliberate first choice.

What's keeping a protocol from 1979 alive when everything about industrial automation has changed?

## The Installed Base Reality

Manufacturing facilities don't replace working automation systems. They just don't. A plant manager looks at a control panel full of PLCs and motor drives from 2005, all communicating via Modbus, all running production smoothly, and the conversation ends there. Finance already depreciated that equipment over fifteen years. Maintenance has spare parts stocked. Operators know how to troubleshoot it. Why would anyone rip that out?

The equipment wasn't designed for short lifecycles. [Industrial PLCs typically last around 10 to 20 years](https://www.indmall.in/faq/how-long-do-plc-components-typically-last/){rel="&#x22;nofollow&#x22;"} depending on environment and maintenance. Process industry equipment like pumps, transmitters, and valves often [hits 20-30 years before replacement becomes necessary](https://www.automationworld.com/products/control/article/13311314/plc-lifecycle-management){rel="&#x22;nofollow&#x22;"}. [The average age of manufacturing equipment in the US is close to 20 years, and since 1990, the age of assets has virtually doubled](https://www.manufacturing.net/operations/article/13057130/is-the-united-states-ready-to-take-manufacturing-back){rel="&#x22;nofollow&#x22;"}. Not because companies can't afford upgrades. Because the equipment still works.

That creates a problem for protocol modernization. You can't swap out a few devices at a time. Industrial networks are interconnected systems where everything talks to everything else. Upgrading means either taking down the entire line for a coordinated replacement, or maintaining parallel communication infrastructure during a phased migration. Both options are expensive, risky, and deliver zero production benefit.

The numbers show how big this problem is. [The Modbus TCP market alone was [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[1.35]{.mord}[bi]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[i]{.mord.mathnormal}[o]{.mord.mathnormal}[nin]{.mord.mathnormal}[2024]{.mord}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[p]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[j]{.mord.mathnormal style="margin-right:0.0572em;"}[ec]{.mord.mathnormal}[t]{.mord.mathnormal}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[t]{.mord.mathnormal}[o]{.mord.mathnormal}[hi]{.mord.mathnormal}[t]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 2.55 billion by 2032](https://www.futuremarketreport.com/industry-report/modbus-communication-module-market){rel="&#x22;nofollow&#x22;"}. That's not legacy support. That's active growth. Companies are buying new Modbus devices in 2026 to integrate with Modbus networks from 2006.

## It Costs Almost Nothing

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

The economics of Modbus implementation are absurdly compelling. A basic Modbus RTU interface costs manufacturers maybe $5-10 in components. Software licensing? Zero. The protocol is completely open, no royalties, no certification fees, no vendor lock-in. Compare that to implementing industrial Ethernet protocols where you might pay thousands for stack licenses, certification processes, and conformance testing.

For device manufacturers, this matters enormously. A sensor company can add Modbus support for trivial cost and immediately become compatible with millions of existing installations. The development effort is minimal: the protocol specification fits in a few dozen pages, implementations are straightforward, and countless reference designs exist. You don't need specialized silicon or complex firmware. A basic microcontroller with a UART can speak Modbus RTU. Add an Ethernet chip and you've got Modbus TCP.

This simplicity extends through the entire supply chain. Integrators don't need expensive training or specialized tools. A laptop, some free software, and basic understanding of serial communication gets you started. Troubleshooting requires nothing more sophisticated than a protocol analyzer, or in many cases, just watching register values change. The barrier to entry is so low that maintenance technicians can learn Modbus basics in an afternoon.

The contrast with modern protocols is stark. OPC UA requires understanding information modeling, certificate management, and complex security configurations. Profinet demands precise timing requirements and specialized hardware. EtherCAT needs real-time capable network controllers. Each adds cost, complexity, and dependencies. Each creates opportunities for things to go wrong.

## The Vendor-Neutral Advantage

Perhaps Modbus's greatest strength is that nobody owns it. Modicon created it in 1979, but the rights now belong to the Modbus Organization, a trade association that maintains the specification as an open standard. This means no single vendor can kill it, paywall it, or steer it toward proprietary extensions.

Industrial automation is full of protocol wars where vendors push their preferred standards. Rockwell champions EtherNet/IP. Siemens invested heavily in Profinet. Every major automation vendor has protocols they'd rather you use: protocols that tie you into their ecosystem, their training programs, their support contracts.

Modbus doesn't care. It works with everyone's equipment. This vendor neutrality has enormous practical value in facilities running mixed automation systems. A typical factory floor might have Rockwell PLCs, ABB drives, Schneider Electric power meters, and Siemens HMIs all talking to each other. Getting all those vendors' preferred protocols to coexist would be a nightmare. Getting them all to speak Modbus is trivial.

This creates competitive pressure that keeps Modbus relevant. Device manufacturers can't afford to skip Modbus support because doing so immediately excludes them from projects with heterogeneous automation systems. Even vendors with their own sophisticated protocols implement Modbus as a fallback, ensuring interoperability when nothing else works.

The open nature also prevents the protocol from becoming a competitive weapon. Nobody can leverage Modbus to lock customers into their platform. Nobody can obsolete older Modbus devices by dropping support in newer products. The protocol's longevity is guaranteed by the fact that no single entity controls its fate.

## The Technical Case for Modbus

Beyond the strategic and economic reasons, Modbus delivers real technical advantages that matter when you're building and maintaining industrial systems:

**Brutally simple operation.** Modbus does exactly one thing: it reads and writes registers. No object models, no service-oriented architecture, no semantic layers. Just addresses and values. When a motor drive fails at 3 AM, the maintenance technician doesn't want to debug XML schemas or navigate object hierarchies. They want to see if register 40001 is returning the right value. The diagnostic process is straightforward: Can you communicate? Are you reading the right address? Is the value correct? Done.

**Predictable and lightweight.** Modbus frames are small: RTU maxes out at 256 bytes, TCP at 260 bytes. The protocol data unit itself can't exceed 253 bytes. This minimal overhead works fine on 9600 baud serial links still common in older facilities. No state to manage, no synchronized clocks, no microsecond timing requirements like industrial Ethernet protocols demand.

**Trivial to implement.** A basic Modbus stack runs on 8-bit microcontrollers with as little as 10KB flash and 1.5KB RAM. On a PIC16F1827 with 7KB program memory and 384 bytes of data RAM, a complete Modbus RTU implementation uses roughly a quarter of total resources. The entire protocol specification runs maybe 150 pages total. A competent embedded developer can knock out a working implementation in days, not months.

**Debugging is transparent.** Register 40001 is register 40001, period. Hook up a protocol analyzer and you see the raw data: device address, function code, register address, value, CRC. No security? That's one less thing to troubleshoot. No discovery mechanism? That's fine, you configured the addresses once during commissioning and they never change. No data typing beyond basic registers? Perfectly adequate when you know a particular register holds temperature in tenths of degrees Celsius.

**Universal compatibility.** Same protocol on RS-485, RS-232, TCP/IP, even UDP. Modbus devices are addressed from 1 to 247 on serial networks. Converting between Modbus RTU and Modbus TCP is trivial: cheap gateway boxes handle it automatically. You can broadcast to all devices using address 0 for synchronized updates. Modbus devices from different manufacturers actually interoperate. Not in theory, in practice. A Modbus master from Company A will communicate with a Modbus slave from Company B without negotiation, configuration wizards, or integration consultants.

**Fast enough for most applications.** Typical Modbus response time is under 10 milliseconds for 90% of exchanges, though it can occasionally stretch to 150ms depending on device processing. That's plenty fast for process control, monitoring, and most industrial automation tasks. Not fast enough for coordinated motion control, but that's not what Modbus was designed for.

**Reliable error detection.** Modbus RTU uses CRC-16-MODBUS for error checking. Modbus ASCII uses longitudinal redundancy check (LRC). Modbus TCP relies on TCP's built-in data integrity. Each message is independent: no session state means no state corruption. Simple design means fewer things break when a sensor sits in a 60°C cabinet or -20°C freezer for twenty years.

These technical advantages translate directly to faster development cycles, simpler troubleshooting, lower hardware costs, and more reliable operation in harsh industrial conditions where complex protocols would create more failure points.

## When Modern Protocols Actually Win

Modbus's strengths become liabilities when you need capabilities beyond simple register polling. There are entire classes of industrial applications where choosing Modbus means accepting fundamental limitations that modern protocols solve elegantly.

Try running a multi-axis CNC machine or coordinated robot cell over Modbus and you'll understand why EtherCAT exists. Modbus operates on a poll-response cycle: the master asks, the slave answers, repeat. At 115.2 kbaud, you're looking at 25-50 milliseconds per device minimum.

Stack up ten servo drives that need position updates synchronized within microseconds, and Modbus simply cannot deliver. EtherCAT, Profinet IRT, and SERCOS III provide deterministic cycle times under 1 millisecond with jitter measured in nanoseconds. This isn't a performance difference, it's a capability gap. Motion applications requiring sub-millisecond synchronization across multiple axes have no choice but to use these specialized protocols.

Modbus gives you registers. That's it. Register 40023 could be motor temperature, error flags, or the number of production cycles: you only know because someone documented it somewhere. Scale this to a facility with thousands of data points across hundreds of devices and the maintenance burden becomes crushing.

OPC UA solves this with information modeling that makes data self-describing. A temperature sensor doesn't just expose a value, it exposes metadata about units, range, accuracy, and context. When you're building systems that need to automatically discover capabilities, validate configurations, or provide rich [HMI](https://flowfuse.com/blog/2025/11/building-hmi-for-equipment-control/) experiences, OPC UA's semantic layer isn't optional overhead: it's the foundation that makes complexity manageable.

For decades, industrial networks lived behind air gaps and Modbus's lack of authentication didn't matter. Those days are over. Modern facilities need remote monitoring, cloud analytics, vendor support access, and integration with enterprise IT systems.

The moment you connect to external networks, Modbus's plaintext communication and zero authentication become indefensible. An attacker with network access can send arbitrary commands to any Modbus device. No password, no certificate, no audit trail.

[OPC UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/) provides TLS encryption, certificate-based authentication, role-based access control, and detailed audit logging. [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/) with [Sparkplug B](https://flowfuse.com/blog/2024/08/using-mqtt-sparkplugb-with-node-red/) adds lightweight security for IIoT deployments. These aren't nice-to-have features when you're connecting critical infrastructure to the internet: they're requirements. Companies implementing Industry 4.0 initiatives, remote operations, or cloud-based analytics cannot build on [Modbus](https://flowfuse.com/node-red/protocol/modbus/). The protocol has no security model to extend.

Modbus RTU at 115.2 kbaud can theoretically handle around 80-100 transactions per second under ideal conditions, but real-world installations see more like 40-60 due to device processing time and network overhead. That's fine for a few dozen devices with slow-changing process variables.

It collapses when you need high-resolution data from hundreds of sensors. Environmental monitoring systems, vibration analysis, or energy metering across large facilities quickly saturate Modbus networks. Even Modbus TCP, while faster, lacks the bandwidth efficiency of modern protocols.

MQTT's publish-subscribe model eliminates polling overhead entirely. Profinet and [EtherNet/IP](https://flowfuse.com/blog/2025/10/using-ethernet-ip-with-flowfuse/) use producer-consumer architectures that scale better. When data volume grows beyond simple polling scenarios, Modbus becomes the bottleneck.

If you're building a new plant from scratch with modern equipment and no legacy constraints, defaulting to Modbus is choosing 1979 technology for 2026 problems. You lose semantic modeling, security, diagnostic capabilities, and future-proofing.

The cost argument weakens too: modern industrial Ethernet switches and device interfaces aren't dramatically more expensive than RS-485 infrastructure when you factor in reduced wiring labor. The real question is whether you're building for today's requirements or tomorrow's.

Modbus works great until you need asset monitoring, predictive maintenance, cloud integration, or advanced analytics. Then you're ripping out infrastructure you just installed.

Modbus TCP added IP networking but fundamentally remained a register-based polling protocol. There's no roadmap for features industrial facilities increasingly need: time synchronization, alarm management, historical data access, file transfer, or complex data types.

Modern protocols continue evolving. OPC UA added pub-sub models, field-level communications, and TSN integration. The Modbus specification is essentially frozen because any significant changes would break the simplicity that makes it useful. This works fine in stable applications but becomes a ceiling when operational needs expand beyond what the protocol was designed for forty-six years ago.

## The Hybrid Reality

The industry has settled on a hybrid reality that favors encapsulation over replacement. Edge gateways now act as the primary translators, speaking Modbus to legacy hardware while providing secure MQTT or OPC UA feeds to the cloud. This allows maintenance teams to keep their reliable hardware while IT departments receive the structured, authenticated data they require for modern analytics.

Network segmentation becomes the security strategy. Critical Modbus networks stay isolated from the internet. Remote access happens through VPNs and jump boxes. Protocol gateways enforce security boundaries. It's more complex than native security in modern protocols, but it works with equipment that was never designed for network security in the first place.

The result is a patchwork that reflects industrial reality rather than protocol purity. Modbus handles what it does well: simple, reliable communication with field devices. Modern protocols handle what Modbus can't: semantic data, security, cloud integration. The two worlds coexist because forcing a single protocol across all applications would be both technically limiting and economically wasteful.

This approach proves that Modbus survives not because it's technically superior, but because it solves real problems with minimal friction. The protocol succeeded by being simple enough that anyone can implement it, cheap enough that everyone does, and reliable enough that nobody has to think about it.

FlowFuse is the industrial data platform designed to bridge this gap between legacy Modbus registers and modern enterprise systems. Our platform provides the connectivity and security layers needed to transform aging infrastructure into a secure, data-driven operation. See [how FlowFuse connects Modbus PLCs, and every other PLC brand, to MQTT, cloud, and enterprise systems](https://flowfuse.com/landing/plc/).


# Edge AI Is 80% Plumbing, 20% Intelligence

The model is the easy part. I know that is not what you were told. But it is true, and somewhere between your third deployment and your first production fire, you will stop arguing with it.

Edge AI is infrastructure work. Unglamorous, load-bearing, invisible-until-it-breaks infrastructure work with a neural network sitting on top of it like a trophy on a foundation nobody inspected. The 20% is the trophy. The 80% is everything underneath it.

Most Edge AI projects do not fail because the model was wrong. They fail because nobody budgeted for the plumbing, nobody respected the plumbing, and everybody assumed the plumbing would figure itself out.

It does not figure itself out.

Here is what I have watched happen, repeatedly, across manufacturing facilities that were serious about Edge AI, staffed it well, and still could not get past the pilot: the model worked. The demo worked. The business case was real. And then the project stalled. Not because the technology failed, but because the infrastructure the technology needed to survive in an actual plant was never built.

[McKinsey put a number on this: 84% of manufacturers pursuing IIoT were stuck in pilot mode](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-organization-blog/avoid-pilot-purgatory-in-7-steps){rel="&#x22;nofollow&#x22;"}. More than a quarter for over two years. In the years since, the models have gotten better, the hardware has gotten cheaper, and the percentage has not moved. That tells you the model was never the constraint.

What is the constraint? Data your system can actually trust. Updates that reach hardware you cannot physically touch. Security that was designed in, not bolted on. Monitoring that catches a drifting model before it causes a quality escape. And an operating model that answers, before something breaks at 3 a.m., who owns this: IT or OT.

None of that is in the vendor's proposal. All of it determines whether the vendor's proposal is worth anything.

The factory your AI vendor designed their solution for has clean data, modern equipment, stable connectivity, and IT and OT teams working from a shared operating model. That factory is a useful abstraction. It is not your plant.

Your plant has PLCs from three different vendors. A historian configured in 2009 that your OT team will not let anyone touch because the last time someone touched it, production stopped for four hours. Legacy equipment on the shop floor with no digital interface, because when it was commissioned, "digital interface" was not a specification category that existed. Sensor data in proprietary formats. Timestamps that do not align across systems. Protocols that your IT team has never heard of and your OT team has been working around for a decade.

Before a single inference runs at the edge, someone has to collect and normalize data from all of that. Protocol translation. Context tagging. Historian integration. That work is months of engineering. It is almost never scoped. And when it surfaces, it is always described as a surprise, even though everyone in the plant knew it was there.

This is why [Node-RED](https://flowfuse.com/node-red/) matters in manufacturing in a way that nothing else quite does. It was built for exactly this problem: connecting things that were never designed to talk to each other. Modbus, OPC-UA, Siemens S7, MQTT. Thousands of community-built nodes covering the full reality of what is on the factory floor, not the idealized version. Your OT engineers, the people who actually understand the equipment, can build integration flows without waiting for scarce software developers. The domain knowledge that has been locked in people's heads for years can finally become logic that runs.

But Node-RED alone is a development tool. Running it in production, across a fleet of edge devices in multiple facilities, is a different problem entirely. And that gap, between a working flow on one machine and a reliable, managed, auditable deployment across your entire operation, is precisely where most IIoT projects quietly fall apart.

FlowFuse was built to close that gap. Both gaps, actually. Because the problem in manufacturing is not just that the infrastructure is hard. It is that building the intelligence on top of it is also harder than the demos suggest, and most teams are doing both with the wrong tools.

The OT engineer who has spent fifteen years learning one plant's quirks is not going to become a software developer. That was never a realistic ask. But they understand the equipment better than anyone who might be hired to build integrations for it, and if the tooling respects that knowledge, they can do the integration work themselves. Node-RED was the first tool in this space that actually respected that. Not because it simplified the problem, but because it let domain expertise drive the solution.

FlowFuse starts from that same premise and takes it further, into the territory Node-RED was never designed to handle alone.

Take what happens when you want to put a model in production. You have a data scientist who trained something useful, a predictive maintenance model, an anomaly detector, a vision system for defect classification. The model is accurate. It works on their laptop. And then there is the question of where it actually lives, how OT can interact with it, what happens when it needs to be retrained, and who owns it when something goes wrong at 2 a.m. on a Saturday.

In most deployments, nobody has a good answer to any of those questions. The model ends up in a container somewhere that only the data scientist understands, connected to the plant by a fragile handshake that no one wants to touch. The OT team treats it like a black box because it is a black box.

[FlowFuse's ONNX nodes](https://flowfuse.com/node-red/flowfuse/ai/onxx/) change that by putting the model where OT engineers already work. You train, you export, you deploy it as a node in a flow, alongside the Modbus reads, the historian writes, the MQTT publishes. The inference runs locally, on the edge device, no cloud round trip, no latency the line cannot afford. When we [deployed a motor anomaly detector this way](https://flowfuse.com/blog/2026/02/motor-anomaly-detector-ai/), the thing that changed was not the model's accuracy. It was that the people running the line could see what the model was looking at, wire its output to the control logic themselves, and update it through the same pipeline they use for everything else. That is not a convenience improvement. That is the difference between a model that gets maintained and a model that gets abandoned.

The same logic applies to the [FlowFuse Expert](https://flowfuse.com/docs/user/expert/). OT engineers are not waiting for JavaScript fluency. They know the equipment; they know what they need the flow to do; they just get slowed down in the translation between that knowledge and working code. The Expert handles the boilerplate, autocompletes flows, generates function node logic from a plain-language description, explains what a set of nodes does in terms that make sense. It is not a general-purpose chatbot bolted onto an IDE. It was trained on Node-RED and FlowFuse specifically, which means it gives answers that work in industrial contexts rather than answers that look plausible until you try to run them. For teams where the backlog of integration work is longer than the list of people who can do it, that matters.

And then there is the part that breaks most programs before they get to ask any of these questions: operating at fleet scale.

One Node-RED instance, on one machine, managed by the person who set it up, is survivable. Ten devices across two facilities, or a hundred devices across a global operation, is a different problem. You need to push an update to a device on a production line in a facility in another country, and you need to know it landed correctly, and you need to be able to roll it back in under five minutes if it did not. You need to prove, to an auditor or a regulator, exactly which software version was running on which device at which moment. You need to be sure that when a device is decommissioned, its credentials are gone and its configuration is immediately invalidated.

None of that is possible with stock Node-RED. All of it is table stakes in a real manufacturing environment.

FlowFuse's [snapshot-based](https://flowfuse.com/blog/2024/09/node-red-version-control-with-snapshots/) deployments give you a tested, versioned, rollback-capable pipeline for every device in your fleet. [Staged rollouts](https://flowfuse.com/blog/2024/10/how-to-build-automate-devops-pipelines-node-red-deployments/) let you push to a test group first, validate behavior in real conditions, and then promote to production, the same discipline software engineering spent twenty years learning, now available to the people managing industrial edge infrastructure. [Role-based access control](https://flowfuse.com/blog/2024/04/role-based-access-control-rbac-for-node-red-with-flowfuse/), [SSO integration](https://flowfuse.com/blog/2024/07/how-to-setup-sso-saml-for-the-node-red/), and a complete audit trail are in the architecture, not added later when someone asks for them. In automotive, pharmaceutical, and food manufacturing, where you need to prove exactly which software version was running on which device at which moment, that audit trail is not a reporting feature. It is compliance infrastructure.

The manufacturers who escape pilot purgatory are not the ones with better models. They are the ones who decided, before the model was ever deployed, that the infrastructure was the product. The model is a feature. What makes the feature reliable, observable, and maintainable, across a fleet of heterogeneous devices, in real plants, over years, is everything underneath it.

FlowFuse is that infrastructure. Not because it is the most technically sophisticated platform available, but because it was built for the actual factory floor: the PLCs from three vendors, the historian nobody wants to touch, the protocols IT has never heard of, the OT engineers who know more about this equipment than anyone who might be hired to replace them. It meets the plant where it is. That is a harder design constraint than building for the idealized version.

The conference circuit will keep celebrating the 20%. The benchmark results, the accuracy curves, the inference speeds. That work matters. But it is not what separates the manufacturers generating real operational value from the ones still running the same pilot they started two years ago.

What separates them is the plumbing.

Build it on something that understands where you are starting from.

*If you are running Node-RED in production today, or trying to, FlowFuse is the operational layer that makes it scale. Device management, snapshot deployments, DevOps pipelines, ONNX-based AI inference, and the FlowFuse Expert to build faster, all built specifically for industrial environments. [Start a 30-day free trial today](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}. No abstractions. No greenfield assumptions. Just the infrastructure your plant actually needs.*


# FlowFuse 2.27: Integrated Editor in Remote Instances & Context-Aware FlowFuse Expert

FlowFuse 2.27 tightens the development loop for Remote instances and makes FlowFuse Expert more aware of what is actually running in your Node-RED environment. It also improves availability for High Availability hosted deployments.

## A More Integrated Remote Development Workflow

Teams run production and edge workloads in Remote instances. When tooling behaves differently across environments, it slows debugging and increases risk during active changes.

### Immersive Editor & Snapshot Restore

FlowFuse now brings the integrated editor experience to Remote instances. Clicking **Open Editor** provides the same FlowFuse capabilities regardless of where your instance runs.

:video{ariaLabel="Immersive Mode on a Remote Instance" autoPlay="true" height="1340" loop="true" muted="true" playsInline="true" preload="none" width="2026"}*Immersive Mode accessed from a remote instance*

Device Agent v3.8.0 also allows you to restore snapshots while remaining in developer mode. You no longer need to exit developer mode to roll back changes. Pipeline protections remain in place, but manual recovery is faster.

![Restoring a snapshot while in Developer Mode](https://flowfuse.com/blog/2026/02/images/snapshot-restore.png){dataZoomable=""}*Restoring a snapshot without leaving developer mode*

### In practice

- You move between hosted and remote environments without changing your workflow
- You restore snapshots without interrupting active debugging
- You reduce friction while iterating on live systems

## FlowFuse Expert Uses Live Flow and Palette Context

AI guidance is only useful when it reflects what is actually running in your environment. Manually describing flows or installed nodes slows troubleshooting and introduces gaps in context.

### Palette Awareness & Flow Context

FlowFuse Expert now:

- Understands your selected flows as troubleshooting context
- Detects installed custom nodes automatically
- Answers questions about your Node-RED palette, including versions, updates, and disabled nodes
- Suggests node packages and links directly to manage them
- Installs suggested nodes and imports flows with a single click

FlowFuse Expert surfaces context and performs actions only when initiated by the user.

:video{ariaLabel="FlowFuse Expert using live palette context" autoPlay="true" height="720" loop="true" muted="true" playsInline="true" preload="none" width="1411"}*FlowFuse Expert answering palette queries with live context*

### In practice

- You do not manually describe your setup
- You identify missing or outdated nodes faster
- You troubleshoot flows based on real context
- You move between chat, palette manager, and editor without unnecessary clicks or context switching

## High Availability Improvements for Hosted Instances

Parallel restarts in HA environments can introduce avoidable service interruption during deploys or manual restarts.

### Rolling Restarts

Hosted Node-RED instances with HA enabled now restart sequentially rather than in parallel. Any manual or pipeline-triggered restart follows this behavior.

This feature is available to Enterprise licensed self-hosted users and Enterprise tier users of FlowFuse Cloud.

### In practice

- You reduce service interruption during restarts
- You improve availability during deploys
- You maintain stronger continuity in HA environments

## What else is new?

For detailed breakdowns of each feature with additional visuals, visit our [changelog](https://flowfuse.com/changelog/). For the complete list of everything included in FlowFuse 2.27, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases){rel="&#x22;nofollow&#x22;"}.

If something in this release improves your workflow, or if there is still friction we can remove, please [share feedback or report issues regarding this release](mailto\:contact@flowfuse.com?subject=Feedback%20on%202.27) to us.

## Try FlowFuse

### FlowFuse Cloud

The fastest way to get started is with FlowFuse Cloud. :br[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in minutes.

### Self-Hosted

Run FlowFuse locally using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# CAN Bus & CAN Network Explained: Protocol, Frames & Setup

If you work with vehicles, industrial automation, or embedded systems, you've likely encountered **CAN bus**, the communication backbone that connects ECUs, sensors, controllers, and actuators in real-world environments. The challenge isn't just reading CAN data; it's getting that data into your dashboards, cloud platforms, databases, or industrial control systems.

Traditionally, this meant dealing with vendor-specific drivers, proprietary gateway hardware, and low-level C code just to bridge CAN bus to modern IT infrastructure. **SocketCAN** and **FlowFuse** offer a better approach.

SocketCAN brings CAN bus support directly into the Linux networking stack, treating CAN interfaces like Ethernet or Wi-Fi. Combined with FlowFuse's visual flow-based programming (built on Node-RED), you can connect CAN bus devices to virtually any system, building real-time dashboards, streaming data to cloud platforms, integrating with SCADA systems, or bridging to MQTT, databases, REST APIs, and industrial protocols, all without writing low-level code or relying on proprietary tools.

In this tutorial, you'll set up SocketCAN on Linux, integrate it with FlowFuse, and learn how to send and receive CAN frames, establishing the foundation for connecting your CAN infrastructure to the broader industrial ecosystem.

## What Is CAN Bus?

**CAN bus** (Controller Area Network) is a message-based communication protocol that lets multiple electronic control units (ECUs), sensors, and actuators exchange data over a single, shared two-wire connection, without a central computer routing every message. Bosch developed it in the 1980s to simplify automotive wiring, and it now runs everything from car dashboards to industrial machines, farm equipment, and medical devices.

## How the CAN Network Works

A CAN network has no master node and no dedicated point-to-point wiring between devices. Every node connects to the same twisted pair of wires (CAN High and CAN Low), and every message broadcasts to every other node at once, each device decides for itself whether a message is relevant based on its identifier, rather than a switch routing traffic to a specific address.

When two nodes transmit at the same instant, the protocol resolves it without a collision: each bit is either dominant (0) or recessive (1), and during arbitration the node sending the lower, higher-priority identifier wins automatically while the other silently backs off and retries. The network prioritizes itself, a safety-critical message like a brake signal always wins arbitration over a routine one like cabin temperature, without any central scheduler.

## CAN Protocol: Frame Structure

Every message on the bus is a **CAN frame**. Its identifier field drives both filtering and arbitration:

- **Identifier**: 11 bits (standard frame) or 29 bits (extended frame), both the message's priority and its "address"; a lower value wins arbitration
- **DLC (Data Length Code)**: how many data bytes follow, 0-8
- **Data**: up to 8 bytes of payload
- **CRC**: a checksum every receiver verifies before acknowledging
- **ACK**: a single bit any node on the bus can assert to confirm the frame was received without errors

Because every node sees every frame, error-checking is a network-wide guarantee rather than a point-to-point one: if a frame fails its CRC anywhere, every node flags it and the sender automatically retransmits.

## CAN Controllers and Transceivers

Each node reaches the bus through two components: a **CAN controller**, the chip or microcontroller peripheral that handles framing, arbitration, and error detection, and a **CAN transceiver**, which converts the controller's logic-level signals into the differential voltage the bus actually carries. Some microcontrollers include a built-in CAN controller; others pair an add-on controller chip like the MCP2515 with a transceiver like the MCP2551. On Linux, SocketCAN abstracts all of this behind a standard network interface, which is what the rest of this guide uses.

## Where CAN Bus Is Used

CAN bus is the standard in-vehicle network for nearly every car and truck built since the 1990s, it's the physical layer underneath OBD-II diagnostics, but it's just as common outside automotive: industrial machinery and robotics, agricultural and construction equipment, elevators, medical devices, and marine electronics all use CAN to connect controllers, sensors, and actuators over one durable, noise-resistant bus instead of dedicated point-to-point wiring for every signal.

Reading and writing that traffic from software is where SocketCAN and FlowFuse come in.

## What Is SocketCAN?

SocketCAN is a Linux kernel feature that integrates CAN bus support directly into the networking stack. It exposes CAN hardware as standard network interfaces (like `can0` or `vcan0`), allowing you to configure and interact with CAN using familiar Linux networking commands. This abstraction means your application code remains the same whether you're using a USB-to-CAN adapter, an embedded controller, or a virtual interface, making development, testing, and hardware changes significantly simpler.

## Getting Started

To follow this tutorial, you'll need a Linux environment where you can run FlowFuse and configure SocketCAN. In our setup, FlowFuse runs on an Ubuntu-based edge device, and we use a virtual CAN interface to simulate a real CAN bus. This allows you to complete the tutorial without any physical CAN hardware.

### Prerequisites

Before you begin, ensure your environment meets the following requirements:

- **Linux Operating System**
  SocketCAN is a Linux kernel feature and requires a Linux-based system. This guide is tested on Ubuntu 20.04+ and other Debian-based distributions, though the same concepts apply to any modern Linux distribution with kernel 2.6.25 or later.
- **Running FlowFuse Instance**
  FlowFuse is built on top of Node-RED, providing the fastest and most production-ready way to deploy, manage, and govern your flow applications on edge devices. If you're using plain Node-RED, this tutorial will work there as well. For installation details of FlowFuse, see this [guide](https://flowfuse.com/blog/2025/09/installing-node-red/).
- **System Permissions**
  Root or sudo privileges are required to load kernel modules, create network interfaces, and configure SocketCAN devices.
- **CAN Hardware or Virtual Interface**
  This tutorial uses a &#x2A;*virtual CAN (vcan)** interface to demonstrate SocketCAN and FlowFuse integration without requiring physical hardware.
  In production deployments, physical CAN interfaces are typically used, such as:
  - USB-to-CAN adapters (for example, PEAK PCAN-USB or Kvaser devices)
  - Embedded CAN controllers (such as MCP2515 via SPI)
  - Built-in CAN interfaces on industrial computers or single-board computers

The FlowFuse flows and application logic remain the same when switching between virtual and physical CAN interfaces; only the underlying CAN interface configuration differs.

### Enabling CAN Interfaces with SocketCAN

Before FlowFuse can interact with a CAN bus, a CAN network interface must be available and active at the operating system level. SocketCAN does not automatically create or enable interfaces; this step is always required, whether you are using a virtual or physical CAN bus.

The setup differs slightly depending on your environment.

#### Option A: Virtual CAN (vcan) for Development and Testing

A virtual CAN interface allows CAN frames to be exchanged entirely in software. It is useful for development, testing, and learning, but it does not model physical bus timing or electrical behavior.

##### Enable vcan Support

Load the virtual CAN kernel module:

```bash
sudo modprobe vcan
```

Verify that it is loaded:

```bash
lsmod | grep vcan
```

##### Create and Enable the Interface

Create a virtual CAN interface named `vcan0`:

```bash
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
```

Verify the interface:

```bash
ip link show vcan0
```

At this point, `vcan0` is ready to be used by SocketCAN applications such as FlowFuse.

#### Option B: Physical CAN Hardware for Production Systems

When using real CAN hardware, the interface is exposed by a hardware driver, but it still must be explicitly configured and enabled.

##### 1. Hardware Driver

Most common CAN hardware is supported directly by the Linux kernel:

- USB-to-CAN adapters are typically detected automatically when connected
- SPI-based CAN controllers (for example, MCP2515) require kernel and device-tree configuration
- Built-in CAN controllers may require BIOS or kernel configuration

Once the driver is loaded, a CAN interface such as `can0` becomes visible to the system.

##### 2. Configure and Enable the Interface

Physical CAN interfaces must be configured with a bitrate before use:

```bash
sudo ip link set can0 up type can bitrate 500000
```

This command enables the CAN interface, sets the bus bitrate, and makes the interface available to SocketCAN applications.

##### 3. Verify the Interface

```bash
ip link show can0
```

If the interface is up, it can be used immediately by FlowFuse.

#### Comparison: Virtual vs Physical CAN

| Aspect                    | Virtual CAN (vcan)   | Physical CAN      |
| ------------------------- | -------------------- | ----------------- |
| Hardware required         | No                   | Yes               |
| Electrical bus            | No                   | Yes               |
| Bitrate configuration     | Not required         | Required          |
| Kernel driver             | `vcan`               | Hardware-specific |
| FlowFuse (Node-RED) flows | Same                 | Same              |
| Typical use               | Development, testing | Production        |

### Using SocketCAN in FlowFuse

Once a CAN interface (`vcan0` or `can0`) is enabled at the operating system level, FlowFuse can interact with it like any other SocketCAN-compatible application. At this stage, no CAN frames are flowing yet. FlowFuse simply gains access to the interface.

In this section, we'll focus on how FlowFuse connects to SocketCAN and what that means conceptually, before building any actual flows.

The flow looks like this:

![Diagram illustrating the connection flow from FlowFuse, through the SocketCAN layer, down to the OS-level CAN interface (vcan0 or can0)](https://flowfuse.com/blog/2026/02/images/ff-to-canbus.png "diagram illustrating the connection flow from FlowFuse, through the SocketCAN layer, down to the OS-level CAN interface (vcan0 or can0)")

FlowFuse does not communicate directly with CAN hardware. Instead, it relies on SocketCAN, which exposes CAN interfaces through the Linux networking stack.

Once a CAN interface is enabled at the operating system level, whether a virtual interface like vcan0 or a physical interface like can0, it becomes available to any SocketCAN-compatible application. FlowFuse simply opens this interface and exchanges CAN frames using standard socket operations.

This design has two important advantages:

- FlowFuse remains hardware-agnostic. The same flows work with virtual CAN interfaces, USB-to-CAN adapters, or embedded CAN controllers.
- All hardware-specific configuration, such as driver loading and bitrate setup, is handled by the operating system, not by FlowFuse.

As a result, the application logic in FlowFuse stays the same across development, testing, and production environments. The only requirement is that the appropriate CAN interface is created and enabled before FlowFuse starts

#### Installing the SocketCAN Node

FlowFuse does not include native CAN support out of the box. To interact with SocketCAN interfaces (`can0`, `vcan0`, etc.), you need to install a module that provides CAN input and output nodes.

Follow these steps:

1. Open the Instance editor in your browser
2. Click the menu icon (☰) in the top-right corner
3. Select **Manage palette**
4. Open the **Install** tab
5. Search for `node-red-contrib-socketcan`
6. Click **Install** next to the package

Once installed, the SocketCAN nodes will appear in the FlowFuse palette.

##### Installation Troubleshooting

If the installation fails, it is usually due to one of the following reasons:

- FlowFuse is not running on a Linux system (SocketCAN is Linux-only)
- Required build tools are missing on the system

To resolve this, ensure you are running on Linux and install the required build dependencies:

```bash
sudo apt update
sudo apt install -y build-essential
```

After installing the build tools, retry installing `node-red-contrib-socketcan` from the FlowFuse palette.

### Working with CAN Frames in FlowFuse

Once a CAN interface (`vcan0` or `can0`) is enabled and the SocketCAN nodes are installed, FlowFuse can begin exchanging CAN frames. At a high level, there are only **two operations** involved when working with CAN in FlowFuse:

- **Receiving CAN frames** from the bus
- **Transmitting CAN frames** onto the bus

FlowFuse represents these operations using dedicated input and output nodes provided by the SocketCAN module.

#### Receiving CAN Frames

Receiving CAN frames means listening to all messages that appear on the CAN bus and processing them inside FlowFuse.

1. Drag a `socketcan-out` node from the FlowFuse palette onto the canvas.
2. Open the node configuration and add the interface by clicking the &#x2A;*+** button next to the interface. Enter your interface name, e.g., `vcan0` (for virtual CAN) or `can0` (for physical CAN).
3. Click Add, then Done to save the interface.
4. Connect the output of the `socketcan-out` node to a **Debug** node.
5. Deploy the flow to begin receiving CAN frames.

Once connected, the `socketcan-out` node will show a green status box with text. The same applies to the `socketcan-in` node:

```text
connected <your-interface-name>
```

When frames are received, FlowFuse outputs them as JavaScript objects containing fields such as:

- `timestamp`: the time the frame was received (in milliseconds since epoch)
- `ext`: indicates whether the frame uses an **extended CAN ID** (true/false)
- `canid`: the **CAN identifier** for the message
- `dlc`: the **Data Length Code**, i.e., the number of data bytes in the frame
- `rtr`: **Remote Transmission Request** flag (true if the frame requests data)
- `data`: an array of bytes representing the **payload** of the frame
- `err`: indicates whether the frame contains an **error** (true/false)
- `rawData`: a copy of the data payload in its **raw byte form**

![Debug output showing a received CAN message in FlowFuse](https://flowfuse.com/blog/2026/02/images/debug-output-can-message.png "Debug output showing a received CAN message in FlowFuse")

This makes it easy to filter, decode, or route messages using standard FlowFuse nodes.

:lite-youtube{style="width: 100%; aspect-ratio: 16/9; background-image: url('/blog/2026/02/images/receiving-can.png'); background-size: cover; background-position: center;" title="Receiving CAN Frames" videoid="MoL3vw9x5eg"}

#### Transmitting CAN Frames

Transmitting CAN frames means sending messages onto the CAN bus from FlowFuse. This allows you to control devices, trigger actions, or communicate with other ECUs on the network.

1. Drag a `socketcan-in` node from the FlowFuse palette onto the canvas.
2. Open the node configuration and set the interface to `vcan0` (for virtual CAN) or `can0` (for physical CAN).
3. Leave the node in **transmit** mode to send messages onto the bus.
4. Connect the input of the `socketcan-in` node to any source node, such as an **Inject** node for testing.
5. Configure the message in the **Inject** node by setting the payload as a JavaScript object containing the fields `canid`, `data`, and optionally `ext` for extended frames.
6. Deploy the flow to begin transmitting CAN frames.

For example, a message object could look like this:

```json
{
  "canid": 512,
  "data": [22, 45, 170, 255],
  "ext": false
}
```

This would send a standard CAN frame with ID `0x200` and 4 bytes of data onto the bus.

:lite-youtube{style="width: 100%; aspect-ratio: 16/9; background-image: url('/blog/2026/02/images/transmitting-can.png'); background-size: cover; background-position: center;" title="Transmitting CAN Frames" videoid="oWI3Fs9_gyI"}

##### String-Formatted Messages

Alternatively, CAN messages can be defined as strings using a compact format:

```text
<canid>#{R|data}
```

Where:

- **canid**: The CAN identifier in hexadecimal format. For standard IDs using this string format, specify 1-2 hex digits (e.g., `5A`, `FF`). For extended IDs, use 3 or more hex digits (e.g., `7FF`, `1F334455`).
- **data**: The data payload for the CAN frame, specified in hexadecimal format.
- **R**: Indicates a Remote Transmission Request (RTR) frame instead of a data frame.

For example:

```text
200#162DAAFF
```

This sends a CAN frame with ID `0x200` and data bytes `[0x16, 0x2D, 0xAA, 0xFF]`.

To send an RTR frame:

```text
200#R
```

This requests data from devices listening to CAN ID `0x200` without sending any payload.

## Conclusion

By combining SocketCAN with FlowFuse, you've eliminated much of the complexity traditionally associated with CAN bus development. What once required low-level C code, vendor-specific drivers, and deep protocol knowledge can now be accomplished with visual flows and straightforward message handling.

The real power of this approach becomes clear when you consider scalability. The same FlowFuse flows work identically whether you're testing with a virtual CAN interface on your laptop or deploying to production hardware with physical CAN controllers. The abstraction layer provided by SocketCAN means your application logic remains stable even as your hardware requirements evolve.

Once you've connected to your CAN bus, the possibilities expand significantly. You can build real-time monitoring dashboards to visualize CAN data, send telemetry to cloud platforms for analytics and storage, or bridge CAN networks with virtually any other protocol or system. FlowFuse's extensive ecosystem of nodes and integrations supports connections to databases, MQTT brokers, REST APIs, industrial protocols, and more, making it straightforward to integrate your CAN infrastructure into larger IoT and automation workflows.


# Mapping MTConnect Streams for Dashboard Visualization

Most manufacturing facilities run MTConnect agents on their CNC machines, but the XML data these agents produce isn't directly usable. You receive streams of timestamped measurements, state changes, and condition flags wrapped in hierarchical XML structures. Converting this into a functional dashboard means solving three problems: retrieving the data reliably, parsing it correctly, and routing specific values to the right display components.

This article walks through the implementation. You'll connect FlowFuse to an MTConnect agent, extract data items from the XML response, and build dashboard widgets that update in real time.

## What MTConnect Is and Why It Matters

[MTConnect](https://www.mtconnect.org/getting-started/){rel="&#x22;nofollow&#x22;"} is an open manufacturing standard that defines how equipment communicates operational data. Before MTConnect, each machine tool manufacturer used proprietary protocols. Connecting a Mazak, Haas, and DMG MORI to the same monitoring system meant writing custom integrations for each brand. MTConnect solves this by providing a vendor-neutral protocol that any machine can implement.

The standard specifies what data machines should report and how to structure it. A spindle speed reading from a Haas looks identical to one from a Mazak when both machines run MTConnect agents. This standardization makes it possible to build dashboards and monitoring systems that work across mixed machine fleets without custom code for each manufacturer.

MTConnect agents typically run as software on the machine controller or on a separate computer connected to the machine. The agent reads data from the controller's internal systems and exposes it through HTTP endpoints that return XML. You don't interact with the machine directly, you interact with the agent.

## Data Types in MTConnect

MTConnect organizes data into three categories:

- Samples - Continuous numeric measurements like spindle speed, axis position, temperature, power consumption. These values change smoothly and have units.
- Events - Discrete state changes like mode switches, program starts, door opens. Values are strings or enumerations.
- Condition - Equipment health at the component level: normal, warning, fault, unavailable. Multiple conditions can be active simultaneously.

Agents expose this through HTTP endpoints. /current returns latest values for all data items. /sample?from=X\&count=Y returns time-series data.

## XML Response Structure

When you query an MTConnect agent, the response is an XML document rooted in the `Streams` element, which contains one or more `DeviceStream` elements, each representing a device or machine.

Within each `DeviceStream`, `ComponentStream` elements describe individual machine components such as spindles, axes, or controllers. Each component reports its data using three categories: `Samples`, `Events`, and `Conditions`.

Samples represent continuously measured values, while Events represent discrete or state-based changes. Conditions are reported inside a `Conditions` container and use state-specific elements, such as `Normal`, `Warning`, or `Fault`, rather than a generic condition element. Multiple condition states may be active at the same time, as long as they represent different condition data items.

Each reported data item includes a `dataItemId` for identification, a `timestamp` indicating when the value was recorded, and the value itself provided as text content, for example:

```xml
<SpindleSpeed dataItemId="S1spd" timestamp="2026-01-30T14:23:17.492Z">2847</SpindleSpeed>
```

While this hierarchical structure provides a complete and standardized view of the machine, dashboard implementations must traverse multiple levels of nesting and correlate `dataItemId` values with their definitions in the Devices model to extract and display the data they care about.

## Getting Started

Now that we understand the structure of MTConnect and the challenges involved, let's look at how to collect and visualize MTConnect data using FlowFuse.

FlowFuse is an industrial application platform built on Node-RED that brings data collection, transformation, and visualization together in one place. Instead of writing custom integration code, you build flows visually by dragging, configuring, and connecting nodes, then deploying them, no separate tools required.

### Prerequisites

Before you begin, you need:

- **FlowFuse instance** – An active FlowFuse account with an instance created and access to the Node-RED Editor. Sign up at <https://app.flowfuse.com>{rel="&#x22;nofollow&#x22;"} and follow the [FlowFuse getting started guide](https://flowfuse.com/docs/user/introduction/#getting-started-with-flowfuse). If you are new to Node-RED, you can also check out our [course](https://node-red-academy.learnworlds.com/){rel="&#x22;nofollow&#x22;"} on Node-RED.
- MTConnect agent – A CNC machine running an MTConnect agent or an MTConnect simulator such as the public agent at `agent.mtconnect.org` or a locally hosted agent
- Network access – Connectivity from the FlowFuse instance to the MTConnect agent's HTTP endpoint, with the FlowFuse Remote Device Agent installed when connecting from cloud-hosted FlowFuse to on-premises machines

### Collecting MTConnect Data

Bringing MTConnect data into FlowFuse is the first step toward a live dashboard. While you could use the standard HTTP Request node to query MTConnect agents, which is the most common approach, that method requires manually parsing XML responses and navigating through large nested objects to extract specific data points. In this article, I'll show you an easier way.

The Solution Engine node (`node-red-contrib-solution-engine`) makes this straightforward because it lets you access any data point directly by its dataItemId, without having to worry about parsing XML or navigating nested structures.

You can install the node by following the instructions in the FlowFuse documentation: [Using the Palette Manager](https://flowfuse.com/node-red/getting-started/library/#using-the-palette-manager).

Once installed, follow these steps to start collecting data:

1. Add the `mtconnect-dataitem` node to your canvas and open its configuration.
2. Enter the host of your MTConnect agent or broker (for example, `mtconnect.isoc.net`).
3. Enter the port your agent is listening on.
4. Path (optional): leave this empty in most cases. The node automatically detects the type of agent or broker and chooses the correct endpoint:
   - For SolutionEngine agents, it uses `/api/v6/mtc/current`.
   - For generic MTConnect brokers like `mtconnect.isoc.net`, it uses `/current`.
   :brOnly fill in this field if your broker uses a custom endpoint that differs from the defaults. Entering `/current` manually for standard brokers may cause the node to fail.
5. Enter the `dataItemId` for the value you want to retrieve.
6. Once everything is configured, deploy the flow.

To trigger the node, add an Inject node, set the polling interval you want, and connect it to the `mtconnect-dataitem` node. This will fetch the latest data at regular intervals and send it to your dashboard or other nodes in the flow.

When the node successfully retrieves data, it outputs the following fields: `msg.payload` (the value), `dataItemId`, `timestamp`, `sequence`, and `name`. The node also shows the status with a green square when data is found successfully. If the value isn't available, it will display a yellow square.

![MTConnect Data Item node output on debug panel](https://flowfuse.com/blog/2026/02/images/output.png "MTConnect Data Item node output on debug panel")

## Building the Dashboard

Now that you're successfully retrieving MTConnect data, the next step is to display it on a live dashboard. FlowFuse makes this straightforward with its [dashboard package](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"}. You can bind any data item to a visual component, and it updates automatically whenever new data arrives.

Before you start, make sure to install the `@flowfuse/node-red-dashboard` package to add the dashboard nodes.

For this tutorial, we'll demonstrate two example data points: Controller Mode and Spindle Speed. You can apply the same steps to all other data points as an exercise. I'm using a public MTConnect demo agent (<https://demo.mtconnect.org>{rel="&#x22;nofollow&#x22;"}) to make it easy to follow along.

**Note:** This is a brief demonstration to help you understand the workflow. When building your production dashboard, make sure to use the appropriate host and port for your actual MTConnect agent, and select widgets that best suit your specific monitoring needs and use case.

I've provided additional data points with their `dataItemId`s below so you can practice. Try to match the dashboard shown in the image below, or create your own layout by selecting different `dataItemId`s and widget types. For more information on available dashboard widgets, see the FlowFuse documentation: <https://dashboard.flowfuse.com/nodes/widgets>{rel="&#x22;nofollow&#x22;"}.

:video{ariaLabel="MTConnect FlowFuse Dashboard at left and MTConnect demo public agent digital twin at right" autoPlay="true" height="1602" loop="true" muted="true" playsInline="true" preload="none" width="3014"}

### Available Data Points for Practice

| Data Item ID  | Name                     | Description                                       |
| ------------- | ------------------------ | ------------------------------------------------- |
| `execution`   | Execution State          | Program execution status (ACTIVE, READY, STOPPED) |
| `doorstate`   | Door State               | Machine door status (OPEN/CLOSED)                 |
| `program`     | Program Name             | Currently loaded program name                     |
| `activeprog`  | Active Program           | Currently executing program                       |
| `Tool_number` | Tool Number              | Active tool number                                |
| `pallet_num`  | Pallet Number            | Current pallet identifier                         |
| `Xabs`        | X-Axis Absolute Position | Current X-axis absolute position in mm            |
| `Zabs`        | Z-Axis Absolute Position | Current Z-axis absolute position in mm            |
| `Bpos`        | B-Axis Position          | Current B-axis rotational position                |
| `Cpos`        | C-Axis Position          | Current C-axis rotational position                |

### Steps to Create the Dashboard

1. Drag an Inject node onto the canvas, double-click it, and set Repeat to interval for every 1 second.
2. Drag two mtconnect-dataitem nodes onto the canvas and connect them to the inject node.
3. Double-click the first mtconnect-dataitem node and configure it: Host: `demo.mtconnect.org`, Port: `5000`, Data Item ID: `mode`. For the second node, use the same configuration except Data Item ID: `Srpm`. Click Done for both nodes.
4. Drag a Text widget onto the canvas and double-click it. Click the + button next to Group to create a new group: Group Name: `Machine State`, select the page and check Display group name, then click Done.
5. In the Text widget configuration: Label: `Controller Mode:`, Layout: Select the 4th option, enable Style option, Font: Default, Text Size: `26`, then click Done.

![Text widget configuration settings](https://flowfuse.com/blog/2026/02/images/text-widget.png "Text widget configuration settings")

6. Connect the mode mtconnect-dataitem node output to the Text widget input.
7. Drag a Gauge widget onto the canvas and double-click it. Create a new group: Group Name: `Spindle Speed`. In the Gauge widget configuration: Type: Half gauge, Style: Rounded, Value: `msg.payload`, Range limits: `0` to `10000`.
8. Add three segments by clicking the + button in the Segments section and configure them as shown in the image below.

![Gauge widget configuration settings](https://flowfuse.com/blog/2026/02/images/gauge.png "Gauge widget configuration settings")

9. Connect the Srpm mtconnect-dataitem node output to the Gauge widget input.
10. Click Deploy in the top-right corner.

To achieve the page layout as shown in the dashboard I have built, follow the [Setting Page Layout guide](https://flowfuse.com/blog/2024/05/node-red-dashboard-2-layout-navigation-styling/#setting-page-layout) and set it to Notebook.

Your dashboard should now display live updates for Controller Mode and Spindle Speed from the MTConnect agent. You can extend this by adding more data items from the table above, experimenting with different widget types, and organizing them into logical groups for your specific monitoring needs.

Below is the complete flow configuration. If you've successfully built the dashboard following the steps above, you can compare it with this reference implementation:

::render-flow
```json
[{"id":"5daedf163d8ff55a","type":"group","z":"e98fbc22244df867","name":"Spindle Speed","style":{"label":true},"nodes":["52df691dc45e95db","95d475e6ecb616fc","2267147b9ee9cc86"],"x":134,"y":119,"w":652,"h":82},{"id":"52df691dc45e95db","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"5daedf163d8ff55a","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"Srpm","x":430,"y":160,"wires":[["95d475e6ecb616fc"]]},{"id":"95d475e6ecb616fc","type":"ui-gauge","z":"e98fbc22244df867","g":"5daedf163d8ff55a","name":"Spindle Speed","group":"9df7f1ad772380dd","order":1,"value":"payload","valueType":"msg","width":"5","height":3,"gtype":"gauge-half","gstyle":"rounded","title":"","alwaysShowTitle":false,"floatingTitlePosition":"top-left","units":"RPM","icon":"","prefix":"","suffix":"","segments":[{"from":"0","color":"#8d8600","text":"","textType":"value"},{"from":"8000","color":"#d29d00","text":"","textType":"value"},{"from":"9500","color":"#ff4013","text":"","textType":"value"}],"min":0,"max":"10000","sizeThickness":16,"sizeGap":4,"sizeKeyThickness":8,"styleRounded":true,"styleGlow":false,"className":"","x":680,"y":160,"wires":[[]]},{"id":"2267147b9ee9cc86","type":"inject","z":"e98fbc22244df867","g":"5daedf163d8ff55a","name":"Trigger","props":[{"p":"payload"}],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":240,"y":160,"wires":[["52df691dc45e95db"]]},{"id":"9df7f1ad772380dd","type":"ui-group","name":"Spindle Speed","page":"df8568c32d9e9bfa","width":"5","height":"3","order":3,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"df8568c32d9e9bfa","type":"ui-page","name":"MTConnect Dashboard","ui":"34bdc26026de2a48","path":"/page1","icon":"home","layout":"notebook","theme":"ecea95aad5b94726","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":true,"disabled":false},{"id":"34bdc26026de2a48","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":false},{"id":"ecea95aad5b94726","type":"ui-theme","name":"Default Theme","colors":{"surface":"#1f2933","primary":"#00a3d7","bgPage":"#f5f7fa","groupBg":"#ffffff","groupOutline":"#e5e7eb"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"da2bf9f0f5377d70","type":"group","z":"e98fbc22244df867","name":"Machine State","style":{"label":true},"nodes":["8f895b1f6bcb91e9","09c59f876c3785b8","b83ef79948c36e6d","8e820966be8f9874","6fb9250c86c29e88","2d665d743deeac21","4df4be8a5a835810"],"x":134,"y":219,"w":652,"h":202},{"id":"8f895b1f6bcb91e9","type":"inject","z":"e98fbc22244df867","g":"da2bf9f0f5377d70","name":"Trigger","props":[{"p":"payload"}],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":240,"y":320,"wires":[["09c59f876c3785b8","8e820966be8f9874","2d665d743deeac21"]]},{"id":"09c59f876c3785b8","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"da2bf9f0f5377d70","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"mode","x":430,"y":260,"wires":[["b83ef79948c36e6d"]]},{"id":"b83ef79948c36e6d","type":"ui-text","z":"e98fbc22244df867","g":"da2bf9f0f5377d70","group":"44eef3deae3ebe65","order":1,"width":0,"height":0,"name":"","label":"Controller Mode : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":670,"y":260,"wires":[]},{"id":"8e820966be8f9874","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"da2bf9f0f5377d70","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"execution","x":440,"y":320,"wires":[["6fb9250c86c29e88"]]},{"id":"6fb9250c86c29e88","type":"ui-text","z":"e98fbc22244df867","g":"da2bf9f0f5377d70","group":"44eef3deae3ebe65","order":3,"width":0,"height":0,"name":"","label":"Execution : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":650,"y":320,"wires":[]},{"id":"2d665d743deeac21","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"da2bf9f0f5377d70","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"doorstate","x":440,"y":380,"wires":[["4df4be8a5a835810"]]},{"id":"4df4be8a5a835810","type":"ui-text","z":"e98fbc22244df867","g":"da2bf9f0f5377d70","group":"44eef3deae3ebe65","order":2,"width":0,"height":0,"name":"","label":"Door State : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":650,"y":380,"wires":[]},{"id":"44eef3deae3ebe65","type":"ui-group","name":"Machine State","page":"df8568c32d9e9bfa","width":"4","height":1,"order":1,"showTitle":true,"className":"","visible":true,"disabled":false,"groupType":"default"},{"id":"9350e391e87fe7a5","type":"group","z":"e98fbc22244df867","name":"Program & Tool","style":{"label":true},"nodes":["df36b3a29c31ce98","a0217e5e2aa5f44c","0629feeaf7920e2c","2f2a09682b0967db","fdd85c0cb9116148","2067a83f2e4cf2e1","733c2464b32ad3f6","1a8683bb29c9708d","4060d2c10f0cc6d9"],"x":134,"y":439,"w":652,"h":262},{"id":"df36b3a29c31ce98","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"9350e391e87fe7a5","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"program","x":440,"y":480,"wires":[["a0217e5e2aa5f44c"]]},{"id":"a0217e5e2aa5f44c","type":"ui-text","z":"e98fbc22244df867","g":"9350e391e87fe7a5","group":"e7af486f283064fa","order":1,"width":0,"height":0,"name":"","label":"Program (Main)  : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":660,"y":480,"wires":[]},{"id":"0629feeaf7920e2c","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"9350e391e87fe7a5","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"activeprog","x":450,"y":540,"wires":[["2f2a09682b0967db"]]},{"id":"2f2a09682b0967db","type":"ui-text","z":"e98fbc22244df867","g":"9350e391e87fe7a5","group":"e7af486f283064fa","order":4,"width":0,"height":0,"name":"","label":"Program (Active) : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":670,"y":540,"wires":[]},{"id":"fdd85c0cb9116148","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"9350e391e87fe7a5","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"Tool_number","x":450,"y":600,"wires":[["2067a83f2e4cf2e1"]]},{"id":"2067a83f2e4cf2e1","type":"ui-text","z":"e98fbc22244df867","g":"9350e391e87fe7a5","group":"e7af486f283064fa","order":3,"width":0,"height":0,"name":"","label":"Tool ID : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":640,"y":600,"wires":[]},{"id":"733c2464b32ad3f6","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"9350e391e87fe7a5","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"pallet_num","x":450,"y":660,"wires":[["1a8683bb29c9708d"]]},{"id":"1a8683bb29c9708d","type":"ui-text","z":"e98fbc22244df867","g":"9350e391e87fe7a5","group":"e7af486f283064fa","order":2,"width":0,"height":0,"name":"","label":"Pallet ID : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":640,"y":660,"wires":[]},{"id":"4060d2c10f0cc6d9","type":"inject","z":"e98fbc22244df867","g":"9350e391e87fe7a5","name":"Trigger","props":[{"p":"payload"}],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":240,"y":560,"wires":[["df36b3a29c31ce98","fdd85c0cb9116148","0629feeaf7920e2c","733c2464b32ad3f6"]]},{"id":"e7af486f283064fa","type":"ui-group","name":"Program & Tool","page":"df8568c32d9e9bfa","width":"3","height":"2","order":2,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"46321a3ca1be0e85","type":"group","z":"e98fbc22244df867","name":"Position (Work)","style":{"label":true},"nodes":["db9b9d1633807788","e8b23a150120a81e","8547410491f90a0d","130dd01d8d29297f","19099f474caffd2e","2e34c68a3e9a30b2","0c375b39b14df4f1","3f61d2622a728b13","1fbf908ad8b311db","08ddb29a3ec4d7e5","69b9bad3c1781b6e"],"x":134,"y":719,"w":652,"h":322},{"id":"db9b9d1633807788","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"46321a3ca1be0e85","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"Xabs","x":430,"y":760,"wires":[["e8b23a150120a81e"]]},{"id":"e8b23a150120a81e","type":"ui-text","z":"e98fbc22244df867","g":"46321a3ca1be0e85","group":"e697761e6d26019e","order":1,"width":0,"height":0,"name":"","label":"X : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":710,"y":760,"wires":[]},{"id":"8547410491f90a0d","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"46321a3ca1be0e85","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"Yabs","x":430,"y":820,"wires":[["130dd01d8d29297f"]]},{"id":"130dd01d8d29297f","type":"ui-text","z":"e98fbc22244df867","g":"46321a3ca1be0e85","group":"e697761e6d26019e","order":2,"width":0,"height":0,"name":"","label":"Y : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":710,"y":820,"wires":[]},{"id":"19099f474caffd2e","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"46321a3ca1be0e85","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"Zabs","x":430,"y":880,"wires":[["2e34c68a3e9a30b2"]]},{"id":"2e34c68a3e9a30b2","type":"ui-text","z":"e98fbc22244df867","g":"46321a3ca1be0e85","group":"e697761e6d26019e","order":3,"width":0,"height":0,"name":"","label":"Z : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":710,"y":880,"wires":[]},{"id":"0c375b39b14df4f1","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"46321a3ca1be0e85","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"Bpos","x":430,"y":940,"wires":[["3f61d2622a728b13"]]},{"id":"3f61d2622a728b13","type":"ui-text","z":"e98fbc22244df867","g":"46321a3ca1be0e85","group":"e697761e6d26019e","order":4,"width":0,"height":0,"name":"","label":"B : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":710,"y":940,"wires":[]},{"id":"1fbf908ad8b311db","type":"mtconnect-dataitem","z":"e98fbc22244df867","g":"46321a3ca1be0e85","name":"","host":"https://demo.mtconnect.org","port":"5000","path":"","dataItemId":"Cpos","x":430,"y":1000,"wires":[["08ddb29a3ec4d7e5"]]},{"id":"08ddb29a3ec4d7e5","type":"ui-text","z":"e98fbc22244df867","g":"46321a3ca1be0e85","group":"e697761e6d26019e","order":5,"width":0,"height":0,"name":"","label":"C : ","format":"{{msg.payload}}","layout":"row-spread","style":true,"font":"","fontSize":"26","color":"#717171","wrapText":false,"className":"","value":"payload","valueType":"msg","x":710,"y":1000,"wires":[]},{"id":"69b9bad3c1781b6e","type":"inject","z":"e98fbc22244df867","g":"46321a3ca1be0e85","name":"Trigger","props":[{"p":"payload"}],"repeat":"1","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":240,"y":860,"wires":[["db9b9d1633807788","8547410491f90a0d","19099f474caffd2e","0c375b39b14df4f1","1fbf908ad8b311db"]]},{"id":"e697761e6d26019e","type":"ui-group","name":"Position (Work)","page":"df8568c32d9e9bfa","width":6,"height":1,"order":4,"showTitle":true,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"7500e4ba5bb1ce02","type":"global-config","env":[],"modules":{"node-red-contrib-solution-engine":"0.9.4","@flowfuse/node-red-dashboard":"1.30.2"}}]
```
::

## Conclusion

Your MTConnect dashboard is now live, pulling real-time machine data and displaying it through visual widgets. The setup you've built here works the same way across any MTConnect-compliant machine in your facility.

This is what FlowFuse does, it makes connecting to equipment, collecting data, transforming it into useful formats, and visualizing it on dashboards straightforward. Beyond basic monitoring, you can log production metrics to databases for trend analysis, set up automated alerts when machines enter fault states, integrate shop floor data with MES or ERP systems, and build event-driven workflows that respond to machine conditions. For production environments, FlowFuse Enterprise provides role-based access control, audit logging, high availability infrastructure, and dedicated support, giving you the operational controls needed to run manufacturing applications reliably across multiple facilities.


# Modbus TCP vs Modbus RTU: Reliability, Latency, and Failure Modes

Modbus shipped in 1979. It has outlasted every protocol that was meant to replace it, survived the transition from relay logic to microprocessors and modern SCADA systems, and is still running production lines today. That kind of longevity does not happen by accident. It exists because the protocol is simple, deterministic, and unambiguous, at least in its original form, a point I have discussed in more detail in a [separate article](https://flowfuse.com/blog/2026/01/why-modbus-still-exist/).

Then TCP came along. The data model stayed the same, identical function codes and identical register maps. But the assumptions underneath changed completely, including expectations about the network, failure modes, and what happens when things go wrong. The industry gained real capability, but it also inherited an entirely new class of problems, ones that look nothing like the challenges Modbus engineers spent forty-seven years learning to solve.

That gap is what most people miss. And it is exactly what this post is about.

## They Are Not the Same Protocol in Different Clothes

Modbus RTU runs over serial. That sounds simple until you consider what serial actually means in practice: one master, multiple slaves, one conversation at a time. The master initiates every transaction, the slave responds, and nothing else happens on the wire until that exchange completes.

The physical layer is almost always RS-485 in industrial installations, a differential pair that can run hundreds of meters, tolerate significant electrical noise, and connect up to 247 devices on a single bus.

That architecture imposes hard constraints. Only one device can transmit at a time. Timing between bytes within a frame matters: RTU uses silence on the line to mark frame boundaries, so a gap of 3.5 character times signals the end of one message and the start of the next. Get the baud rate wrong, introduce a noisy cable that stretches a byte, or misconfigure inter-character timing, and the frame parser loses its place. The message is silently discarded. No retransmission, no acknowledgment, just a timeout.

![Image showing Modbus RTU on RS-485 and Modbus TCP on Ethernet.](https://flowfuse.com/blog/2026/02/images/modbus-rtu-and-tcp-physical-layer.png "Image showing Modbus RTU on RS-485 and Modbus TCP on Ethernet.")

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

Modbus TCP moves the same application layer onto Ethernet and wraps it in a TCP socket. The serial constraints disappear. Multiple masters can coexist, transactions can be pipelined, and the physical layer handles collision detection and retransmission. What you gain in flexibility, you trade for a different set of assumptions. TCP guarantees delivery, but not timing. A retransmission storm on a busy network can stretch response times in ways that RTU, for all its limitations, never would.

## Latency: What the Numbers Actually Mean on the Floor

RTU latency is predictable almost to the microsecond. That sounds like a strength until you realize how slow predictable can be.

At 9600 baud, a typical Modbus RTU transaction (request plus response) takes 50 to 100 milliseconds per device. Move to 115200 baud and that drops under 10 milliseconds. But you are still polling sequentially. Ten devices at 9600 baud means your slowest sensor gets updated once per second at best. Add more devices and the math gets worse in a straight line.

That ceiling matters. A real-world example: a water treatment plant running 32 RTU devices on a single RS-485 bus at 9600 baud had a worst-case poll cycle of nearly four seconds. When the control engineer needed tighter feedback on a pH dosing loop, the only options were to reduce the device count on that segment, split the bus, or increase baud rate, all of which required physical work on a running system.

Modbus TCP removes the baud rate ceiling and adds pipelining. A well-configured TCP master can have multiple transactions in flight simultaneously. On a lightly loaded Ethernet network, round trip times under 2 milliseconds are routine. For many applications, that is enough to stop thinking about latency altogether.

![Chart comparing Modbus RTU polling latency with Modbus TCP network latency](https://flowfuse.com/blog/2026/02/images/modbus-rtu-tcp-latency.png "Chart comparing Modbus RTU polling latency with Modbus TCP network latency")

The catch is that Ethernet latency is not flat. It varies with network load, switch queue depth, and the TCP stack on the device side. Most of the time the numbers look excellent. Under the wrong conditions, they do not. A PLC with a modest embedded TCP stack, hit with traffic from a network scan or a broadcast storm, can stretch its response time by an order of magnitude. RTU would have delivered the same response time it always does.

RTU offers better worst-case latency. TCP offers better average latency. In industrial control, worst-case is usually what you design for.

## Failure Modes: What Breaks, How It Breaks, and Whether You Will Know

This is where the two protocols diverge most sharply, and where choosing wrong costs the most.

### RTU Failures Are Loud and Physical

RTU failures tend to be physical. A corroded terminal block. A cable run too close to a variable frequency drive. A termination resistor missing from one end of the bus. The symptoms are usually obvious: CRC errors climb, devices stop responding, the master logs timeouts.

What RTU rarely does is fail silently. Framing errors and timeouts are visible. The master knows a transaction failed. The application layer gets a clear signal that something is wrong, even if locating the fault takes time.

Locating it is the hard part. RS-485 is a shared medium, which means a single bad connection can drag down every device on the segment. Isolating which node is responsible requires methodical disconnection or a bus analyzer. Neither is fast at 2 AM with a line down.

**But at least you know it is down.**

### TCP Failures Are Quiet and Strange

TCP failures are quieter and more varied. The physical layer is more robust: Ethernet cable is forgiving, switches regenerate signals, and a single bad port does not take down the network. But the failure surface is much broader.

A device can be electrically healthy and passing traffic, yet still behave badly. Connection state gets out of sync. A TCP socket on a cheap embedded device does not close cleanly after a timeout, leaving the master waiting on a half-open connection that looks alive but delivers nothing. A managed switch renegotiating link speed during a firmware update introduces 30 seconds of elevated latency that looks, from the application's perspective, like a slow device.

The worst TCP failures are the ones that are almost working. Partial connectivity. Occasional dropped transactions. Response times elevated but not elevated enough to trip a timeout threshold.

![Half-open TCP socket failure where the master waits on a connection that never responds.](https://flowfuse.com/blog/2026/02/images/modbus-tcp-open-connection-failure.png "Half-open TCP socket failure where the master waits on a connection that never responds.")

RFC 793 formally defines the half-open state: when one end of a TCP connection crashes or closes without notifying the other, the remaining side may wait indefinitely on a connection that appears alive and delivers nothing ([RFC 793, Section 3.4](https://www.rfc-editor.org/rfc/rfc793){rel="&#x22;nofollow&#x22;"}). Rockwell Automation's troubleshooting documentation describes how conditions like duplex mismatches during switch replacement can produce exactly this pattern: performance that degrades quietly and stays within configured thresholds ([Rockwell Automation, ENET-AT003](https://literature.rockwellautomation.com/idc/groups/literature/documents/at/enet-at003_-en-p.pdf){rel="&#x22;nofollow&#x22;"}).

RTU tends to fall over cleanly. TCP tends to degrade quietly. Degraded is harder to catch than broken.

### TCP Introduces a Failure Mode That RTU Never Had: Security

Modbus has no authentication. On a serial bus, that is usually acceptable, because physical access to the wire implies physical access to the facility. On an Ethernet network, that assumption collapses entirely.

Modbus TCP devices reachable from a corporate network, or worse from the internet, will respond to commands from anyone who sends them. No credentials. No audit trail. No way to distinguish a legitimate master from an attacker with a laptop and a Modbus client.

This is not theoretical. Shodan regularly turns up Modbus TCP devices with publicly routable IP addresses. ICS security assessments routinely find Modbus exposed on flat networks shared with corporate IT. The clearest demonstration of what that exposure enables is [FrostyGoop](https://www.dragos.com/blog/protect-against-frostygoop-ics-malware-targeting-operational-technology/){rel="&#x22;nofollow&#x22;"}, malware discovered by Dragos in 2024 and the first ever to use Modbus TCP to cause direct physical impact. Attackers targeted a district energy company in Lviv, Ukraine supplying heat to over 600 apartment buildings, port 502 was open to the internet, no network compromise required, and remediation took nearly two days while residents endured sub-zero temperatures. No credentials were needed. Modbus provided none to ask for.

RTU is not inherently secure either, but attacking it requires being physically present on the wire. TCP removes that requirement entirely.

## Choosing Between Them

Most engineers do not choose between RTU and TCP from a blank slate. They inherit a system, get handed a specification, or discover that the device they need only supports one of them. The real decision is narrower: whether what is already in place is appropriate for what the system now needs to do.

RTU is the right answer when device count is small, cable runs are already there, polling rates are modest, and nothing outside the cabinet needs to reach the network. Those conditions describe a large percentage of working industrial installations. Changing a system that meets all of them adds risk for no operational benefit.

TCP makes sense when you need to integrate field devices with higher-level systems like SCADA, historians, or MES, when device count or poll rate has grown beyond what serial can comfortably handle, or when the network already exists and adding serial infrastructure would cost more than it saves. It also makes sense when you need multiple masters, which serial cannot support without external arbitration hardware.

The hybrid case is a serial network running reliably for fifteen years, with a gateway at the head end converting RTU to TCP for the SCADA system. It is more common than either pure scenario, and more sensible than it looks on paper. The gateway adds a failure point, but it also insulates field devices from the corporate network. That insulation is worth keeping. Replacing it to simplify the architecture is usually not the right trade.

## What to Actually Do Differently Based on This

If you are deploying RTU: use the highest baud rate the cable length and device count will reliably support, do not leave devices at 9600 baud out of habit; document your bus topology, because when something fails at night the person troubleshooting will not be you; and install proper termination resistors at both ends of every RS-485 segment, since this causes more problems than almost anything else.

If you are deploying TCP: isolate Modbus devices on a dedicated VLAN or network segment and never put them on the corporate LAN; configure short TCP timeouts and explicit connection retry logic in your master, because half-open connections will happen; and log poll latency over time, since degradation that stays inside timeout thresholds will not alarm and you have to trend it.

If you are maintaining a hybrid gateway architecture, resist the urge to rationalize it away. It is doing work.

The two protocols make different guarantees, fail differently, and require different diagnostic skills when something goes wrong. Understanding that distinction before the system is designed costs nothing. Understanding it for the first time during an incident costs considerably more.

For a practical guide to connecting Modbus PLCs, alongside OPC UA, EtherNet/IP, and Siemens S7, to MQTT, cloud, and enterprise systems, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).


# Building an AI Vibration Anomaly Detector for Industrial Motors

Bearing wear, shaft misalignment, and imbalance don't appear overnight. They develop over days or weeks, leaving a clear trail in vibration data long before any audible or thermal symptoms emerge. By the time a technician hears grinding or feels heat, the window for low-cost intervention has already closed.

The challenge isn't visibility: it's continuity. Manual spot-checks capture a fraction of developing faults, and only if the timing is lucky. What's needed is something that watches constantly, understands what normal looks like, and flags the moment something shifts.

This guide walks through building exactly that: a custom AI model that learns the healthy vibration signature of your motor, detects deviations in real time, and integrates directly into Node-RED using FlowFuse with no separate ML infrastructure required.

:lite-youtube{style="width: 100%; aspect-ratio: 16/9; background-image: url('/blog/2026/02/images/anomaly-detection.png'); background-size: cover; background-position: center;" title="Motor Anomaly Detection System Built Using FlowFuse" videoid="Fkv2x3Kv0lY"}

## How It Works

An accelerometer mounted on the motor captures vibration across three axes (X, Y, Z) and publishes batches of raw readings to an MQTT broker every half-second. A Node-RED flow subscribes to those readings, extracts 33 statistical features per batch (covering energy, peak forces, shape, and distribution across all three axes) and passes them to a trained autoencoder.

### Why an Autoencoder?

An [autoencoder](https://en.wikipedia.org/wiki/Autoencoder){rel="&#x22;nofollow&#x22;"} is a neural network trained to compress its input and then reconstruct it. The architecture used here is:

```text
Input (33) → Dense (16) → Dense (8) → Dense (16) → Output (33)
```

The bottleneck layer (8 nodes) forces the model to learn a compact representation of the input. When trained exclusively on healthy motor data, the model learns to reconstruct normal vibration patterns with very low error. When conditions change (a bearing begins to wear, alignment drifts, imbalance develops) the vibration signature shifts, reconstruction error rises, and the system flags an anomaly.

This approach is well-suited to industrial use because you almost certainly have abundant examples of normal operation, but few or no labeled examples of specific fault modes. You don't need to know what failure looks like; you only need to define what normal looks like.

## Building the System

The implementation has three stages: setting up hardware to collect vibration data, training the autoencoder on normal operation, and deploying the trained model in Node-RED for real-time inference.

## Part 1: Hardware and Data Requirements

This guide assumes you already have a vibration sensor publishing batches of acceleration readings across X, Y, and Z axes at regular intervals. The examples were built using an ESP32 wired to an ADXL345 accelerometer. If your hardware differs, the rest of the steps remain unchanged as long as your sensor publishes the same payload format.

### Expected Payload Format

Each MQTT message contains a half-second snapshot of motor vibration. The sensor captures 256 measurements per axis and packages them into a single JSON payload:

```json
{
  "motor_id": "motor-01",
  "ts": 1718000000000,
  "x": [0.12, 0.11, 0.13, 0.14, ...],
  "y": [0.04, 0.05, 0.04, 0.03, ...],
  "z": [0.98, 0.97, 0.99, 0.96, ...]
}
```

At 500 Hz sampling, 256 values represent roughly half a second of continuous vibration. This batching approach matters because it gives the AI model enough context to detect patterns: a single data point is meaningless, but 256 points reveal the behavioral signature of how the motor is actually running.

The `motor_id` and `ts` fields are ignored by the model and can be omitted or renamed without effect.

> **If your sensor uses different settings:** The feature extraction math works regardless of sample count or sampling rate. If your sensor samples at 200 Hz and sends 128 values per batch, each window represents 640 ms instead of 500 ms; the model doesn't care about absolute timing, only the shape of the vibration signature. Aim for at least 100–200 ms of data per window; anything shorter may not carry enough signal for reliable detection.

### MQTT Broker

You'll need an MQTT broker to route messages between the sensor, the training script, and Node-RED. Make sure your sensor is publishing to a consistent topic so all three can stay in sync.

> **Tip:** If you're using [FlowFuse](https://flowfuse.com) for enterprise Node-RED, a built-in MQTT broker is available on **Pro** and **Enterprise** tiers with no external setup required. [Contact us](https://flowfuse.com/contact-us) for more information.

## Part 2: Training the Autoencoder

Before deploying anything in Node-RED, you need a trained model that understands what normal motor vibration looks like. This is done with a single Python script that connects to your MQTT broker, collects vibration data while the motor runs normally, then automatically trains and exports the model when you're done.

### Prerequisites

**System requirements:** Python 3.11 or later. The steps below were tested on macOS (Apple Silicon); adapt as needed for Linux or Windows.

Create and activate a virtual environment:

```bash
python3 -m venv venv
source venv/bin/activate
```

> **Windows:** Replace `source venv/bin/activate` with `venv\Scripts\activate`.

Install dependencies:

```bash
pip3 install numpy paho-mqtt torch onnx onnxruntime scikit-learn
```

### Configuration

All setup lives in a single configuration block at the top of the script. Before running, update these variables to match your environment:

| Variable          | Description                                                                                                     |
| ----------------- | --------------------------------------------------------------------------------------------------------------- |
| `BROKER`          | Hostname or IP of your MQTT broker                                                                              |
| `PORT`            | `1883` for plain MQTT, `8883` for TLS                                                                           |
| `USERNAME`        | Broker username. Leave empty `""` if not required                                                               |
| `PASSWORD`        | Broker password. Leave empty `""` if not required                                                               |
| `CLIENT_ID`       | Any unique string identifying this client                                                                       |
| `TOPIC`           | The MQTT topic your sensor publishes to                                                                         |
| `MIN_WINDOWS`     | Minimum samples to collect before training (default: 300)                                                       |
| `MIN_STD`         | Minimum standard deviation floor that prevents near-constant features from skewing normalisation (default: 0.1) |
| `CLIP`            | Hard clamp applied after normalisation to prevent extreme values (default: 5.0)                                 |
| `EPOCHS`          | Number of training epochs (default: 200)                                                                        |
| `LEARNING_RATE`   | Adam optimizer learning rate (default: 0.001)                                                                   |
| `THRESHOLD_SIGMA` | Multiplier for threshold calculation: `mean + N × std` of training errors (default: 3)                          |

> **Threshold tuning:** The default `mean + 3σ` threshold is a solid starting point, but every motor environment is different. If you see too many false positives during normal operation, increase `THRESHOLD_SIGMA`. If faults are being missed, decrease it. You can also edit `threshold.json` directly after training without rerunning the script.

### Collect and Train

Create a file called `train_model.py` and paste the following. &#x2A;*Start the motor first, then run the script.** The model needs to learn what running vibration looks like. Collecting data with the motor stopped or barely loaded will produce a model that treats idle conditions as normal and misses real anomalies.

```python
"""
Motor Vibration Anomaly Detection: Data Collection and Training
"""

import json
import signal
import sys
import numpy as np
import torch
import torch.nn as nn
import onnx
import onnxruntime as ort
from onnx import numpy_helper, TensorProto, helper
import paho.mqtt.client as mqtt
from paho.mqtt.client import CallbackAPIVersion

# ── Configuration ────────────────────────────────────────────────────────────
BROKER         = "broker.example.com"            # Your MQTT broker address or IP
PORT           = 1883                            # 1883 for plain MQTT, 8883 for TLS
USERNAME       = ""                              # Leave as "" if broker has no auth
PASSWORD       = ""                              # Leave as "" if broker has no auth
CLIENT_ID      = "motor-trainer-01"             # Any unique string for this client
TOPIC          = "factory/motor-01/vibration/raw" # Must match your sensor's publish topic

# ── Training parameters ───────────────────────────────────────────────────────
MIN_WINDOWS    = 300    # Minimum samples before training is allowed
MIN_STD        = 0.1    # Prevents near-constant features from exploding normalisation
CLIP           = 5.0    # Hard clip applied after normalisation
EPOCHS         = 200    # Number of training epochs
LEARNING_RATE  = 1e-3   # Adam optimiser learning rate
THRESHOLD_SIGMA = 3     # Threshold = mean + N * std of training reconstruction errors
# ─────────────────────────────────────────────────────────────────────────────

training_data = []
stop_flag = [False]

def extract_features(sig):
    """Extract 11 time-domain features from a signal array."""
    sig  = np.asarray(sig, dtype=np.float64)
    mean = np.mean(sig)
    std  = np.std(sig) + 1e-9

    rms              = np.sqrt(np.mean(sig ** 2))
    peak             = np.max(np.abs(sig))
    peak_to_peak     = np.max(sig) - np.min(sig)
    crest_factor     = peak / (rms + 1e-9)
    variance         = np.var(sig)
    std_dev          = np.std(sig)
    skewness         = np.mean(((sig - mean) / std) ** 3)
    kurtosis         = np.mean(((sig - mean) / std) ** 4) - 3
    mean_abs         = np.mean(np.abs(sig)) + 1e-9
    shape_factor     = rms / mean_abs
    impulse_factor   = peak / mean_abs
    mean_sqrt_abs    = np.mean(np.sqrt(np.abs(sig)))
    clearance_factor = peak / (mean_sqrt_abs ** 2 + 1e-9)

    return [rms, peak, peak_to_peak, crest_factor, variance,
            std_dev, skewness, kurtosis, shape_factor,
            impulse_factor, clearance_factor]

def featurize(payload):
    """Concatenate features from X, Y, Z → 33-element vector."""
    return (extract_features(payload["x"]) +
            extract_features(payload["y"]) +
            extract_features(payload["z"]))

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code == 0:
        print(f"Connected to {BROKER}")
        client.subscribe(TOPIC)
        print(f"Subscribed to {TOPIC}")
        print("Run motor normally. Press Ctrl+C when done collecting.\n")
    else:
        print(f"Connection failed: {reason_code}")

def on_message(client, userdata, msg):
    if stop_flag[0]:
        return
    try:
        payload = json.loads(msg.payload.decode())
        training_data.append(featurize(payload))
        n = len(training_data)
        print(f"  Collected {n} windows", end="\r")
    except Exception as e:
        print(f"\nError parsing message: {e}")

def train_and_export():
    N = 33
    print(f"\n\nCollected {len(training_data)} windows. Starting training...")
    X = np.array(training_data, dtype=np.float32)

    # Normalisation with minimum std floor
    mean = X.mean(axis=0)
    std  = X.std(axis=0)

    clamped = std < MIN_STD
    if clamped.any():
        print(f"  Clamping {clamped.sum()} near-constant features to std={MIN_STD}")
        std[clamped] = MIN_STD

    X_norm = np.clip((X - mean) / std, -CLIP, CLIP)
    print(f"  Normalised range: [{X_norm.min():.3f}, {X_norm.max():.3f}]")

    scaler = {"mean": mean.tolist(), "std": std.tolist(), "clip": CLIP}
    with open("scaler_params.json", "w") as f:
        json.dump(scaler, f, indent=2)
    print("  Saved scaler_params.json")

    # Autoencoder definition
    class Autoencoder(nn.Module):
        def __init__(self, n):
            super().__init__()
            self.encoder = nn.Sequential(
                nn.Linear(n, 16), nn.ReLU(),
                nn.Linear(16, 8), nn.ReLU(),
            )
            self.decoder = nn.Sequential(
                nn.Linear(8, 16), nn.ReLU(),
                nn.Linear(16, n),
            )
        def forward(self, x):
            return self.decoder(self.encoder(x))

    model   = Autoencoder(N)
    opt     = torch.optim.Adam(model.parameters(), lr=LEARNING_RATE)
    loss_fn = nn.MSELoss()
    data_t  = torch.tensor(X_norm, dtype=torch.float32)

    model.train()
    for epoch in range(1, EPOCHS + 1):
        opt.zero_grad()
        loss = loss_fn(model(data_t), data_t)
        loss.backward()
        opt.step()
        if epoch % (EPOCHS // 5) == 0:
            print(f"  Epoch {epoch}/{EPOCHS}  loss={loss.item():.6f}")

    # Calculate threshold
    model.eval()
    with torch.no_grad():
        recon  = model(data_t).numpy()
        errors = np.mean((recon - X_norm) ** 2, axis=1)
        thresh = float(errors.mean() + THRESHOLD_SIGMA * errors.std())

    with open("threshold.json", "w") as f:
        json.dump({"threshold": thresh}, f, indent=2)
    print(f"  Threshold (mean+{THRESHOLD_SIGMA}σ): {thresh:.6f}")
    print("  Saved threshold.json")

    # Export to ONNX
    # Built manually to avoid version conflicts between PyTorch and ONNX exporters
    layers   = [("encoder.0","enc0"),("encoder.2","enc2"),
                ("decoder.0","dec0"),("decoder.2","dec2")]
    has_relu = [True, True, True, False]
    inits, nodes = [], []
    cur = "features"

    for (prefix, tag), relu in zip(layers, has_relu):
        w = model.state_dict()[f"{prefix}.weight"].numpy().T.astype(np.float32)
        b = model.state_dict()[f"{prefix}.bias"].numpy().astype(np.float32)
        inits += [numpy_helper.from_array(w, name=f"w_{tag}"),
                  numpy_helper.from_array(b, name=f"b_{tag}")]
        mm = f"mm_{tag}"; add = f"add_{tag}"
        nodes += [helper.make_node("MatMul", [cur, f"w_{tag}"], [mm]),
                  helper.make_node("Add",    [mm,  f"b_{tag}"], [add])]
        cur = add
        if relu:
            r = f"relu_{tag}"
            nodes.append(helper.make_node("Relu", [cur], [r]))
            cur = r

    graph = helper.make_graph(
        nodes, "autoencoder",
        [helper.make_tensor_value_info("features", TensorProto.FLOAT, [None, N])],
        [helper.make_tensor_value_info(cur, TensorProto.FLOAT, [None, N])],
        initializer=inits,
    )
    proto = helper.make_model(graph, opset_imports=[helper.make_opsetid("", 11)])
    proto.ir_version = 7
    onnx.checker.check_model(proto)
    onnx.save(proto, "motor_autoencoder.onnx")
    print("  Exported motor_autoencoder.onnx")

    # Sanity check
    sess = ort.InferenceSession("motor_autoencoder.onnx")
    out  = sess.run(None, {"features": X_norm[:5].astype(np.float32)})[0]
    mse  = float(np.mean((out - X_norm[:5]) ** 2))
    print(f"\n  Sanity MSE (5 normal samples): {mse:.6f}  threshold: {thresh:.6f}")
    if mse < thresh:
        print("  ✓ Model correct , normal data scores below threshold.")
    else:
        print("  ⚠ Sanity MSE above threshold , collect more data and retrain.")

    print("\nDone. Copy these 3 files to your Node-RED server:")
    print("  motor_autoencoder.onnx  scaler_params.json  threshold.json")

def handle_sigint(sig, frame):
    stop_flag[0] = True
    if len(training_data) < MIN_WINDOWS:
        print(f"\n\nNeed at least {MIN_WINDOWS} windows. Restart and collect longer.")
        sys.exit(1)
    train_and_export()
    sys.exit(0)

signal.signal(signal.SIGINT, handle_sigint)

client = mqtt.Client(callback_api_version=CallbackAPIVersion.VERSION2,
                     client_id=CLIENT_ID)
client.username_pw_set(USERNAME, PASSWORD)
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()
```

Let it collect for 5–10 minutes (aim for 300+ windows), then press **Ctrl+C once** and wait. The script will train the model and export three files:

- `motor_autoencoder.onnx` , the trained model in a portable, runtime-agnostic format
- `scaler_params.json` , the scaling parameters used to normalise input features
- `threshold.json` , the reconstruction error value above which a reading is flagged as anomalous

> **Sanity check:** Watch the output at the end. `✓ Model correct` means the model correctly scores normal data below the threshold. A warning means you should collect more data with the motor under its typical load and retrain.

### When to Retrain

The model captures what normal looks like at the time of training. Plan to retrain after any significant change to the motor's operating conditions: a maintenance overhaul, a change in load profile, a new mounting position, or seasonal temperature shifts that affect the vibration baseline. The process is identical, run the script again with the motor under its new normal conditions, replace the three output files, and restart the Node-RED flow.

## Part 3: Deploying in Node-RED

The model now knows what healthy looks like. This section builds the Node-RED flow that runs continuously, scores every incoming vibration batch in real time, and raises an alert the moment something shifts.

### Installing the AI Nodes

FlowFuse provides a dedicated AI nodes package for Node-RED that includes ONNX runtime support.

> **Note:** These nodes are only available to FlowFuse users. If you don't have an account, [get started here](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and follow the steps to [run the device agent](https://flowfuse.com/blog/2025/09/installing-node-red/).

1. Open the Node-RED editor and go to **Menu → Manage Palette**
2. Search for `@flowfuse-nodes/nr-ai-nodes`
3. Click **Install**

Once installed, you will see new nodes in the palette under the FlowFuse AI category. This guide uses the **onnx** node.

![FlowFuse AI nodes visible in the Node-RED palette under the FlowFuse AI category](https://flowfuse.com/blog/2026/02/images/ai-nodes.png "FlowFuse AI nodes visible in the Node-RED palette under the FlowFuse AI category")

### Loading the Model Files

Place your three model files in the FlowFuse Device Agent directory before building the flow:

```bash
sudo mkdir -p /opt/flowfuse-device/models
sudo cp motor_autoencoder.onnx /opt/flowfuse-device/models/
sudo cp scaler_params.json /opt/flowfuse-device/models/
sudo cp threshold.json /opt/flowfuse-device/models/
```

### Building the Inference Flow

The flow has five stages: receive the payload, extract features, scale and prepare, run inference, and score the result.

**1. Subscribe to MQTT**

Add an **mqtt-in** node and configure it to connect to the same broker and topic used during training. Set the output to auto-detect so the JSON payload is parsed automatically.

If you are using the built-in FlowFuse MQTT broker, use the [FlowFuse MQTT nodes](https://flowfuse.com/node-red/flowfuse/mqtt/) , these connect automatically when dragged into the flow.

**2. Extract Features**

Add a **function** node. In the **Setup** tab, add the module `fs`. Then paste the following into the **On Message** tab:

```javascript
function extractFeatures(sig) {
    const arr = sig.map(Number);
    const n = arr.length;
    const mean = arr.reduce((a, b) => a + b, 0) / n;
    const std = Math.sqrt(arr.reduce((a, b) => a + (b - mean) ** 2, 0) / n) + 1e-9;
    const absArr = arr.map(Math.abs);
    const rms = Math.sqrt(arr.reduce((a, b) => a + b * b, 0) / n);
    const peak = Math.max(...absArr);
    const meanAbs = absArr.reduce((a, b) => a + b, 0) / n + 1e-9;
    const meanSqrtAbs = absArr.reduce((a, b) => a + Math.sqrt(b), 0) / n;
    return [
        rms, peak, Math.max(...arr) - Math.min(...arr),
        peak / (rms + 1e-9),
        arr.reduce((a, b) => a + (b - mean) ** 2, 0) / n,
        Math.sqrt(arr.reduce((a, b) => a + (b - mean) ** 2, 0) / n),
        arr.reduce((a, b) => a + ((b - mean) / std) ** 3, 0) / n,
        arr.reduce((a, b) => a + ((b - mean) / std) ** 4, 0) / n - 3,
        rms / meanAbs, peak / meanAbs, peak / (meanSqrtAbs ** 2 + 1e-9),
    ];
}

// Scaler and threshold are cached in flow context after the first message.
// If you update the model files, restart the Node-RED flow to reload them.
if (!flow.get('scaler')) {
    const sc = JSON.parse(fs.readFileSync('/opt/flowfuse-device/models/scaler_params.json'));
    const th = JSON.parse(fs.readFileSync('/opt/flowfuse-device/models/threshold.json'));
    flow.set('scaler', sc);
    flow.set('threshold', th.threshold);
}

const scaler = flow.get('scaler');
const CLIP = scaler.clip || 5.0;
const MIN_STD = 0.1;

const raw = [
    ...extractFeatures(msg.payload.x),
    ...extractFeatures(msg.payload.y),
    ...extractFeatures(msg.payload.z)
];

const normalised = raw.map((v, i) => {
    const s = Math.max(scaler.std[i], MIN_STD);
    const n = (v - scaler.mean[i]) / s;
    return Math.max(-CLIP, Math.min(CLIP, n));
});

msg.input = {
    data: new Float32Array(normalised),
    type: "float32",
    dims: [1, 33]
};
msg.payload = msg.input;
msg.threshold = flow.get('threshold');
return msg;
```

This function extracts 11 time-domain features per axis (33 total), loads the scaler on first run, and normalises the feature vector. The `MIN_STD` floor and `±CLIP` clamp mirror the values used during training and prevent near-constant features from producing extreme values, which are a common source of false positives with vibration sensors.

> **If you changed the model file path**, update the two `readFileSync` paths to match your chosen directory.

**3. Run the Model**

Add an **onnx** node and configure it:

- **Model path:** `/opt/flowfuse-device/models/motor_autoencoder.onnx`
- **Input:** `msg.payload`

The autoencoder compresses the 33-feature input through the bottleneck and reconstructs it on the output side. The reconstructed tensor is accessible in the next node via `msg.payload`. Since the output key name depends on how the ONNX graph was exported, the scoring node retrieves it dynamically rather than relying on a hardcoded name.

**4. Score the Reconstruction Error**

Add a second **function** node:

```javascript
if (!context.get('initialized')) {
    flow.set('score_history', []);
    context.set('initialized', true);
}

// Generic output key lookup, works regardless of tensor name
const outputKey = Object.keys(msg.payload)[0];
const reconstructed = msg.payload[outputKey].cpuData;

const input = Array.from(msg.input.data);
const threshold = msg.threshold;

const mse = input.reduce((s, v, i) => s + (reconstructed[i] - v) ** 2, 0) / input.length;

let history = flow.get('score_history') || [];
history.push(mse);
if (history.length > 10) history.shift();
flow.set('score_history', history);

const smoothed = history.reduce((a, b) => a + b, 0) / history.length;

msg.anomaly_score = smoothed;
msg.is_anomaly    = smoothed > threshold;
msg.severity      = smoothed > threshold * 2 ? 'CRITICAL' : smoothed > threshold ? 'WARNING' : 'NORMAL';
msg.payload       = { anomaly_score: smoothed, threshold, is_anomaly: msg.is_anomaly, severity: msg.severity };
return msg;
```

This function computes mean squared error between the model's reconstruction and the normalised input, applies a 10-window rolling average to reduce sensitivity to transient spikes, then classifies the result as `NORMAL`, `WARNING`, or `CRITICAL`.

> **Recovery time:** After an anomaly clears, the score returns to normal once the rolling window fills with healthy readings , typically 10 × your publish interval. At 500 ms publishing, that's roughly 5 seconds. Reduce the history window size for faster recovery; increase it to suppress false alarms.

Once deployed, the flow should look like this:

![Completed Node-RED inference flow showing MQTT input, feature extraction function node, ONNX node, and anomaly scoring function node](https://flowfuse.com/blog/2026/02/images/flow.png "Completed Node-RED inference flow showing MQTT input, feature extraction function node, ONNX node, and anomaly scoring function node")

**5. Act on the Result**

Connect the scoring output to whatever suits your operation. For testing, a debug node shows results in real time. For production, an mqtt-out node can publish anomaly alerts downstream, the [FlowFuse Dashboard](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"} package can visualise the anomaly score over time with a clear motor state indicator, and alerting nodes can notify your team directly, via [Telegram](https://flowfuse.com/node-red/notification/email/), [email](https://flowfuse.com/node-red/notification/telegram/), or [SIGNL4](https://flowfuse.com/blueprints/other/mobile-alerting/) for structured mobile alerts with on-call scheduling and acknowledgement tracking.

### What the Output Looks Like

Each message produces a structured result:

```json
{
  "anomaly_score": 0.842,
  "threshold": 0.703,
  "is_anomaly": true,
  "severity": "WARNING"
}
```

When `is_anomaly` is `false`, the motor is behaving within the expected range. When it flips to `true`, the vibration pattern has shifted beyond the acceptable boundary, giving you time to act before the problem becomes a failure. A severity of `CRITICAL` means the score has crossed twice the threshold, signalling a more significant deviation that warrants immediate attention.

## What This System Won't Tell You

This approach works well, but it's worth being clear about where it stops.

The autoencoder learns a statistical boundary around the vibration patterns it was trained on. It doesn't understand physics, it doesn't know the difference between a worn bearing and a loose mounting bolt, and it has no concept of severity beyond the reconstruction error score. When it flags an anomaly, it's telling you that something has changed, not what changed or why. Diagnosing the root cause still requires a technician with domain knowledge.

Training data quality matters more than model architecture. A model trained on data collected while the motor was lightly loaded, recently serviced, or running in cool ambient conditions will treat those as "normal." If real operating conditions differ, the threshold may be poorly calibrated from day one, generating either chronic false positives or, worse, missing genuine faults. There's no substitute for collecting training data under representative, sustained, real-world load.

False positives are inevitable in early deployment. External vibration from nearby equipment, transient load spikes, or sensor cable movement can all push the score above threshold momentarily. The rolling average window helps, but it doesn't eliminate them. Treat the first few weeks as a calibration period: log alerts, investigate them, and adjust `THRESHOLD_SIGMA` or the window size based on what you learn. The system improves with attention.

Finally, anomaly detection is an early warning layer, not a maintenance strategy on its own. It tells you to look sooner, not what to do when you get there. Pair it with regular physical inspection, lubrication schedules, and, where possible, a domain expert who can interpret the alerts in context. Used that way, it earns its place. Used as a replacement for those things, it will eventually let you down.


# How to Build an MQTT-to-InfluxDB Data Pipeline (2026)

An MQTT to InfluxDB is one of the most common and most critical pipelines in IIoT. Every timestamped telemetry event that drives decisions on the floor needs to land somewhere it can be queried, trended, and acted on.

:product-update-note

The typical approach is a custom Python script that subscribes to the broker, parses the payload, and writes to InfluxDB. It works until a sensor changes its payload format, or the script quietly dies over a weekend and nobody notices until Monday. Now you're debugging a process nobody else fully understands, with no visibility into what failed or when. Others stitch together multiple tools, each with its own config, its own failure modes, and its own logs to dig through at 2am. The complexity ends up hidden in places that are hard to see, hard to debug, and hard to hand off.

This article takes a different approach. Using FlowFuse (the enterprise platform built on [Node-RED](https://flowfuse.com)), you'll build the entire pipeline as a visual flow covering MQTT subscription, payload transformation, and InfluxDB write. Every step is visible, editable, and easy to hand off.

## TL;DR

- **What**: Build an MQTT-to-InfluxDB pipeline that subscribes to a broker, transforms the payload, and writes time-series data to InfluxDB.
- **How**: Three nodes in FlowFuse: MQTT in, change node for transformation, and InfluxDB out. No custom scripts or glue code.
- **Why FlowFuse**: Every step is visual, editable, and easy to hand off. When something breaks, you know exactly where to look.

## Prerequisites

Before you start, make sure you have the following in place.

- A running FlowFuse instance. If you don't have one yet, [sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} to get started.
- An MQTT broker. FlowFuse Pro and Enterprise include a [built-in broker](https://flowfuse.com/docs/user/teambroker/), and the [MQTT nodes](https://flowfuse.com/node-red/flowfuse/mqtt/) configure themselves automatically. If you are using an external broker, keep your host, port, and credentials handy.
- A running InfluxDB instance, either local or on InfluxDB Cloud. Keep your URL, token, organization, and bucket name handy.

## Building the Pipeline

The flow has three stages. An MQTT in node subscribes to your broker and receives incoming sensor payloads. A change node transforms that payload into the structure InfluxDB expects. An InfluxDB out node takes that structured data and writes it to your bucket. That's the entire pipeline. Let's build it.

![MQTT to InfluxDB architecture illustrating sensor data ingestion via MQTT, transformation in FlowFuse, and storage in an InfluxDB bucket](https://flowfuse.com/blog/2026/02/images/mqtt-to--influxdb-architecture.png "MQTT to InfluxDB architecture illustrating sensor data ingestion via MQTT, transformation in FlowFuse, and storage in an InfluxDB bucket")

### Step 1: Install the InfluxDB Node

Node-RED does not include an InfluxDB node out of the box, so you will need to install it first.

1. Open the Node-RED editor in your FlowFuse instance.
2. Click the main menu in the top right corner and select Manage Palette.
3. Go to the Install tab and search for [node-red-contrib-influxdb](https://flowfuse.com/integrations/node-red-contrib-influxdb/).
4. Click Install. Once complete, the InfluxDB nodes will appear in your palette on the left side.

![Node-RED editor palette displaying the InfluxDB nodes added via the node-red-contrib-influxdb package.](https://flowfuse.com/blog/2026/02/images/influxdb-nodes.png "Node-RED editor palette displaying the InfluxDB nodes added via the node-red-contrib-influxdb package.")

### Step 2: Configure the MQTT In Node

Drag an MQTT in node onto the canvas and double-click it to open its settings. Click the pencil icon next to the Server field to add a new broker connection.

1. Enter your broker host in the Server field and set the Port.
2. Select `MQTT 3.1.1` as the protocol version.
3. Leave the Client ID blank to let Node-RED generate one automatically.
4. The keepalive is 60 seconds by default, so there’s no need to change it.
5. Check `Automatically unsubscribe when disconnecting`.

![MQTT broker connection settings in Node-RED showing server, port, protocol version, and client ID fields.](https://flowfuse.com/blog/2026/02/images/mqtt-in--config.png "MQTT broker connection settings in Node-RED showing server, port, protocol version, and client ID fields.")

6. Switch to the Security tab and enter your broker username and password.
7. Click Add to save the broker configuration.

![MQTT broker security tab in Node-RED showing username and password fields.](https://flowfuse.com/blog/2026/02/images/mqtt-in--security.png "MQTT broker security tab in Node-RED showing username and password fields.")

If you are on FlowFuse Pro or Enterprise, the built-in broker details will already be picked up by the node and you can skip the above.

Once the broker is configured:

1. Set the Topic to `acme-motors/detroit/welding/line-1/robot-3/temperature`.
2. Set QoS to 2 to minimize message loss and reduce duplicates between the broker and Node-RED. For true end-to-end de-duplication, add an idempotency strategy (for example, a unique key or timestamp handling) before writing to InfluxDB.
3. Give the node the name `robot 3 temperature` and click Done.

![MQTT in node configured in Node-RED with topic set to the ISA-95 hierarchy and QoS set to 2.](https://flowfuse.com/blog/2026/02/images/mqtt--in.png "MQTT in node configured in Node-RED with topic set to the ISA-95 hierarchy and QoS set to 2.")

### Step 3: Transform the Payload with a Change Node

When the MQTT in node receives a message, `msg.payload` will look like this:

```json
{
  "timestamp": 1738830735000,
  "value": 187.6,
  "unit": "celsius",
  "sensor_id": "temp-robot-3",
  "status": "normal"
}
```

The InfluxDB out node does not accept this structure directly. With `node-red-contrib-influxdb`, the easiest pattern is to pass `msg.payload` as an array, the first containing the fields to write and the second containing the tags. In InfluxDB, fields are the values you aggregate and query over, while tags are metadata used mainly for filtering and grouping. Getting this split right matters because you cannot aggregate or perform math on tags, only on fields.

1. Drag a change node onto the canvas and connect it to the MQTT in node.
2. Double-click it to open its settings and add the following rules:
   - Set `msg.measurement` to the string value `temperature`. If your payload already contains the measurement name, you can set `msg.measurement` dynamically from `msg.payload.measurement` instead, making the flow reusable across multiple sensors without any changes. Otherwise, you can configure the measurement name directly in the InfluxDB out node.
   - Set `msg.payload` to the JSONata expression:

```text
     [{"value": payload.value, "status": payload.status, "time": payload.timestamp}, {"sensor_id": payload.sensor_id, "unit": payload.unit}]
```

3. Give the node the name `transform for influxdb` and click Done.

![Change node in Node-RED configured with rules to transform the MQTT payload into the InfluxDB structure.](https://flowfuse.com/blog/2026/02/images/change-node-influxdb-influxdb-transform.png "Change node in Node-RED configured with rules to transform the MQTT payload into the InfluxDB structure.")

### Step 4: Configure the InfluxDB Out Node

1. Drag an InfluxDB out node onto the canvas and connect it to the change node.
2. Double-click it to open its settings and click the pencil icon next to the Server field to add a new InfluxDB connection.
   - Set Version to `2.0`.
   - Enter your InfluxDB instance URL.
   - Enter your API token.
3. Click Add to save the connection.

![InfluxDB server configuration in Node-RED showing version, URL, and API token fields.](https://flowfuse.com/blog/2026/02/images/influxdb--config.png "InfluxDB server configuration in Node-RED showing version, URL, and API token fields.")

4. Set the Organization to your organization name.
5. Set the Bucket to the bucket you want to write data into.
6. Leave the Measurement field blank since we are passing it via `msg.measurement` from the change node. If you prefer to hardcode it, enter `temperature` here.
7. Give the node the name `write to influxdb` and click Done.

![InfluxDB out node configured in Node-RED with organization, bucket, and measurement fields.](https://flowfuse.com/blog/2026/02/images/influxdb-node.png "InfluxDB out node configured in Node-RED with organization, bucket, and measurement fields.")

### Step 5: Deploy and Test

With all three nodes connected, click the Deploy button in the top right corner of the Node-RED editor. Once deployed, the flow will immediately start listening for messages on the topic you configured.

As your sensor publishes readings, open your InfluxDB instance and navigate to Data Explorer. Select your bucket, filter by measurement, and run the query. You should see the values and tags coming in from the pipeline.

If no data appears, open the Node-RED debug panel and check for any error messages on the InfluxDB out node. The most common issues are an incorrect API token, a mismatched organization name, or a bucket that does not exist yet in InfluxDB.

## Conclusion

Most MQTT-to-InfluxDB pipelines don't fail because the technology is wrong. They fail because the implementation is invisible: a script running somewhere, maintained by someone, that nobody else fully understands until it stops working.

What you've built here flips that. Three nodes, one canvas, zero ambiguity about where data comes from, how it's shaped, and where it lands. When something breaks, and in IIoT, something always eventually breaks, you're not grepping through logs or reverse-engineering a process. You're looking at a flow that tells you exactly what happened and where.

From here, the pipeline is yours to grow. Handle multiple sensors by parameterizing the topic and measurement. Add a catch node so malformed payloads get logged instead of silently dropped. Connect your InfluxDB bucket to a FlowFuse dashboard and put live telemetry on the floor where operators can actually see it.

The three nodes you deployed today are the foundation. Everything else is just adding to what's already visible.


# MQTT vs CoAP: Measure Your Constraints or Pick Wrong

The MQTT vs CoAP debate is mostly noise. One protocol assumes you have infrastructure and want centralized coordination. The other assumes you don't and can't. If you're still debating which is "better," you haven't measured what matters.

MQTT dominates because it solved the hard problem: coordinating thousands of devices through centralized brokers with persistent connections, pub/sub semantics, and delivery guarantees. CoAP survived because some deployments can't afford that solution, not as a tradeoff, but as a physical impossibility. Battery-powered sensors often can't afford long-lived TCP connections (or frequent reconnects), depending on duty cycle, radio, and power budget. Microcontrollers with 16KB RAM can't run MQTT stacks. Mesh networks at the edge can't reach brokers reliably.

These aren't competing protocols. They're answers to incompatible constraints. MQTT requires infrastructure you can reach and connections you can sustain. CoAP requires neither. Pick MQTT for constrained devices, and watch batteries drain in months instead of years. Pick CoAP for cloud-coordinated fleets, and rebuild pub/sub patterns badly.

This article shows what each protocol actually demands, where each fails under real constraints, and why teams consistently choose wrong, not because they pick inferior technology, but because they never validated their deployment requirements.

## What Actually Separates These Protocols

To choose between CoAP and MQTT, you need to understand what these protocols do and what architectural assumptions they force on your system.

MQTT uses a publish/subscribe model. Devices publish messages to topics. Other devices subscribe to those topics. A central broker handles routing, persistence, and delivery guarantees. This works well for many IoT scenarios: sensors broadcasting telemetry, commands flowing to actuators, aggregating data from thousands of devices into a single pipeline. The broker decouples publishers from subscribers, enabling flexible topologies and simplified client logic. But it also requires a mandatory intermediary, a single point that must be scaled, secured, and kept reliable.

CoAP uses a request/response model. It mirrors HTTP's client-server architecture but strips the overhead that makes HTTP unsuitable for constrained devices. CoAP runs over UDP by default, supports multicast discovery, and operates peer-to-peer without centralized infrastructure. Resources are addressed using URIs. Clients request data. Servers respond.

This isn't just a difference in wire format. It's a difference in architectural philosophy. MQTT assumes centralized coordination is beneficial. CoAP assumes it may not be necessary or even possible. That distinction shapes how these protocols behave under network failures, how they scale at the edge, and what happens when infrastructure becomes unreliable or unavailable.

## Where CoAP Has Real Advantages

CoAP's architectural choices create measurable benefits in three specific scenarios.

### Ultra-Constrained Devices

CoAP was built for devices with severe resource limits: sensors running on coin cell batteries for years, microcontrollers with kilobytes of RAM, networks where every transmission costs energy and money. In these environments, MQTT's TCP requirement and broker dependency create overhead that isn't just inefficient, it's prohibitive.

Consider the protocol overhead. An MQTT connection requires a TCP three-way handshake, then protocol negotiation. Even with minimal configuration, that's multiple round trips before any application data moves. For a sensor that wakes once per hour to send a temperature reading, this overhead destroys battery life.

MQTT-SN (MQTT for Sensor Networks) attempts to bridge this gap by adapting MQTT for UDP and removing the TCP requirement. While it reduces some overhead, it still requires gateway infrastructure to translate between MQTT-SN and standard MQTT brokers, preserving the centralized architecture that CoAP avoids entirely.

CoAP uses UDP, has tiny message headers (as small as 4 bytes), and operates without persistent connections. This makes it objectively more efficient. Field deployments of agricultural sensors, building automation, and environmental monitoring have demonstrated power consumption reductions of 40-60% when switching from MQTT to CoAP in ultra-constrained scenarios.

The math is straightforward: fewer transmissions, smaller packets, no connection state. When your device budget is measured in microwatts and your network budget in bytes per day, CoAP is often the only viable option.

### Edge Architectures Without Internet Connectivity

CoAP's advantages become more pronounced at the system level. As more processing moves to the edge for latency, bandwidth, or regulatory reasons, the value of a centralized broker decreases. Edge gateways coordinating local sensors, device-to-device communication in factories, deployments where internet connectivity is intermittent or absent, in these scenarios, CoAP's ability to work peer-to-peer without infrastructure is a genuine advantage.

Consider a factory floor with hundreds of sensors and actuators coordinating through a local gateway. With MQTT, every sensor-to-actuator interaction must route through the broker, even when both devices are physically adjacent. The broker becomes a mandatory hop, adding latency and creating a single point of failure.

With CoAP, devices communicate directly. The gateway can still aggregate and forward data to the cloud when needed, but local control loops operate independently. When the internet connection drops, local operations continue. When latency matters, safety interlocks in industrial equipment, eliminating the broker hop can mean the difference between meeting requirements and failing them.

This distinction matters even more in mobile or disconnected scenarios: autonomous vehicles coordinating with roadside infrastructure, offshore platforms where satellite bandwidth is expensive, emergency networks operating with degraded connectivity.

### Integration with Web Infrastructure

When distributed systems need to communicate with backend infrastructure, CoAP offers another benefit: it aligns with web semantics. CoAP deliberately mirrors HTTP: URIs, methods (GET, POST, PUT, DELETE), content negotiation, status codes. This means it integrates naturally with RESTful systems, web proxies, and developer tools built around HTTP.

For organizations already using REST APIs, CoAP presents a lower barrier than MQTT's topic-based model. HTTP-to-CoAP proxies are straightforward because the semantic models align. MQTT-to-HTTP bridges require significant translation. Topics must map to endpoints. QoS semantics must adapt. Pub/sub patterns must be forced into request/response or require additional infrastructure like webhooks.

None of this is impossible. Organizations bridge MQTT and HTTP successfully every day. But the mismatch is real and introduces complexity that CoAP avoids by design.

## Where MQTT Still Dominates

These CoAP advantages are real. But if we stop here, we miss the bigger picture. MQTT isn't being displaced, and the reason goes deeper than momentum. In most production IoT deployments, MQTT's architectural choices aren't limitations, they're features that solve problems CoAP cannot.

### Publisher/Subscriber Decoupling

The pub/sub model is a fundamental decoupling mechanism that enables capabilities difficult or impossible with request/response.

Consider industrial telemetry. Thousands of sensors publishing measurements. Multiple backend systems consuming that data: a time-series database for analysis, a rules engine for alerts, a machine learning pipeline for predictive maintenance, a dashboard for operators.

With MQTT, adding a new consumer is trivial. Subscribe to the topics. The sensors don't know you exist. They don't need reconfiguration or firmware updates. The decoupling is complete.

With CoAP, this becomes complex. If sensors are servers, how do new clients discover them? If sensors are clients pushing data, where do they push? How do you add a destination without reconfiguring every device? You end up rebuilding what a broker provides, service discovery, routing, fan-out, but distributed across your device fleet instead of centralized in infrastructure you control.

This is why MQTT dominates cloud ingestion. When your architecture is about collecting data from many devices and distributing it to many consumers, the broker model is the right abstraction.

### Delivery Guarantees

The broker provides something CoAP struggles to match: robust delivery guarantees across unreliable networks.

MQTT's three QoS levels (at most once, at least once, exactly once) are fundamental guarantees many production systems require. CoAP, being UDP-based, offers optional confirmable messages with retransmission. This works for many scenarios, but it's not equivalent to MQTT's QoS 2 (exactly once delivery). If your application cannot tolerate duplicates, financial transactions, command-and-control, state machine updates, MQTT's exactly-once semantics are non-negotiable.

MQTT's QoS guarantees are end-to-end through the broker. Messages can persist to disk. Sessions resume after disconnection. Client state is maintained. This makes MQTT significantly more resilient to network instability and device mobility.

### Ecosystem Maturity

These technical advantages are amplified by years of real-world deployment and community investment. MQTT has battle-tested brokers (Mosquitto, EMQX, HiveMQ, VerneMQ). Comprehensive client libraries in every language. Integration with major IoT platforms (AWS IoT Core, Azure IoT Hub) and widely used broker/vendor ecosystems. Monitoring tools, debugging utilities, best practices, and a large community that has solved common problems.

CoAP has matured significantly, but its ecosystem is smaller. This reflects where the use cases are. Cloud ingestion, telemetry aggregation, command and control, these patterns dominate IoT. CoAP's narrower focus on ultra-constrained devices and peer-to-peer edge scenarios means fewer developers encounter it, fewer tools get built, fewer problems get solved publicly.

Network effects matter. When MQTT is the default, more effort improves MQTT tooling, which makes MQTT more attractive, which reinforces its position.

### Session State and Message Queuing

MQTT provides another capability CoAP implementers often underestimate: stateful session management.

MQTT's persistent sessions enable offline message queuing. If a device disconnects, battery dies, network drops, enters a tunnel, messages published to its subscribed topics get queued by the broker and delivered when it reconnects. This is invaluable for mobile devices, intermittently connected sensors, and scenarios where guaranteed delivery matters more than real-time delivery. Examples include fleet management tracking vehicles, medical devices uploading telemetry, and remote monitoring in areas with poor connectivity.

CoAP can implement message queuing, but it requires additional infrastructure, essentially building broker-like services for state management and persistence. At which point, you've rebuilt the pattern MQTT provides natively.

## Security: Choose Based on What You Can Measure

MQTT and CoAP impose fundamentally different security architectures. MQTT's broker creates a centralized security choke point with TLS-protected connections, certificate-based authentication, and topic-level authorization. This simplifies policy enforcement and audit trails but introduces measurable overhead, a TLS handshake consumes 30-50% of total power for sensors transmitting hourly, prohibitive for ultra-constrained devices where battery life is measured in years.

CoAP distributes security across peer-to-peer networks. DTLS provides encrypted UDP communication with similar handshake costs to TLS. For constrained deployments, OSCORE enables application-layer security without connection establishment, reducing wake time by 60-80%. But this efficiency trades centralized control for distributed key management complexity that scales poorly without additional infrastructure.

The architectural trade-off is concrete: MQTT centralizes authentication and policy enforcement but requires broker infrastructure with power overhead. CoAP eliminates broker dependency but pushes authorization to individual devices, requiring distributed policy updates and log aggregation.

The most common security failure is choosing based on perceived simplicity rather than measured requirements. Teams select MQTT assuming TLS is well understood, then discover field batteries depleting in weeks. Teams choose CoAP to avoid broker dependency, then realize they cannot revoke compromised credentials without manual intervention across distributed devices.

Before choosing, measure connection establishment cost in actual power consumption for your device profile, operational cost of key management at your projected scale, and whether your compliance requirements favor centralized audit trails or distributed authorization. The right security model is the one that matches the operational reality you can actually sustain.

## The Measurement Discipline That Matters

What separates successful deployments from failed ones isn't choosing the "better" protocol. It's starting with measured constraints rather than architectural preferences.

The teams that ship working systems know their sensor consumes 12 microamps in sleep and 45 milliamps during transmission. A CR2032 battery provides 235 milliamp-hours. For three-year operation, the math reveals a daily transmission budget of roughly 200 messages. Protocol overhead becomes concrete. Connection establishment costs aren't theoretical, they determine whether you meet requirements or miss by months.

Teams that struggle start with vague requirements. "Low power" sounds reasonable until batteries die early in field trials. "Real-time" invites endless debate until you specify "actuator response within 50 milliseconds for 99% of events." Precision transforms discussion into engineering.

If you need to decouple thousands of publishers from dozens of consumers with guaranteed delivery across unreliable networks, MQTT's broker model provides exactly that. The centralized architecture handles message routing, persistence, and quality of service.

If your constraint is battery operation where every transmission costs operational lifetime, and infrastructure cannot be deployed reliably, CoAP's lightweight UDP approach becomes necessary. TCP overhead and broker coordination would exceed your power budget.

If your system genuinely spans both contexts, use both protocols where each fits. The constraints will make this obvious.

Most failed projects share a common pattern. They selected protocols before measuring deployment reality. They assumed requirements without validation. They copied architectures without understanding the underlying trade-offs. Then field deployment revealed the gaps.

So before choosing between MQTT and CoAP, answer these with measured data:

- What is your power budget per device?
- What transmission frequency and payload size does your application require?
- How does latency behave under network degradation?
- During partitions, can operations continue locally or must activity queue?
- What do infrastructure costs look like at production scale?

If you cannot answer with measurements, build a prototype. Instrument it. Run it under realistic conditions. Measure power, latency, and costs under stress. Then choose based on evidence, not assumptions.

The protocol debate becomes irrelevant once you measure. MQTT and CoAP each solve distinct problems well. Understand your constraints, and the choice becomes clear.


# Shop Floor AI: Dead on Arrival Without This

Your industrial AI initiative is dying. Maybe it's already dead.

Not because the models are wrong. Not because the data scientists failed. Not because you didn't spend enough on sensors or compute power.

It's dying because you're building on a foundation that was never designed to support it.

You instrumented everything: motors, conveyors, bearings, valves, streaming thousands of data points per second. Historians filled to capacity. Dashboards displayed every metric. AI models trained on millions of records. Yet despite all this technology, you still can't see what's happening until something breaks.

The problem isn't your AI. It's the architecture underneath it.

This article reveals why most industrial AI projects fail before they start: why raw signals without context are just noise, why your three disconnected data layers doom AI from day one, and why a Unified Namespace is the only architecture that makes industrial AI actually work on the shop floor.

Twenty years ago, a skilled operator could diagnose a failing machine by sound, smell, or vibration. Today's machines still communicate just as clearly. They've simply switched languages. They produce numbers that nobody understands. A temperature spike, a current drift, a vibration anomaly: each is meaningless without knowing which product is running, under what conditions, with which maintenance history, and how this system typically behaves.

The problem isn't AI capability. It's poor architecture. Signals without context are difficult to interpret. Context without connection never reaches the people who need it. And decisions made without information are guesses at best.

For AI to actually work on the factory floor, we need three things working in concert: signals that feed context, context that creates understanding, and AI that empowers humans to ask the right questions at the right time.

## The Three-Layer Problem

Most manufacturers diagnose themselves with an AI problem. Their models don't predict failures. Their anomaly detection drowns in false positives. Their optimization recommendations get politely ignored.

They're diagnosing the wrong disease. Most factory floors aren't ready for AI.

This isn't an AI problem. It's an architecture problem that AI just makes impossible to ignore. Your data exists in three disconnected layers, and until you bridge them, no amount of machine learning can help.

### Layer One: The Signal Layer

Raw data accumulates here. PLCs, SCADA, historians, MES systems, all generating measurements at rates human cognition was never designed to process. Temperature, pressure, flow, current draw, RPM, torque, position. Millisecond timestamps. Perfect fidelity. Absolutely zero meaning.

The signal layer has no concept of importance. When a conveyor motor pulls 2.3 amps, that's just a number in a database. The system doesn't know if this represents peak efficiency or the warning sign of a dying gearbox.

But nobody knows which question to ask until something fails. Then you're analyzing historical data files, reconstructing what happened. It's post-incident analysis when what you needed was real-time diagnosis.

The signal layer does exactly one thing well: it remembers everything. What it can't do is understand anything.

### Layer Two: The Context Layer

Context is everything the signal doesn't tell you. Which product is currently running. The ambient conditions. The maintenance history. The supplier change that wasn't documented. The operator who runs things hot because it's faster. The firmware update that altered control loop timing.

This layer exists in fragments, scattered across ERP systems, maintenance logs, Excel files, shift handover notes, and inside the heads of people who might retire next year.

Without this layer, signals are just sequential numbers. With it, they become useful information. They tell you not just what is happening, but why it matters, what it resembles, and what typically comes next.

The fundamental problem: we never built systems to unite these layers. Different databases, different teams, different vendors, different security models. Integration became a six-month IT project instead of a core design principle.

Your data has context, but it's locked away where neither your people nor your AI can see it.

### Layer Three: The Human Decision Layer

This is where humans operate, increasingly overwhelmed by the gap between what they can see and what they need to know.

An alarm sounds. An operator has 30 seconds to decide: Is this real or noise? Critical or routine? Stop the line or log and monitor? The context they need is fragmented across three systems they can't access and two colleagues on different shifts.

So they decide based on experience and instinct. Sometimes they're right. Sometimes they're not. Either way, the decision logic gets lost - there's no system capturing why they chose what they did.

Engineers face the inverse problem: too much time and too much data. By the time they've extracted historian data, correlated it with production schedules, and cross-referenced maintenance records, the problem has either resolved itself or gotten worse.

This is where AI should enter, not as a decision-maker, but as an intelligent assistant. The human decision layer needs AI that can answer questions in real-time: "Is this vibration pattern normal for this product recipe?" "When did we last see this current signature?" "What were the conditions the last three times this alarm triggered?"

The decision remains human. The insight becomes instant.

## Why This Architecture Breaks AI

You can't fix a three-layer problem with a one-layer solution.

Companies repeatedly make the same mistake: they drop AI models directly into the signal layer (pure time-series analysis on raw sensor data) then wonder why predictions are worthless. The model identifies a pattern, but it's blind to the fact that context just changed. It flags anomalies that are actually normal for this product recipe. It misses failures because the signal appeared fine while the context indicated problems.

But here's what's crucial to understand: AI is ready for the factory floor right now. Not ready to take autonomous action, but ready to be the most knowledgeable assistant your operators and engineers have ever had.

Think about what you actually need. When an operator sees unusual behavior, they need answers immediately: "Is this normal?" "What happened last time?" "Should I be concerned?" When an engineer investigates a problem, they need to explore data at depth: "Show me all the times we saw this pattern." "What were the ambient conditions?" "How does this compare across shifts?"

AI can answer these questions instantly if it has access to the right architecture.

Industrial AI fails when you ignore the architecture. You need the signal layer feeding a context layer that's actually integrated, queryable, and current. You need decision support that operates at the speed questions get asked, not at the speed IT can generate a report.

## The Architecture Solution

The challenge isn't the layers themselves, but the gaps between them.

So what would an architecture look like that actually closes these gaps? What would it take to have signals arrive already carrying context? To have that context accessible the moment a question gets asked? To give AI and humans the same unified view of what's happening right now?

The requirements are clear: you need operational data organized the way factories actually run - by site, area, line, and asset. You need context added at the moment data enters the system, not reconstructed hours later. You need a single source of truth that every system can access in real time.

This isn't a future vision. This architecture exists, and it's been battle-tested in manufacturing operations worldwide.

It's called the [Unified Namespace (UNS)](https://flowfuse.com/blog/2023/12/introduction-to-unified-namespace/).

A Unified Namespace is a shared, real-time, event-driven structure where operational data flows with its context intact. Instead of systems integrating point-to-point, every system publishes to and consumes from the same namespace. Signals arrive already carrying context.

In a UNS, a motor current is no longer just a number stored in a historian. It's published as *Line 3 / Conveyor 2B / Motor Current*, alongside the active recipe, operating mode, ambient conditions, and relevant maintenance history. Every system sees the same structured truth, continuously updated.

This shift in architecture is what makes AI viable on the factory floor.

Building a Unified Namespace requires three things:

1. Connecting incompatible industrial systems
2. Enriching raw signals with operational context as data flows
3. Publishing that context once, over MQTT, so AI and humans can consume it in real time

This is where flow-based integration becomes essential.

Tools like [Node-RED](https://flowfuse.com/node-red/) make UNS architectures practical. Instead of writing custom integration code, engineers visually wire systems together. PLCs publishing over Modbus, MES systems exposing REST APIs, and proprietary SCADA protocols can all be connected, normalized, and enriched as data moves through the flows.

FlowFuse builds on Node-RED to make this architecture production-ready. It adds centralized deployment, version control, access control, and remote management: the capabilities required to operate a Unified Namespace reliably across lines, plants, and teams.

Crucially, in a Unified Namespace, context is added at the moment data enters the system, not reconstructed later. A motor current isn't simply forwarded. It's enriched with equipment hierarchy, product recipe, operating mode, environmental conditions, and timestamps aligned with production events.

That enriched information is then published into a shared MQTT-based Namespace. One location. One structure. One source of truth. Dashboards, analytics, and AI systems all subscribe to the same contextualized view of reality.

Through [FlowFuse MCP nodes](https://flowfuse.com/node-red/flowfuse/mcp/), AI systems connect directly to the namespace, querying live operational context instead of pulling raw time-series data from isolated historians and attempting to reconstruct meaning after the fact.

[FlowFuse AI Expert](https://flowfuse.com/ai/&#x29; operates on the same MCP-backed context layer. Operators and engineers can ask questions in natural language (&#x2A;"Is Line 3 behaving normally?"&#x2A;, &#x2A;"Have we seen this vibration pattern before?"&#x2A;, &#x2A;"What changed before the last failure?"*) and receive answers grounded in the live Unified Namespace.

To learn how to build your own Unified Namespace with FlowFuse, [see our comprehensive guide](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/).

The result is immediate insight without additional tooling, custom integrations, or fragile data pipelines. The architecture already exists. The context is already there. The questions can finally be asked at the speed decisions are made.

## Final Thoughts

Your industrial AI isn't failing because the models are bad. It's failing because the architecture was never designed to support it.

Most manufacturers make the same mistake: they bolt AI onto existing infrastructure - historians full of raw signals, context scattered across disconnected systems, decisions made with incomplete information. Then they wonder why predictions are worthless and anomaly detection drowns in false positives.

You can't solve a three-layer problem with a one-layer solution.

The Unified Namespace fixes this by doing what should have been done from the start: uniting signals with context in real time. A motor current stops being "2.3 amps" in a database and becomes operational intelligence - which line, which equipment, which recipe, what maintenance history, what patterns preceded past failures.

This is the foundation AI needs. Not more data. Not better models. Context that transforms signals into understanding.

With this architecture in place, AI shifts from a failed prediction engine to what it should be: a tool that multiplies operational expertise. It doesn't replace human judgment. It enables faster, better-informed decisions backed by complete operational context.

Manufacturers who build this architecture first get operations that learn from every incident, engineering teams that diagnose root causes in minutes instead of days, and confidence in decisions because they're based on understanding rather than guesswork.

The path forward isn't better AI models. It's better architecture. Build the Unified Namespace first. The AI will finally work.

*[Start with FlowFuse today](https://flowfuse.com/contact-us/). Build the architecture your industrial AI needs to succeed.*


# Event-Driven Architecture: 99% of Your System Requests Are Worthless

Nearly 99% of the requests your manufacturing systems make return the same answer: nothing changed. The 1% that matter? You find out too late. This isn't a monitoring problem. It's an architecture problem.

*Event-Driven Architecture (EDA) flips this model entirely. Instead of systems asking questions on a schedule, they listen for events and react the moment something happens, eliminating the gap between occurrence and response.*

In manufacturing, an "event" is any significant occurrence. A machine completes a cycle. A sensor detects an anomaly. A part fails inspection. Inventory hits a threshold. When these events occur, they are immediately broadcast to all interested systems, which respond automatically and in parallel.

When a machine finishes a production run, it triggers an event. Instantly, the inventory system updates stock levels. Maintenance logs machine hours. Quality control schedules an inspection. Production planning releases the next order. No manual intervention. No waiting.

This is what real-time responsiveness looks like in practice. Faster issue detection, dynamic optimization, and the ability to absorb disruptions before they cascade.

## The Structural Limits of Traditional Manufacturing Systems

Traditional manufacturing systems operate on request-response models. The MES queries the ERP for inventory counts. SCADA polls sensors at fixed intervals. Quality systems run batch processes to aggregate data. Each system asks for what it needs, when it needs it. This worked when manufacturing moved slowly. It breaks down in modern production environments.

The waste is structural. Nearly 99 out of every 100 polling requests return no new information, and polling models consume orders of magnitude more server resources than event-driven alternatives to maintain the same data freshness. Bandwidth and processing power are spent confirming that nothing has changed.

Between polling intervals lies real risk. A fault appears on the floor at 9:14:01 AM. The monitoring system, configured to poll every five minutes, won't detect it until 9:15:00. During those 59 seconds, defective output flows downstream while costs accumulate at rates exceeding $38,000 per minute in automotive facilities. Schedules drift. Quality issues propagate. The gap between what's happening and what the business knows keeps widening.

Point-to-point integrations make this worse. Connection counts follow the n(n-1)/2 formula. Five systems require ten connections. Ten systems demand 45. Each connection carries its own protocol, authentication scheme, and maintenance overhead. A firmware update means manual remapping across dozens of endpoints. New functionality requires weeks of integration work. A single failure can cascade through every tightly coupled system downstream.

The architecture that once enabled the factory now constrains it.

## How Event-Driven Architecture Works

Every polling system works the same way. Your MES wakes up on a timer and asks if anything changed. Usually nothing has. So it waits, then asks again. Multiply this across every system pair on your floor and you have an architecture that spends most of its energy confirming that nothing has happened.

EDA inverts this. Every significant occurrence gets broadcast the moment it happens. Any system that needs to know receives it immediately. Systems that don't are never involved.

![Diagram comparing traditional polling-based manufacturing systems with event-driven architecture, showing delayed fault detection in polling versus instant system notification using an event broker](https://flowfuse.com/blog/2026/02/images/polling-vs-eda.png "Diagram comparing traditional polling-based manufacturing systems with event-driven architecture, showing delayed fault detection in polling versus instant system notification using an event broker")

Three components make this possible. Event producers generate the signal. PLCs, sensors, vision systems. Their only responsibility is to announce what happened. Event consumers act on it. The MES updates work orders. The ERP adjusts inventory. The maintenance platform logs runtime hours. Each subscribes only to relevant events and acts independently, so multiple consumers can respond to the same event simultaneously. The event broker connects them without coupling them. It receives events, routes them to subscribers, and keeps a durable log. Neither side needs to know the other exists. Adding a new consumer means subscribing it to the broker. Nothing else changes.

That last property is what solves the integration complexity problem. In point-to-point architectures, every new connection requires negotiated APIs and coordinated work across teams. The broker absorbs that complexity entirely.

The durable log solves a problem polling handles poorly. Events that occur while a system is offline are replayed in order when it comes back. Transient outages stop being data integrity problems. The record of what happened on the floor stays complete regardless of which systems were available when it happened.

## The Business Impact of Running on Events

Most factories don't lose money because their equipment is bad. They lose it because their systems are slow to know what's happening and slower to act on it.

That slowness isn't a people problem. It's structural. When your systems communicate by asking rather than listening, there's always a gap between what's happening on the floor and what the business knows about it. Teams fill that gap with buffers, manual checkpoints, and end-of-shift reports. It works until it doesn't.

EDA closes that gap. When something happens, every system that needs to know finds out immediately. The right processes trigger automatically. No polling cycle. No batch job. No one manually connecting the dots.

The scale of what's at stake makes this worth stating plainly. Unscheduled downtime costs the world's largest manufacturers trillions annually, representing a double-digit percentage of revenue. Nearly three-quarters of manufacturing leaders report that delays in reporting problems trigger chain reactions across their operations. These aren't technology metrics. They're business outcomes produced by architectures that were never designed to respond in real time.

Quality compounds the same way. The 1-10-100 rule of manufacturing quality states that a defect costs [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[1]{.mord}[t]{.mord.mathnormal}[oc]{.mord.mathnormal}[a]{.mord.mathnormal}[t]{.mord.mathnormal}[c]{.mord.mathnormal}[h]{.mord.mathnormal}[p]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[]{.mspace style="margin-right:0.2222em;"}[−]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[p]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[d]{.mord.mathnormal}[u]{.mord.mathnormal}[c]{.mord.mathnormal}[t]{.mord.mathnormal}[i]{.mord.mathnormal}[o]{.mord.mathnormal}[n]{.mord.mathnormal}[,]{.mpunct}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 10 to catch during production, and $100 once it reaches the customer. Every minute a failed inspection goes unbroadcast to downstream systems, that multiplier is running. EDA stops the propagation at the source by ensuring the result is instantly visible to every process that needs to act on it.

Integration debt follows the same logic. Enterprise-level manufacturing software implementations routinely take many months to multiple years. Every new capability your team wants requires a project. EDA changes the economics entirely. New systems subscribe to the broker. Existing systems stay untouched. What once consumed quarters now requires configuration.

And when something does go wrong, you have a complete timestamped record of everything that happened on the floor. Not reconstructed timelines. Root cause analysis that took days takes hours. Audits have a chain of custody by default.

The factories pulling ahead right now aren't the most automated. They're the ones where information moves as fast as production does. Every minute that gap exists, it has a cost. EDA removes it.

## What It Takes to Move to Event-Driven Architecture

The hardware is already there. Sensors, [PLCs](https://flowfuse.com/blog/2025/12/what-is-plc/), [SCADA systems](https://flowfuse.com/use-cases/scada/). All running. EDA doesn't replace them. It changes how they communicate.

You need an event broker and something that connects to legacy systems. [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/) for shop floor devices. Kafka for enterprise loads. [Node-RED](https://flowfuse.com/node-red/) to bridge the gap. That's the stack.

The real work is defining what counts as an event. A sensor produces tens of thousands of readings per day. Broadcasting all of them is noise. The event is when temperature crosses a threshold, stays abnormal, or trends wrong. Exceptions, not data points.

Your team already knows which deviations matter. Which delays cascade. Which variations are normal. Get this wrong and you build a system that generates alerts faster than anyone can ignore them.

Start where waiting costs the most. Downtime reported late doesn’t need better sensors. The stop event needs to fire when it happens and route to maintenance, scheduling, and analytics simultaneously. One workflow. Measured impact. Studies show event-driven systems responding in milliseconds rather than minutes, reducing manual intervention dramatically and improving process completion rates at scale. Prove it on one line, then expand to the next bottleneck.

The broker is straightforward. The translation layer isn't. Your [MES](https://flowfuse.com/use-cases/mes/) doesn't listen for events. Your [ERP](https://flowfuse.com/blog/2025/06/connect-shop-floor-to-odoo-erp-flowfuse/) expects scheduled queries. Your quality system runs batch jobs. Bridging that gap is where real effort lives.

Brownfield doesn’t require cutover. Legacy runs. New workflows build on events. Each migration reduces polling overhead and creates durable audit trails. Value compounds.

The factories that fail treat this as infrastructure. The ones that succeed pick the highest-cost delay, fix it with events, measure the difference, and move on. Value drives adoption. Not architecture diagrams.

*FlowFuse makes event-driven architecture practical for manufacturing by connecting IT and OT systems through a single platform that supports virtually any protocol, includes a built-in MQTT broker, and provides enterprise-grade deployment and security. [Get started with FlowFuse today](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}*

## Sources & References

- APIPark, *Moving Beyond API Polling to Asynchronous Architectures*<https://apipark.com/technews/TbhGSEzF.html>{rel="&#x22;nofollow&#x22;"}
- DZone, *Webhooks vs. Polling: You’re Better Than This*<https://dzone.com/articles/webhooks-vs-polling-youre-better-than-this-1>{rel="&#x22;nofollow&#x22;"}
- Insane Cyber, *The Real Cost of Industrial Downtime*<https://insanecyber.com/real-cost-industrial-downtime/>{rel="&#x22;nofollow&#x22;"}
- StackSync, *Why Integration Complexity Grows Exponentially*<https://www.stacksync.com/blog/integration-complexity-growth>{rel="&#x22;nofollow&#x22;"}
- Siemens, *The Cost of Downtime in Manufacturing*<https://www.siemens.com/global/en/products/services/industry-operations-services/digital-enterprise-services/manufacturing-operations-management/manufacturing-intelligence/downtime-cost.html>{rel="&#x22;nofollow&#x22;"}
- Rockwell Automation, *The True Cost of Downtime*<https://www.rockwellautomation.com/en-us/company/news/blogs/the-cost-of-downtime.html>{rel="&#x22;nofollow&#x22;"}
- American Society for Quality (ASQ), *Cost of Quality and the 1-10-100 Rule*<https://asq.org/quality-resources/cost-of-quality>{rel="&#x22;nofollow&#x22;"}
- Gartner, *Manufacturing ERP Implementation Timelines*<https://www.gartner.com/en/documents/manufacturing-erp-implementation>{rel="&#x22;nofollow&#x22;"}
- International Journal of Science and Advanced Technology (IJSAT), *Event-Driven Manufacturing Automation Systems*<https://www.ijsat.org/papers/2025/1/2907.pdf>{rel="&#x22;nofollow&#x22;"}


# 5 Places Smart Factories Are Already Using AI

The factory floor wasn't exactly an early adopter of artificial intelligence.

It's a world built around physical processes: tolerances, throughput, shift schedules. The automation that arrived decades ago was powerful but rigid. Machines that did exactly what you programmed them to do, nothing more.

That's changed.

AI is now embedded in manufacturing operations in ways that are easy to miss. Not in the headline-grabbing robots, but in the systems quietly running underneath: predicting failures, catching defects, optimizing energy loads, and compressing deployment timelines.

The question isn't whether AI has reached the factory floor. It has. The question is where it's actually doing useful work.

Here are five answers.

## Predictive Maintenance on CNC Machines

Manufacturers lose $50 billion a year to unplanned downtime. Here's what that actually looks like: a CNC machine goes down at 2am, the part isn't in stock, the order misses its window, and the schedule takes three days to recover.

The problem was never detection. Factories have had sensors for decades. It was interpretation. A temperature spike means nothing without knowing what's normal for that machine, on that material, at that feed rate. Threshold-based alarms can't know that. A model trained on months of operational data from that specific machine can.

Predictive maintenance learns the baseline and watches for drift. Bearing wear shows up as a frequency shift in vibration data. Spindle imbalance leaves a signature in motor current. None of these are visible on the floor, but all of them are readable in the data, 24 to 72 hours before failure.

Harley-Davidson has been running vibration-based predictive maintenance on plant equipment for longer than most manufacturers realize. But you don't need that scale. We built an [AI vibration anomaly detector for industrial motors](https://flowfuse.com/blog/2026/02/motor-anomaly-detector-ai/) using an autoencoder trained on healthy vibration data, running inference directly in Node-RED. The model learns what normal looks like. When that changes, you get a warning with time to act.

That's the shift. Not better alarms, but a system that knows the difference between a machine running hard and a machine running out of time.

## Visual Quality Inspection

Manual inspection has a hard ceiling. Put someone at a line running 200 units a minute for four hours and their defect detection rate drops. That's not a training problem. It's physiology.

Computer vision doesn't have that ceiling. A camera at the inspection station sees every unit, not a sample, at full line speed, catching surface defects, dimensional drift, solder bridges, and weld inconsistencies. In semiconductor fabrication, where a particle smaller than a human hair destroys yield, vision-based inspection isn't an upgrade. It's the only option that makes sense at volume.

BMW's [AIQX platform](https://www.press.bmwgroup.com/global/article/detail/T0449729EN/artificial-intelligence-as-a-quality-booster?language=en){rel="&#x22;nofollow&#x22;"} runs camera and sensor-based AI quality checks across every plant globally. At Spartanburg, it monitors roughly [half a million weld studs daily](https://www.automotivemanufacturingsolutions.com/smart-factory/quality-visions-ai-inspection-systems-that-learns-from-the-line/2623126){rel="&#x22;nofollow&#x22;"}. At Regensburg, the [GenAI4Q system](https://www.press.bmwgroup.com/global/article/detail/T0449729EN/artificial-intelligence-as-a-quality-booster?language=en){rel="&#x22;nofollow&#x22;"} generates a custom inspection checklist for each of 1,400 vehicles built daily, adapting to every model variant in real time.

There's a compounding effect worth noting: every defect caught becomes labeled training data. The model improves continuously. The longer it runs, the harder it is to beat.

Human inspectors still matter for root cause and edge cases. But the first pass, the one that runs on every unit at line speed, is not a job for human eyes anymore.

## Shorter Path from Pilot to Production

Manufacturers consistently underestimate integration time. The technology decisions get made, the use case is clear, and then the project stalls for months. The pilot ran on clean exported data. Production means live data from PLCs running proprietary protocols, historians not designed for real-time access, and network segments that exist for good reasons. Most IIoT initiatives don't fail at the algorithm layer. They fail at the plumbing.

That gap is expensive. A deployment that takes six months to reach production has a very different ROI profile than one that takes six weeks. And it's precisely here that AI is changing the economics of development. Engineers are generating integration flows from plain language descriptions, tracing protocol mismatches that would have previously burned days, and producing documentation as they build rather than long after. The unglamorous middle work moves faster.

[FlowFuse Expert](https://flowfuse.com/docs/user/expert/) is built for exactly this. AI assistance embedded directly in the Node-RED editor: inline code completions as you write, next-node predictions as you build, and a chat interface that understands your actual flows and live debug output. Describe the logic you need and it writes the function node. Something behaving unexpectedly? Load your flow and debug logs as context and work through it together. Fewer hours lost to problems that have already been solved a hundred times before.

## Energy and HVAC Optimization

Most smart factory conversations never get to the building itself. That's a mistake.

HVAC is one of the largest energy costs in a manufacturing facility and one of the least optimized. A factory's thermal load shifts constantly: which lines are running, what materials are being processed, outdoor temperature, occupancy. Rule-based systems deal with that complexity by setting conservative margins everywhere and leaving them there. It works, but you pay for it on every energy bill.

AI learns the actual behavior of the facility and stops defending against conditions that aren't happening. Yokogawa deployed reinforcement learning for HVAC in its semiconductor plant in Japan. In that facility, cleanroom HVAC accounted for roughly [30 percent of total energy consumption](https://www.isa.org/intech-home/2022/october-2022/features/case-study-ai-based-autonomous-control){rel="&#x22;nofollow&#x22;"}, a figure consistent with, though on the lower end of, what's reported across the semiconductor industry. The result was a [3.6 percent reduction](https://my.avnet.com/silica/resources/article/ai-takes-on-growing-role-in-hvac-system-efficiencies/){rel="&#x22;nofollow&#x22;"} in total consumption. Modest on paper, significant at scale, and it improves as the model keeps learning.

[DeepMind's data center work](https://deepmind.google/discover/blog/deepmind-ai-reduces-google-data-centre-cooling-bill-by-40/){rel="&#x22;nofollow&#x22;"} gets more attention, but that's a controlled, single-purpose environment. A factory is harder. Yokogawa is the more relevant proof of concept.

## Worker Safety and Ergonomics Monitoring

Musculoskeletal disorders are the most common workplace injury in manufacturing. A bad lift, an awkward reach, a sustained bent posture on a repetitive task: the injury doesn't happen dramatically. It accumulates over weeks, then shows up as a compensation claim and a gap on the line.

Traditional ergonomics assessment catches this late. A consultant observes a workstation, writes a report, and by the time recommendations are implemented, workers have been loading their joints wrong for months.

Pose-estimation AI runs overhead cameras continuously and scores every movement in real time against established ergonomic risk frameworks, flagging a bend angle that will cause a back injury long before it materializes. In one [manufacturing pilot study](https://rsisinternational.org/journals/ijrsi/articles/ai-powered-ergonomics-enhancing-workplace-safety-through-posture-detection/){rel="&#x22;nofollow&#x22;"}, researchers reported roughly a 25 percent reduction in workplace injuries, with posture compliance improving once workers received real-time feedback. Results will vary by facility, workstation type, and baseline injury rates.

The privacy question deserves a direct answer: these systems track skeletal keypoints, not faces or identities. What gets logged is joint angle data, not footage of individuals.

What makes this different from a safety poster is that it doesn't rely on the worker remembering. The system watches every repetition, on every shift.

## Where to Start

The five use cases covered here aren't experiments. They're running in production facilities today, on real lines, delivering measurable results. The gap between manufacturers who've deployed AI and those still evaluating it is growing, and it compounds.

But starting doesn't require a complete digital transformation. Pick one problem that's costing you money right now: unplanned downtime on a critical machine, a defect rate you can't get below, an energy bill that doesn't reflect how efficiently you actually run. That's your first use case.

The common thread across all five use cases is the same bottleneck: getting operational data to a model reliably and acting on what it returns. That's the integration problem most deployments stall on. FlowFuse is built around solving exactly that. You connect to your PLCs, deploy your AI model, and trigger actions all within the same flow, which is why it's where most manufacturers start and where they keep building.

The manufacturers seeing results didn't wait for the perfect conditions. They started with one line, proved the value, and expanded. That's still the fastest route from where you are to where you want to be.


# The Bus Factor Problem in Integration Systems

The bus factor is a simple idea. If one person leaves your team, how much breaks? If the answer is "a lot," your bus factor is one. Most integration systems have a bus factor of one.

It's not because teams are sloppy. Integration work just tends to accumulate in corners. Systems get built quickly to solve real problems, and the person who builds them naturally becomes the person who understands them. They know why the retry logic is set the way it is, why data gets reshaped at that particular step, why two systems connect the way they do. That knowledge rarely makes it into documentation because there's always something more urgent to work on.

Time passes. The system keeps running. Nobody questions it. Then that person moves to another team, takes a two-week vacation, or just gets sick at the wrong moment, and suddenly a routine maintenance task turns into a two-day investigation.

The problem isn't unique to integration systems, but it hits them harder. Integration logic lives between other systems, it's rarely the focus of code reviews, and it's usually the last thing anyone thinks to document. Knowledge concentrates fast and spreads slowly.

The good news is it's a solvable problem. The first step is knowing you have it. Before you read further, take two minutes to assess where your team stands today.

### Bus Factor Calculator

:iframe{frameBorder="0" height="650px" src="https://bus-factory-problem-dashboard.flowfuse.cloud/dashboard/bus-factory-calculator" width="100%"}

Now you know where you stand. The rest of this article explains how integration systems end up here, why documentation alone never fixes it, and what it actually takes to change it.

## Why Integration Systems Are Especially Vulnerable

Most engineering work leaves a trail. Pull requests, code reviews, commit messages, test cases. Software teams have spent decades building habits and tooling that make their work legible to others. Integration work tends to skip all of that.

A flow gets built by one person to solve a specific problem: connect a PLC to a database, route sensor data to a dashboard, translate one protocol into another. It works, it gets deployed, and then it runs quietly in the background while everyone moves on. The person who built it moves on too, to the next urgent problem, the next system, the next deadline.

!["Illustration of an integration flow acting as a black box between PLCs, databases, and dashboards, highlighting that knowledge about the connections is concentrated in a single person."](https://flowfuse.com/blog/2026/03/images/integration-systems-black-box.png "Illustration of an integration flow acting as a black box between PLCs, databases, and dashboards, highlighting that knowledge about the connections is concentrated in a single person.")

The people doing this work aren't cutting corners. They're IT engineers, automation specialists, OT technicians, and process engineers working under real time pressure. Their job is to get systems talking, not to produce documentation for a future colleague they've never met. In most organizations, nobody has ever defined what good engineering practice looks like for integration work, so the default is to ship and move on.

There's a structural problem compounding this. Integration flows don't belong cleanly to any one team. They're not part of the application codebase. They're not clearly IT's responsibility or OT's. They live in their own runtime, often on edge devices or gateways distributed across a facility, and they connect systems that different teams own. Nobody has obvious ownership, so nobody feels obvious accountability for making the knowledge transferable.

The result is a system that works fine as long as the right person is available. The moment they're not, you find out just how much was living only in their head.

## What Happens When the Knowledge Walks Out the Door

The immediate impact is visible: something breaks and nobody knows how to fix it. But the slower damage is harder to measure.

Teams start treating their own integration flows as black boxes. They're afraid to touch them because they don't understand them well enough to know what will break. New team members spend weeks or months just trying to figure out what exists and what it does. Simple changes take longer than they should because every modification requires archaeology first.

Over time, organizations start building new flows around existing ones instead of modifying them, because modifying them feels risky. The system gets more complex. More people build more flows that only they understand. The bus factor gets worse, not better.

In manufacturing environments, this isn't just a productivity problem. Integration flows connect real machines, real production lines, and real safety systems, whether that's a changeover routine on an [automotive assembly line](https://flowfuse.com/industries/automotive/) or a batch recipe in a chemical plant. A flow that nobody understands is a flow that nobody can safely change, debug, or improve. That's a real operational risk, and it compounds with scale.

## The Documentation Problem

The obvious answer is: write better documentation. And yes, that's true. But saying "just document it" has never actually solved the problem, and it's worth understanding why.

Documentation is a separate task. That's the core issue. When an engineer finishes building a flow, the work feels done. The flow works. Sitting down to document it means context-switching into a different mode of thinking, opening a different tool, and writing for an audience that doesn't exist yet. Most of the time, that just doesn't happen.

Even when documentation does exist, it goes stale. A flow gets modified. The documentation doesn't. Six months later, the documentation describes something that no longer exists, which is sometimes worse than no documentation at all.

The teams that actually maintain good documentation tend to do it because it's built into how they work, not because they decided to be more disciplined. The process makes it easy and the tooling keeps it close to the work.

## How FlowFuse Approaches the Problem

FlowFuse is an industrial data platform built on [Node-RED](https://flowfuse.com/node-red/). It's designed for teams who need to connect machines, systems, and data across IT and OT environments at scale, with the governance and reliability that production environments require.

What makes it relevant to the bus factor problem is where FlowFuse has chosen to put the intelligence.

[FlowFuse Expert](https://flowfuse.com/docs/user/expert/) is an AI assistant built directly into the Node-RED editor inside FlowFuse. It is not a generic AI. It is specifically trained on FlowFuse's own documentation, blog posts, and resources, which means it understands the platform, its nodes, and the industrial context it operates in. When you ask it a question, you are not talking to a general-purpose chatbot - you are talking to something that knows what a Function node is, what an MQTT broker does, and what your specific flow is actually doing.

That last part matters. FlowFuse Expert can take your flow as context. Select a flow, add it to the conversation, and ask plain-language questions about it - what does this flow do, why is this node outputting a number instead of a string, where could this logic fail. It can also take your palette as context, so it knows which nodes you actually have installed and can give advice based on what is available to you rather than what exists in theory.

For a team inheriting flows they didn't build, this changes the equation significantly. Instead of spending days reverse-engineering what a flow does, a new team member can get a working explanation in seconds and ask follow-up questions in plain language.

:lite-youtube{style="width: 100%; aspect-ratio: 16/9; background-image: url('/blog/2026/03/images/ff-expert-explaining-flow.jpeg'); background-size: cover; background-position: center;" title="FlowFuse Expert Explaining Selected Flow" videoid="YRc1DwkghRs"}

The video above shows just one example - asking questions about a selected flow. FlowFuse Expert goes much further than that. You can query your live operational data through MCP tools in Insights mode, get inline code completions as you type inside Function nodes, generate CSS and HTML for FlowFuse Dashboard templates, build Function nodes from plain-language descriptions, and get intelligent suggestions for which node to add next. The more you use it, the less the work depends on any single person remembering how something was built.

Beyond the chat interface, FlowFuse Expert also brings AI directly into Node-RED through Node-RED Embedded AI. This is AI that works where you already are - inside node editors and on the canvas - without needing to open a separate panel. It can write Function node code from a plain-language description, generate CSS and HTML for FlowFuse Dashboard templates, suggest which node to add next in a flow, and produce realistic test data to validate logic. It handles the JavaScript, the regex, the CSS, the JSON - so engineers can focus on the domain knowledge that actually requires a human.

## Reducing the Bus Factor in Practice

FlowFuse Expert is one piece of a broader approach FlowFuse takes to making integration knowledge more durable.

The platform includes version control for flows, so changes are tracked and teams can roll back when something goes wrong without needing to call the person who made the change. It supports team collaboration on a single Node-RED instance, which means flows don't have to be the work of one person in isolation. DevOps pipelines let teams move flows through development, staging, and production environments with proper governance rather than deploying directly to production from someone's laptop.

Put together, these features don't just reduce the bus factor. They change the conditions that create it. When flows are version-controlled, when multiple people work on them together, when an AI can explain them on demand, the concentration of knowledge in one person's head becomes much harder to sustain accidentally.

The bus factor never fully goes away. Key people will always carry important knowledge. But there's a meaningful difference between a team where one person is the only one who understands something, and a team where one person understands it best but the system can explain itself well enough that others can follow, contribute, and take over.

The goal isn't to make everyone interchangeable. It's to make sure that when someone is out, the work can continue.

## Closing Thought

Integration systems are the connective tissue of industrial operations. When they're well understood and well documented, they're an asset. When they're opaque and person-dependent, they're a liability that just hasn't failed yet.

The bus factor problem doesn't go away on its own. Knowledge concentrates by default, distributing it requires the right conditions, the right process, and tooling that makes the good behavior easier than the bad. That's exactly what FlowFuse is built to do.


# Edge vs Cloud AI in Manufacturing: Where Each Actually Belongs

Most industrial AI deployments are built around the wrong question. "Edge or cloud?" treats a deployment decision as a binary choice, when the real question is simpler and more useful: what does this specific workload actually require?

Edge AI offers real-time inference with no network dependency. Cloud AI offers the depth of compute and data that builds models worth deploying in the first place. Both are genuinely necessary. Neither is universally correct. And the architecture that works is almost always a hierarchy of both, not a choice between them.

This piece looks at where each layer performs, where each fails, and how to place workloads correctly across the hierarchy. The goal is not a verdict. It is a framework for making the decision well, every time.

## What Edge AI and Cloud AI Actually Mean on the Plant Floor

Edge AI processes data where it is generated. The model runs locally on a gateway or industrial PC, directly on the factory floor. Data from sensors, cameras, and machines is analyzed on the spot, and the result is immediate.

Cloud AI processes data in a remote data center. Information travels over a network to where the compute lives. The infrastructure scales to meet demand, and the same models can serve every site in an operation.

Both are real approaches to industrial AI, built for different problems and different scales.

## Where Edge AI Works Best

Think about what happens in the seconds after a sensor detects something abnormal on a running line. There is no time to package that data, send it to a remote server, wait for a response, and act. The machine has already moved on.

This is the environment edge AI was built for. Manufacturing lines running at speed, assets in remote locations, facilities where network connectivity is inconsistent or restricted. In these situations, the model needs to live close to the source, processing data as it arrives and producing a result before the next event occurs.

Quality inspection is one of the clearest examples. A vision system identifying surface defects, dimensional errors, or assembly faults on a fast-moving line has a window measured in milliseconds. The same logic applies to condition monitoring on rotating equipment, anomaly detection on process instrumentation, and real-time control adjustments based on live sensor feeds.

Edge AI also matters where data cannot easily leave the facility. Regulatory requirements, network constraints, or simple operational practicality all create situations where keeping data local is not optional. Running the model at the edge removes the dependency entirely.

The use cases are varied but the underlying condition is consistent. When speed, proximity, or data locality is non-negotiable, the architecture decision is straightforward.

## Where Cloud AI Works Best

Edge AI handles the moment. What it cannot handle is everything that happens before that moment becomes possible.

A single facility sees a fraction of the picture. One site running one set of machines accumulates useful data. But an organization running fifty sites, each generating operational data around the clock, is sitting on something far more valuable. The patterns that predict failure, the process conditions that drive quality, the anomalies that precede downtime. These only become visible when data is brought together at scale.

That is the problem cloud AI was built to solve. Not speed, but depth. Not real-time response, but the kind of learning that takes weeks of data, hundreds of assets, and serious compute to produce. A predictive model that has seen ten thousand failure events across a global fleet will always outperform one trained on a single site. The cloud is where that model gets built.

It is also where industrial organizations manage AI at scale. Retraining models as conditions change, pushing updates across distributed deployments, monitoring performance across every site from a single place. Doing that at the edge, independently, across dozens of locations, is not a realistic proposition.

The workloads that belong in the cloud share a common characteristic. They are not time-critical, but they are data-hungry and compute-intensive. And the value they produce, better models, broader visibility, smarter operations, flows back down to the plant floor where it matters.

## The Trade-offs

Every architecture decision in industrial AI comes down to the same five factors. Get them right and the deployment works. Get them wrong and the problems compound quietly until they become expensive.

Latency determines whether cloud is even an option for a given workload. Bandwidth determines what it costs to run it. Data ownership determines what is permissible. Model complexity determines what is technically feasible. And operational overhead determines what the true long-term cost looks like, not just the build cost.

| Factor               | Edge                                     | Cloud                                                              |
| -------------------- | ---------------------------------------- | ------------------------------------------------------------------ |
| Latency              | Real-time, no network dependency         | Adds network round-trip, not suitable for time-critical decisions  |
| Bandwidth            | Data stays local, minimal transfer costs | High volumes must travel, costs and infrastructure scale with data |
| Data Ownership       | Stays on site, no external exposure      | Requires a deliberate strategy on what leaves and where it lives   |
| Model Complexity     | Constrained by local hardware            | No practical ceiling, runs the largest and most complex models     |
| Operational Overhead | Multiplies with every site added         | Centralized but dependent on connectivity and third-party uptime   |

The factors rarely pull in the same direction. A workload that demands low latency often generates high data volumes, making cloud impractical on two counts at once. A model complex enough to require cloud compute may involve data that cannot leave the facility. These tensions are where most architecture decisions get made, and where getting the balance right matters most.

## The Hierarchy and Where Each Workload Belongs

The architecture that resolves the edge-vs-cloud question is a five-level hierarchy, one the manufacturing industry already knows. It maps directly to the ISA-95 functional model that has guided industrial operations for decades.

Each level handles a different class of decisions, at a different speed, with a different scope of data.

- **Level 0–1 (On-Device):** Inference runs directly on the sensor, camera, or actuator. Models are small and fast, operating in microseconds with no network involved.
- **Level 2 (Edge Compute Node):** Pulls data from multiple machines and runs more capable models across a production cell or line. Keeps working during network outages and syncs upstream when connectivity returns. This level is the most commonly skipped in early planning and the most expensive to add later.
- **Level 3 (Plant-Level Server):** Handles facility-wide analytics, MES integration, and the data historian that feeds both local reporting and cloud synchronization.
- **Level 4–5 (Enterprise and Cloud):** Where models are trained, retrained, and managed across every site. Latency is not a concern here. Compute depth is.

![Diagram showing the ISA-95 five-level hierarchy for industrial AI, from on-device inference at Level 0–1 through edge compute, plant-level server, and enterprise cloud at Level 4–5, with data flowing upward for aggregation and model updates flowing downward to the plant floor](https://flowfuse.com/blog/2026/03/images/isa95_flowfuse_final_v4.svg "Diagram showing the ISA-95 five-level hierarchy for industrial AI, from on-device inference at Level 0–1 through edge compute, plant-level server, and enterprise cloud at Level 4–5, with data flowing upward for aggregation and model updates flowing downward to the plant floor")

Data flows up through this hierarchy for aggregation and learning. Model updates, detection thresholds, and configurations flow back down. An architecture that flips this, sending time-sensitive decisions to the cloud while the edge just passes data along, will run into the same problems as a cloud-only deployment, regardless of what it is called.

Placing workloads correctly is where most industrial AI projects go wrong. The starting point is always the decision itself: what is the AI being asked to do, and what happens if the answer is late? Three questions settle most cases:

> What response time is acceptable? Milliseconds point to Level 0–2. Seconds to minutes allow Level 3. Hours or longer can go to the cloud.

> Can the data leave the facility? Regulatory constraints, network limitations, or operational policy may make cloud processing impermissible regardless of latency.

> How much context does the model need? Single-asset inference fits at the edge. Cross-site pattern recognition belongs in the cloud.

In most real deployments, the same asset feeds multiple levels simultaneously: a Level 2 anomaly detection model acting in real time, a Level 3 shift performance report running every few hours, and a Level 4–5 fleet-wide predictive model retrained monthly. These are three different problems running at three different speeds, not one problem waiting for one answer.

## Conclusion

The edge-vs-cloud question has a straightforward answer once the right question is being asked. Not "where should we run our AI?" but "what does this specific workload require, and which level of the hierarchy delivers it?"

Edge and cloud are not competing philosophies. They are complementary layers of a single architecture that the manufacturing industry already understands. What industrial AI adds is the requirement to place intelligence deliberately at each level, not just data collection at the bottom and reporting at the top, but active inference, model management, and continuous learning distributed across the hierarchy in proportion to where the decisions actually happen.

The technology to do this exists. The frameworks are mature, the hardware is proven, and the use cases are well established. What separates deployments that deliver sustained operational value from the ones that stall after the pilot is not the sophistication of the models. It is the clarity of the architecture and the discipline to build it in the right order.

Define the decision. Map it to the hierarchy. Build the infrastructure that decision requires. Then train the model.

That sequence is what industrial AI at scale actually looks like, and [FlowFuse]() is the platform built to run it. From connecting machines and collecting data, to transforming and visualizing it in real time, to running model inference directly in the flow with ONNX nodes, wiring live plant data into AI agents with MCP, and letting operators query their operations in plain language with Expert Insights. One platform. Every level of the hierarchy.


# FlowFuse Enterprise: More Power, More Confidence

Manufacturing teams using FlowFuse are running industrial applications at scale, across plants, teams, and environments. As that scale grows, so do the expectations: faster deployments, tighter security, smarter tooling.

Today we're announcing updates to our Enterprise tier that reflect where our customers are headed and the kind of platform they need to get there.

**FlowFuse Enterprise now includes Certified Nodes and AI Insights.**

## What's new in Enterprise

### Certified Nodes

One of the most consistent questions we hear from IT and security teams evaluating FlowFuse is: "Is FlowFuse secure and compliant enough for production?"

Certified Nodes are our answer. Every node in the catalogue has been security-scanned, battle-tested, and comes with a clear support owner, along with enterprise level response times. That means your team gets the flexibility of the Node-RED ecosystem with the accountability that enterprise production environments demand.

This isn't just a compliance checkbox. It's the foundation for **trusting your infrastructure** with the dependencies, and for IT and Operations to standardize on FlowFuse with confidence across sites.

### AI Insights

Building and iterating on flows takes time, time your team doesn't always have. AI Insights brings AI-assisted solution building directly into FlowFuse, reducing the effort required to go from idea to production.

Whether you're onboarding a new site, adapting an existing flow, or troubleshooting a process, AI Insights helps your team do more with less, and get to value faster.

Our goal is simple: &#x2A;*the first week of value should come faster than ever before.**

## Built around three things that matter at scale

These additions aren't standalone features, they reflect a deliberate focus on the three capabilities manufacturing enterprises need as they move from pilot to production to fleet.

### Operational Scaling

Deploy and manage Node-RED reliably across sites, teams, and environments, without the configuration drift and version inconsistency that comes with growth.

### System Agility

Build, iterate, and adapt faster with AI-assisted tooling. Certified Nodes and AI Insights together mean your team spends less time on asset modeling and more time on outcomes.

### Event-Driven Data Bridge

Connect your systems with operational responsiveness, not just bulk data collection. FlowFuse is built for the workflow-centric, event-driven logic that manufacturing operations actually run on.

## What this means for your team

FlowFuse has always been built on Node-RED, but Enterprise customers need more than a great open-source foundation. They need a platform they can stake production operations on.

Certified Nodes and AI Insights are the next step in making FlowFuse that platform: more accountable, more capable, and faster to value than ever.

**Get started at [flowfuse.com/pricing](https://flowfuse.com/pricing).**


# FlowFuse 2.28: Troubleshoot Faster, Manage Edge Devices Centrally, and More Self-Hosted Flexibility

FlowFuse 2.28 focuses on making your day-to-day work faster and giving you more control, whether you are debugging a flow, managing edge devices, or running FlowFuse on your own infrastructure.

## Troubleshoot Flows Faster with FlowFuse Expert

Tracking down issues in your flows usually means adding debug nodes, reading through log output, and then trying to describe the problem to get help. That back-and-forth slows you down.

### Point Expert at Your Debug Logs

You can now select individual debug log entries and include them as context when asking FlowFuse Expert for help. Combined with your selected flows, Expert sees exactly what you see, the error, the flow that produced it, and the surrounding context.

::lite-youtube
---
params: rel=0
style: "width: 704; height: 100%; background-image:
  url('https://img.youtube.com/vi/e0XV6lMKazo/maxresdefault.jpg');"
title: YouTube video player
videoid: e0XV6lMKazo
---
::

Select specific log entries to give FlowFuse Expert focused troubleshooting context

- **Select individual log entries** to focus Expert on the specific issue rather than everything in your log
- **Quick-add from the Resource Selector** to pull in logs alongside your flows in one step
- **Get targeted answers** because Expert reasons about your actual errors, not a description of them

### Always Have the Latest Expert Capabilities

FlowFuse Expert is getting new capabilities regularly, like the debug log context above. But when you are deep in your flows, it is easy to miss that an update is available. Expert now shows a banner when a newer version is ready. One click and you are up to date, so you always have access to the latest troubleshooting and development features.

![FlowFuse Expert update banner](https://flowfuse.com/blog/2026/03/images/expert-update-banner.png){dataZoomable="" style="border: 2px solid #E5E7EB;"}

Expert lets you know when an update is available

## New Device Agent Configuration Options

FlowFuse 2.28 combined with Device Agent v3.8.1 expands what you can configure on your edge devices, giving you more control over how Node-RED runs on Remote Instances.

### Configure Node.js Runtime Options

The latest Device Agent lets you set Node.js command line arguments for Remote Instances, via your `device.yml` or the agent command line. Previously these options were not configurable at all. The full set of NodeJS (command line arguments) [<https://nodejs.org/docs/latest-v22.x/api/cli.html>{rel=""nofollow""}] can be set. For example

- **Increase memory** for flows that process large datasets (`--max-old-space-size`)

### Set API Payload Limits from the UI

If your Remote Instances handle large file uploads, you may have hit the default API payload size limit. You can now configure the maximum API payload length directly in FlowFuse under **Remote Instance → Settings → Editor**.

## More Flexibility for Self-Hosted Deployments

### Migrate from Ingress Nginx to Traefik

With the [retirement of Ingress Nginx](https://kubernetes.io/blog/2025/06/30/ingress-nginx-retirement/){rel="&#x22;nofollow&#x22;"}, many self-hosted Kubernetes users need to move to a supported ingress controller. To help with this transition, we have prepared a blueprint for migrating from Ingress Nginx to Traefik. The Helm chart now includes the required job resources and RBAC for the migration tool, and we have published a step-by-step [ingress controller migration guide](https://flowfuse.com/docs/install/kubernetes/ingress-controller-migration/) to walk you through the process.

As part of this work, you can now also set a separate ingress class name for Hosted Instances using `forge.projectIngressClassName`, allowing you to run project traffic through a different ingress controller than the platform itself.

### Additional self-hosted improvements

- **Team NPM Registry**, Docker Compose deployments can now have all the Team Library, Custom Nodes pre-requisits configured.
- **File-server PVC configuration**: Set the size, access modes, and storage class for file-server persistent volumes
- **Private CA certificate mounting**, Docker Compose deployments can now mount a private CA certificate file into the forge service

## What else is new?

- Instances can now automatically receive scheduled maintenance, so they stay up to date without manual configuration.
- Updated FlowFuse Expert documentation with dedicated guides for the Chat Interface and AI-assisted features in Node-RED

For detailed breakdowns of each feature with additional visuals, visit our [changelog](https://flowfuse.com/changelog/). For the complete list of everything included in FlowFuse 2.28, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases){rel="&#x22;nofollow&#x22;"}.

If something in this release improves your workflow, or if there is still friction we can remove, please [share feedback or report issues regarding this release](mailto\:contact@flowfuse.com?subject=Feedback%20on%202.28) to us.

## Try FlowFuse

### FlowFuse Cloud

The fastest way to get started is with FlowFuse Cloud.
[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in minutes.

### Self-Hosted

Run FlowFuse locally using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# How to Connect to Beckhoff TwinCAT PLC Using ADS (2026)

ADS is the protocol TwinCAT uses internally, between its own runtime, its HMI, and its PLC and NC tasks, and Beckhoff exposes it for external tools too. That means connecting to a TwinCAT PLC over ADS gives you direct read and write access to its variables, no additional licensing or middleware required, over the same channel TwinCAT already relies on.

The challenge is usually not the tooling. It is the routing layer. AMS Net IDs, route tables, firewall rules. Get any of those wrong and ADS fails without telling you why. This guide covers the routing first, before touching a single FlowFuse node, because that is where most people get stuck.

By the end you will have live TwinCAT variables flowing into [FlowFuse](https://flowfuse.com).

## Prerequisites

Before you begin, make sure you have the following in place:

- TwinCAT 3.1 runtime running on a Beckhoff IPC
- FlowFuse running on an edge device with network access to the TwinCAT machine. If you don't have an account yet, [sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} to get started, then [follow this guide to quickly run a FlowFuse instance on your edge device](https://flowfuse.com/blog/2025/09/installing-node-red/).
- Both devices on the same network
- Port 48898 open between the two devices
- [Symbol creation](https://flowfuse.com/#enable-symbol-creation) enabled on PlcTask so variables are accessible by name over ADS
- PLC logged in and deployed on port 851
- PLC in Run mode, the TwinCAT system tray icon must be green
- Symbol paths of the variables you want to read or write, available from whoever wrote the PLC program

> If you don't have a real PLC available and want to follow along with a test setup, see
> [Setting Up a Test PLC](https://flowfuse.com/#setting-up-a-test-plc) at the end of this guide before continuing.

## What is ADS and Why It Matters

Every TwinCAT device has an AMS Net ID. It looks like an IP address with two extra octets: `10.68.82.232.1.1`. The first four typically match the device IP, the last two are almost always `1.1` by convention. This is how the ADS router identifies devices on the network, and it is what you will configure in every connection you make from FlowFuse.

Within a device, different TwinCAT components are reachable on different ADS ports. The PLC runtime listens on port `851` by default. If your machine runs multiple PLC tasks, each task gets its own port: the first task is `851`, the second is `852`, and so on. Check with the controls engineer which port corresponds to the task containing your variables.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

## Configuring ADS Routes

TwinCAT will not accept an ADS connection from an unknown host. Every external device that needs to connect must be explicitly trusted in TwinCAT's route table. This is stored in a file called `StaticRoutes.xml` on the TwinCAT machine.

TwinCAT provides a route manager in the system tray under **Router > Edit Routes**. However it does not expose the Flags setting, which defaults to `64` and will silently block connections from non-Windows devices such as Linux or Mac based edge devices. Editing `StaticRoutes.xml` directly is the only way to set Flags to `0`, which allows connections from any trusted device on your network.

Before adding the route you need two pieces of information:

- The IP address of your FlowFuse edge device
- The AMS Net ID you will assign to it, which is the IP address with `.1.1` appended

For example if your FlowFuse device IP is `10.68.82.101`, its AMS Net ID is `10.68.82.101.1.1`.

> **Important:** Your FlowFuse edge device must be on the same network as the interface TwinCAT's AMS Net ID is bound to. TwinCAT binds its AMS Net ID to a specific network interface on startup. If your machine has multiple network interfaces, confirm which IP the AMS Net ID uses, you can find it by right clicking the TwinCAT tray icon and selecting **About TwinCAT System**. Your FlowFuse device must be reachable on that same network, otherwise the ADS handshake will fail even if port 48898 is open.

**Edit StaticRoutes.xml:**

> If you do not have direct access to the TwinCAT machine, ask the controls engineer or machine builder to make this change. Share this section with them so they know exactly what needs to be set, particularly the `Flags` value of `0`.

> **Warning:** The PowerShell command below overwrites the entire `StaticRoutes.xml` file. If the TwinCAT machine already has existing routes configured, back up the file before running this command or add your route entry manually inside the existing `<RemoteConnections>` block instead.

1. On the TwinCAT machine open PowerShell as administrator
2. Run the following command, replacing `YOUR_EDGE_DEVICE_IP` with the actual IP of your FlowFuse device:

```powershell
$xml = @"
<?xml version="1.0"?>
<TcConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <RemoteConnections>
    <Route>
      <Name>flowfuse-edge</Name>
      <Address>YOUR_EDGE_DEVICE_IP</Address>
      <NetId>YOUR_EDGE_DEVICE_IP.1.1</NetId>
      <Type>TCP_IP</Type>
      <Flags>0</Flags>
    </Route>
  </RemoteConnections>
</TcConfig>
"@
$xml | Set-Content "C:\Program Files (x86)\Beckhoff\TwinCAT\3.1\Target\StaticRoutes.xml"
```

> Note: In this example, TwinCAT 3.1 is installed. If you are using a different version, replace 3.1 with the version installed on your system. The installation path may also vary depending on your TwinCAT setup.

3. Restart the TwinCAT router from the system tray by right clicking the TwinCAT icon and selecting **Router > Restart**.
4. Open the Windows Firewall and confirm that port 48898 is allowed for inbound TCP connections.

After the router restarts, verify that port 48898 is reachable from your FlowFuse edge device by running `nc -zv <twincat-ip> 48898`. If the connection is refused, confirm the firewall rule was saved and that both devices are on the same subnet.

## Installing node-red-contrib-ads-client in FlowFuse

1. In your FlowFuse instance open the Node-RED editor
2. Click the hamburger menu in the top right and select **Manage Palette**
3. Go to the **Install** tab
4. Search for `node-red-contrib-ads-client`
5. Click **Install** and wait for it to complete
6. Click **Close**

Once the installation is complete, a few nodes will appear in the right-hand palette under the TwinCAT ADS category.

![TwinCAT ADS nodes available in the Node-RED palette after installing node-red-contrib-ads-client](https://flowfuse.com/blog/2026/03/images/twincat-ads-nodes.png)

## Connecting to TwinCAT

**Add the connection node:**

1. In Node-RED drag an **ADS – Connection Status** node onto the canvas
2. Double click it to open the configuration
3. Next to the **Connection*&#x2A; field click &#x2A;*+** to create a new connection
4. In the **Required Settings** tab fill in the Target AMS Net ID and Target ADS Port:

| Field             | Value                                                       |
| ----------------- | ----------------------------------------------------------- |
| Target AMS Net ID | AMS Net ID of your TwinCAT machine, e.g. `10.68.82.232.1.1` |
| Target ADS Port   | `851`                                                       |

![Required settings tab showing Target AMS Net ID and Target ADS Port fields in the ADS connection configuration](https://flowfuse.com/blog/2026/03/images/Twincat-config-required-fields.png)

5. Switch to the **Optional Settings** tab and fill in the network settings:

| Field            | Value                                                            |
| ---------------- | ---------------------------------------------------------------- |
| Router Address   | IP address of your TwinCAT machine, e.g. `10.68.82.232`          |
| Router TCP Port  | `48898`                                                          |
| Local AMS Net ID | AMS Net ID of your FlowFuse edge device, e.g. `10.68.82.101.1.1` |
| Local ADS Port   | `32750`                                                          |

![Optional settings tab showing Router Address, Router TCP Port, Local AMS Net ID and Local ADS Port fields](https://flowfuse.com/blog/2026/03/images/twincat-config-optional-tab.png)

The **Local AMS Net ID** must match the route configured in `StaticRoutes.xml`. **Local ADS Port** normally does not need to be changed.

> **Note:** If your TwinCAT system is in config mode or the PLC runtime takes time to initialize on startup, enable **Allow Half Open** in the connection settings. Without it the client performs a strict system state check on connect and will fail with ADS error 7 even if the router is reachable. With it enabled the client connects regardless and waits for the runtime to become ready.

6. Click **Add** to save the connection configuration
7. Click **Done**
8. Click **Deploy**

Within a few seconds the connection status node should show **connected**, indicating that FlowFuse successfully established an ADS session with the TwinCAT runtime.

![ADS connection status node showing connected state in Node-RED](https://flowfuse.com/blog/2026/03/images/connection-status.png)

## Reading PLC Variables

With the connection working, reading a variable takes three nodes: an inject node to trigger the read, a read value node to fetch the value, and a debug node to see the output.

1. Drag an **inject** node onto the canvas
2. Double click it and leave the default settings so it triggers manually
3. Click **Done**
4. Drag an **ADS - Read Value** node onto the canvas
5. Double click it to configure
6. Select your TwinCAT connection from the **Connection** dropdown
7. Set the **Variable name** to the full symbol path of the variable you want to read. Symbol paths are always in the format `ProgramName.VariableName`. If you are following along with the test PLC, use `MAIN.temperature`. If you are connecting to a real PLC, use the symbol paths provided by the controls engineer.

![ADS Read Value node configuration showing variable name set to MAIN.temperature](https://flowfuse.com/blog/2026/03/images/ads-read-value.png)

8. Click **Done**
9. Drag a **debug** node onto the canvas
10. Connect the inject node output to the read value node input
11. Connect the read value node output to the debug node input
12. Click **Deploy**

Click the inject button. You should see the variable value appear in the debug panel.

:lite-youtube{style="width: 100%; aspect-ratio: 16/9; background-image: url('/blog/2026/03/images/ads-read.png'); background-size: cover; background-position: center;" title="Reading TwinCAT PLC Variables with FlowFuse" videoid="wTRmgIyWLyk"}

## Subscribing to Variable Changes

Polling on a fixed timer works but is inefficient. For live data the better approach is to subscribe to variable changes. TwinCAT sends a new value to FlowFuse only when the value actually changes, which reduces unnecessary network traffic and gives you lower latency updates.

1. Drag an **ADS - Subscribe Value** node onto the canvas
2. Double click it to configure
3. Select your TwinCAT connection from the **Connection** dropdown
4. Set the **Variable name** to the full symbol path of the variable you want to monitor. If you are following along with the test PLC, use `MAIN.motorRunning`, it toggles roughly once per second so you will see true and false values arriving in the debug panel without being overwhelmed.
5. Set the **Subscription mode** to **On Change**. This tells the TwinCAT runtime to notify FlowFuse only when the variable value has actually changed, rather than pushing the value on every cycle regardless of whether it changed. If you need a value delivered at a fixed interval even when unchanged, use **Cyclic** instead.
6. Set the **Cycle time** to `100` milliseconds. This is how frequently TwinCAT checks for changes on its side.

![ADS Subscribe Value node configuration showing variable name, subscription mode set to On Change, and cycle time set to 100ms](https://flowfuse.com/blog/2026/03/images/ads-subscribe.png)

7. Click **Done**
8. Connect its output to a debug node
9. Click **Deploy**

The debug node will now receive a message every time the variable value changes in the PLC, with no polling required from FlowFuse.

:lite-youtube{style="width: 100%; aspect-ratio: 16/9; background-image: url('/blog/2026/03/images/ads-subscribe-image.png'); background-size: cover; background-position: center;" title="Subscribing to TwinCAT PLC Variable Changes with FlowFuse" videoid="JYrzRXCHb9Q"}

## Writing to PLC Variables

Writing back to the PLC closes the loop. This is useful for sending setpoints, commands, or reset signals from FlowFuse back to TwinCAT.

1. Drag an **ADS - Write Value** node onto the canvas
2. Double click it to configure
3. Select your TwinCAT connection
4. Set the **Variable name** to the full symbol path of the variable you want to write to. If you are following along with the test PLC, use `MAIN.setpoint`.
5. Leave &#x2A;*Automatically fill missing properties (autoFill)** unchecked. This setting only applies when writing complex types such as structs or function blocks, it reads the current value from the PLC first and merges your changes on top so unspecified fields are not zeroed out. For a simple variable like `MAIN.setpoint` it has no effect.

![ADS Write Value node configuration showing variable name set to MAIN.setpoint with autoFill unchecked](https://flowfuse.com/blog/2026/03/images/ads-write.png)

6. Click **Done**
7. Drag an **inject** node onto the canvas
8. Double click it and set the payload type to match the type of your PLC variable. The payload type must match what the PLC expects, a **Number** for INT or REAL, a **boolean** for BOOL, a **string** for STRING, and so on. If you are following along with the test PLC, `setpoint` is declared as INT so set the payload type to **Number**.
9. Click **Done**
10. Connect the inject node output to the write node input
11. Click **Deploy**
12. Click the inject button to trigger the write

To verify the write worked, add a read value node for the same variable and check that the value updated in the debug panel.

:lite-youtube{style="width: 100%; aspect-ratio: 16/9; background-image: url('/blog/2026/03/images/ads-write-image.png'); background-size: cover; background-position: center;" title="Writing to TwinCAT PLC Variables with FlowFuse" videoid="f0GtEp6OA_M"}

## Troubleshooting

- **Connection fails silently with no error**
  The FlowFuse device IP is not in `StaticRoutes.xml` or `Flags` is set to `64` instead of `0`. Edit the file using the PowerShell command in the routing section, then restart the TwinCAT router.
- **ADS error 7: Target machine not found**
  The most common cause is that your FlowFuse device and the TwinCAT machine are not on the same network as the interface TwinCAT's AMS Net ID is bound to. Check the AMS Net ID in **About TwinCAT System** on the TwinCAT machine and confirm your FlowFuse device has an IP on that same subnet. Also confirm the FlowFuse device IP is in `StaticRoutes.xml` with `Flags` set to `0`, and that the router was restarted after any changes. If the PLC runtime takes time to initialize on startup, enable **Allow Half Open** in the connection node.
- **Error: Connection to 127.0.0.1:48898 failed**
  The Router Address field in the connection node is empty or incorrect. Open the connection node, set the Router Address to the TwinCAT machine IP, and redeploy.
- **Error 1808: Symbol not found**
  The variable name is wrong or does not exist in the PLC program. Double check the full symbol path including the program name prefix, for example `MAIN.temperature`. If you are using the test PLC, make sure symbol creation is enabled in PlcTask and the PLC is in Run mode.
- **Error 1804: Failed to get fingerprint**
  The FlowFuse device IP is missing from `StaticRoutes.xml` or the TwinCAT router was not restarted after editing the file.
- **Port 48898 not reachable**
  Port 48898 is blocked on the TwinCAT machine firewall or the two devices are not on the same network. Confirm the firewall rule is in place and test reachability with `nc -zv <twincat-ip> 48898` from your FlowFuse device.
- **PLC variables not updating**
  The PLC is not in Run mode. The TwinCAT system tray icon must be green. A blue icon means the runtime is stopped, right click the tray icon and select &#x2A;*Restart TwinCAT (Run Mode)**.

## Setting Up a Test PLC

For readers without a real TwinCAT PLC available: this sets up a minimal test environment to follow along with. Skip this section if you already have a PLC running.

### What You Need

- A Windows machine or laptop
- TwinCAT XAE Shell installed. Download it from the [Beckhoff website](https://www.beckhoff.com){rel="&#x22;nofollow&#x22;"}

> **Important:** If your Windows machine has Hyper-V enabled, TwinCAT will not run in KM mode and the system tray icon will stay blue instead of turning green. Make sure Hyper-V is disabled before proceeding. You may need to restart the machine after disabling it.

### Create the Project

1. Open TwinCAT XAE Shell
2. Click **File > New > Project**
3. Select **TwinCAT Projects** then **TwinCAT XAE Project**
4. Give the project a name, for example `AdsDemo`, and click **OK**

### Add a PLC Project

5. In Solution Explorer right click the project name and select **Add New Item**
6. Select **Standard PLC Project**, give it a name, and click **Add**

### Write the PLC Program

7. In Solution Explorer expand **PLC > your project > POUs** and double click **MAIN**
8. In the declaration section (top panel) replace the existing content with:

```text
PROGRAM MAIN
VAR
    temperature : REAL := 23.5;
    motorRunning : BOOL := FALSE;
    setpoint : INT := 100;
    cycleCount : INT := 0;
END_VAR
```

9. In the program body (bottom panel) add:

```text
temperature := temperature + 0.1;
IF temperature > 100.0 THEN
    temperature := 0.0;
END_IF

cycleCount := cycleCount + 1;
IF cycleCount >= 1000 THEN
    motorRunning := NOT motorRunning;
    cycleCount := 0;
END_IF
```

This gives you three live variables to work with. `temperature` increments continuously every PLC cycle, `motorRunning` toggles roughly once per second, and `setpoint` stays static until you write to it from FlowFuse.

### Enable Symbol Creation

Symbol creation must be enabled for ADS to access variables by name. Without this step the ADS client will connect successfully but fail to find any variables.

10. In Solution Explorer expand the project, then under **Task** double click **PlcTask**
11. Check **Create symbols** in the properties window that opens
12. Click **OK**

![PlcTask properties window showing the Create symbols checkbox enabled](https://flowfuse.com/blog/2026/03/images/create-symbol.png)

### Build and Activate

13. Press **Ctrl+Shift+B** to build the project. Check the output window for any errors before continuing.
14. Right click the PLC instance in Solution Explorer and select **Login**

> **Note:** If Login is not visible in the right click menu, find it in the top menu bar under **PLC > Login**.

15. When TwinCAT prompts you to create the application on port 851, click **Yes**. Do not skip this step or change the port.
16. Press **F5** to start the PLC

The TwinCAT system tray icon must be green before you proceed. A blue icon means the runtime is not running and ADS connections will fail.

Your test PLC is now running. Go back to the [Configuring ADS Routes](https://flowfuse.com/#configuring-ads-routes) section and continue from there. The variable paths you will use throughout this guide are `MAIN.temperature`, `MAIN.motorRunning`, and `MAIN.setpoint`.

## Conclusion

You now have a working ADS connection between FlowFuse and TwinCAT: reading variables on demand, subscribing to live changes, and writing values back to the PLC. The `node-red-contrib-ads-client` package includes several other nodes worth exploring on your own.

From here, build real-time dashboards on live PLC data, connect TwinCAT to databases, ERP, or cloud platforms, set up alerts when variables go out of range, and give your team operator interfaces they can reach from anywhere, all on the connection you just configured, without custom integration code.

Beckhoff TwinCAT ADS is one of many PLCs FlowFuse connects to the modern industrial stack. For Siemens, Allen-Bradley, Omron, Modbus, OPC UA, and more, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).


# How to Stop Silent Pipeline Failures From Swallowing Your IIoT Data

Somewhere in your IIoT pipeline, a message just failed. You don't know which one. You don't know when. And unless you have a Dead Letter Queue, you never will.

In industrial environments, failure is not the exception. It is the contract. Networks partition. APIs rate-limit. A sensor alert fires at the wrong moment and vanishes without a trace. And unlike consumer applications, missed messages in manufacturing have a real cost.

That cost is invisible by default. No error surface. No audit trail. Just data that was there and then wasn't. FlowFuse changes that. It gives your IIoT pipelines the production-grade tooling they need to handle failure the right way: catch it, retry it, and preserve everything that couldn't be recovered so you can act on it later.

This guide shows you how to build exactly that. You will walk away with a production-ready pattern for catching failed messages, retrying them with exponential backoff, and routing the unrecoverable ones into a Dead Letter Queue where they can be inspected, replayed, or discarded on your terms.

## What Is a Dead Letter Queue?

A Dead Letter Queue is a holding area for messages that could not be delivered. When a message fails processing and has no path forward, it gets routed to the DLQ instead of being dropped or causing your flow to crash.

A message ends up in a DLQ for four reasons. It exceeded the maximum number of retry attempts. It is malformed and cannot be parsed. The target system is permanently unavailable. Or a business rule explicitly rejected it.

The value of a DLQ is not just storage. It is observability. Every failed message arrives with its full payload, error reason, retry history, and timestamps intact. You know exactly what failed, when it failed, and how many times it was attempted before giving up. That information is what makes recovery possible.

Without a DLQ, failed messages disappear silently. With one, failure becomes something you can inspect, act on, and fix.

## The Retry Pattern: Exponential Backoff

Before a message earns its place in the DLQ, you should try, and try again. But naive retries are dangerous. Hammering a failing service every 100ms does not give it time to recover. It makes things worse for everyone.

The industry standard is **exponential backoff with jitter**:

```text
delay = min(base * 2^attempt, max_delay) + random_jitter
```

| Attempt | Base Delay | With Jitter (approx.) |
| ------- | ---------- | --------------------- |
| 1       | 1s         | 1.2s                  |
| 2       | 2s         | 2.5s                  |
| 3       | 4s         | 4.1s                  |
| 4       | 8s         | 8.9s                  |
| 5       |            | → DLQ                 |

The jitter prevents the **thundering herd problem**, where every failed client retries at exactly the same moment and overloads the service all over again.

## Building It

In this section, we'll build this pattern in FlowFuse step by step.

FlowFuse is the Industrial Application Platform that connects any machine or system, collects data across any protocol, and lets you act on it at production scale, with enterprise features like role-based access control, centralized device management, audit logging, and team collaboration built in. It also includes FlowFuse Tables, a built-in database service that gives all your instances a single shared DLQ, so every failed message across your entire fleet lands in one place, visible and queryable from anywhere. [Contact us](https://flowfuse.com/contact-us/) to get started.

The architecture has five components:

1. Retry state initializer
2. Catch node for centralized error handling
3. Retry manager with exponential backoff
4. Delay node for controlled retries
5. Dead Letter Queue backed by FlowFuse Tables

Here's how they connect:

```mermaid
flowchart TD
    A[Input] --> B[Process]
    B --> C[Success Handler]
    B -->|on error| D[Retry Manager]
    D -->|within max retries| E[Delay]
    E --> B
    D -->|max retries exceeded| F[Dead Letter Queue]
    linkStyle default stroke:#4F46E5,stroke-width:2px
    style A fill:#ffffff,color:#4B5563,stroke:#4F46E5
    style B fill:#ffffff,color:#4B5563,stroke:#4F46E5
    style C fill:#ffffff,color:#4B5563,stroke:#4F46E5
    style D fill:#ffffff,color:#4B5563,stroke:#4F46E5
    style E fill:#ffffff,color:#4B5563,stroke:#4F46E5
    style F fill:#ffffff,color:#4B5563,stroke:#4F46E5
```

Every step below maps directly to one part of that diagram. Follow it in order.

### Step 1: Initialize Retry State

This function node runs once when a fresh message enters the pipeline. It attaches retry metadata to `msg` so every downstream node knows where the message stands.

1. Drag a **function node** onto the canvas.
2. Double-click it to open its settings.
3. In the **Name** field, enter `Init Retry State`.
4. In the **Function** tab, paste the following code:

```javascript
msg._originalPayload = RED.util.cloneMessage(msg.payload);

if (!msg._retry) {
    msg._retry = {
        attempts: 0,
        maxAttempts: 5,
        lastError: null,
        originalTimestamp: new Date().toISOString(),
        topic: msg.topic
    };
}

return msg;
```

5. Click **Done**.

Two things are happening here worth noting. First, `msg._originalPayload` saves a deep clone of the original payload using `RED.util.cloneMessage` before anything touches it. A plain assignment (`= msg.payload`) would only copy a reference. If a downstream node mutates the object in place, the saved copy changes too. `cloneMessage` ensures the DLQ always holds the payload exactly as it arrived. Some nodes, like the HTTP Request node, also overwrite `msg.payload` with their response body, so this clone is what gets stored in the DLQ later. Second, the `if (!msg._retry)` check ensures initialization only runs on a fresh message. When the retry loop sends the message back through, this block is skipped entirely and the existing retry state is preserved. The underscore prefix on `msg._retry` also protects it from being overwritten by processing nodes.

### Step 2: Add a Catch Node

The catch node monitors your processing nodes and intercepts any message that causes an error, routing it to the retry logic instead of letting it disappear.

Scoping it to `All nodes` is tempting but dangerous. If any node in the retry infrastructure itself throws, for example the Retry Manager calling `node.error()`, the catch node will intercept it and feed it back into the retry loop, creating an infinite loop. Scoping it explicitly to your processing nodes prevents this.

1. Drag a **catch node** onto the canvas.
2. Double-click it to open its settings.
3. In the **Name** field, enter `Catch Errors`.
4. Set **Catch errors from** to `Selected nodes`.
5. Select only the nodes where real failures can occur. In practice, these are the nodes that talk to the outside world: MQTT nodes, HTTP request nodes, database nodes, WebSocket nodes, or anything that reaches beyond the flow itself. Taking the example flow provided at the end of this guide, that means selecting the HTTP Request node and the Check Response function node.
6. Click **Done**.

Next, add a normalization step between the catch node and the retry manager. Built-in nodes sometimes attach `msg.error` as an object rather than a string, which causes problems downstream. This function node converts it to a consistent string format.

1. Drag a **function node** onto the canvas.
2. Double-click it to open its settings.
3. In the **Name** field, enter `Normalize Error`.
4. In the **Function** tab, paste:

```javascript
msg.retry = msg._retry;

if (typeof msg.error === 'object') {
    msg.error = msg.error.message || JSON.stringify(msg.error);
}

msg.error = msg.error || 'Processing failed';
return msg;
```

5. Click **Done**.
6. Wire the **catch node** output to the **Normalize Error** input.

### Step 3: Add the Retry Manager

This is the decision node. It increments the attempt count, calculates the backoff delay, and routes the message either back into the pipeline for another try or forward to the DLQ if retries are exhausted.

1. Drag a **function node** onto the canvas.
2. Double-click it to open its settings.
3. In the **Name** field, enter `Retry Manager`.
4. Go to the **Setup** tab and set **Outputs** to `2`. This gives the node two output ports, one for retrying and one for the DLQ.
5. Go to the **Function** tab and paste:

```javascript
const MAX_ATTEMPTS = msg.retry.maxAttempts || 5;
const BASE_DELAY_MS = 1000;
const MAX_DELAY_MS = 30000;

msg.retry.attempts += 1;
msg.retry.lastError = msg.error || 'Unknown error';
msg.retry.lastAttemptAt = new Date().toISOString();

// keep _retry in sync
msg._retry = msg.retry;

if (msg.retry.attempts >= MAX_ATTEMPTS) {
    msg.retry.exhausted = true;
    msg.dlq = {
        reason: 'Max retries exceeded',
        attempts: msg.retry.attempts,
        lastError: msg.retry.lastError,
        deadAt: new Date().toISOString()
    };
    return [null, msg];
}

const exponential = BASE_DELAY_MS * Math.pow(2, msg.retry.attempts - 1);
const jitter = Math.random() * 1000;
const delay = Math.min(exponential + jitter, MAX_DELAY_MS);

msg.delay = Math.round(delay);

node.status({
    fill: 'yellow',
    shape: 'ring',
    text: `Retry ${msg.retry.attempts}/${MAX_ATTEMPTS} in ${Math.round(delay / 1000)}s`
});

return [msg, null];
```

6. Click **Done**.
7. Wire the **Normalize Error** output to the **Retry Manager** input.

`return [msg, null]` sends the message out of **Output 1** (retry path). `return [null, msg]` sends it out of **Output 2** (DLQ path). No switch node is needed. The routing is built into the return statement.

### Step 4: Add the Delay Node

The delay node holds the message for the calculated backoff period before it re-enters the pipeline. Without this, retries fire instantly and you are hammering an already-struggling service.

1. Drag a **delay node** onto the canvas.
2. Double-click it to open its settings.
3. In the **Name** field, enter `Backoff Delay`.
4. Set **Action** to `Delay each message`.
5. Set **For** to `Override delay with msg.delay`. This tells the node to use the backoff value the Retry Manager calculated rather than a fixed duration.
6. Click **Done**.
7. Wire **Retry Manager Output 1** to **Backoff Delay** input.

Each pass through the loop, the delay gets longer. Roughly 1 second on the first retry, 2 seconds on the second, 4 on the third, and so on. When the Retry Manager decides retries are exhausted, it stops sending to Output 1 entirely and routes to Output 2 instead, ending the loop.

Wire **Backoff Delay** output to your processing node input. This completes the retry loop.

### Step 5: Set Up the DLQ Handler

When a message reaches this stage, retries are finished. The goal now is to preserve everything: the original payload, the error reason, how many attempts were made, and the timestamp. That context is what makes later recovery possible. Without a persistent store, that context disappears the moment the flow restarts, the device reboots, or the pipeline moves on to the next message. And in a multi-instance deployment, you need a store that is accessible across every instance in your fleet, not just the device the failure happened on.

[FlowFuse Tables](https://flowfuse.com/blog/2025/08/getting-started-with-flowfuse-tables/) gives you exactly that: a managed PostgreSQL database that connects directly to your flows with no credentials to configure and no external infrastructure to manage, making it the right storage layer for a production DLQ.

> **Note:** FlowFuse Tables requires an Enterprise plan.

#### 5a: Create the DLQ Table

1. In FlowFuse, go to **Team Settings** and [enable the Tables feature](https://flowfuse.com/blog/2025/08/getting-started-with-flowfuse-tables/#step-1-enable-the-database-in-your-project) for your team.
2. Once enabled, drag a **Query node** from the FlowFuse category onto the canvas.
3. The Query node is pre-configured to connect to your FlowFuse-managed database automatically. No credentials needed.
4. Paste the following into the Query field:

```sql
CREATE TABLE IF NOT EXISTS "dlq" (
  "id" TEXT PRIMARY KEY,
  "topic" TEXT,
  "payload" TEXT,
  "attempts" INTEGER,
  "last_error" TEXT,
  "captured_at" TEXT
)
```

5. Connect an **Inject node** set to run once on deploy to the Query node input.
6. Click **Done** and deploy.

> **Tip:** If you prefer, you can also create the table directly from the **Tables** section in the FlowFuse navigation without writing any SQL.

#### 5b: Build the Insert Flow

1. Drag a **change node** onto the canvas and name it `Build DLQ Params`.
2. Add the following rules:

| Action | Target                            | Value type | Value                       |
| ------ | --------------------------------- | ---------- | --------------------------- |
| Set    | `msg.queryParameters`             | JSON       | `{}`                        |
| Set    | `msg.queryParameters.id`          | msg        | `_msgid`                    |
| Set    | `msg.queryParameters.topic`       | msg        | `retry.topic`               |
| Set    | `msg.queryParameters.payload`     | JSONata    | `$string(_originalPayload)` |
| Set    | `msg.queryParameters.attempts`    | msg        | `retry.attempts`            |
| Set    | `msg.queryParameters.last_error`  | msg        | `retry.lastError`           |
| Set    | `msg.queryParameters.captured_at` | JSONata    | `$now()`                    |

3. Drag a **Query node** from the FlowFuse category onto the canvas and name it `Insert DLQ Record`.
4. Paste the following SQL:

```sql
INSERT INTO "dlq" ("id", "topic", "payload", "attempts", "last_error", "captured_at")
VALUES ($id, $topic, $payload, $attempts, $last_error, $captured_at)
ON CONFLICT ("id") DO UPDATE SET
  "attempts" = EXCLUDED."attempts",
  "last_error" = EXCLUDED."last_error",
  "captured_at" = EXCLUDED."captured_at"
```

5. Wire **Retry Manager Output 2** to **Build DLQ Params**, then **Build DLQ Params** to **Insert DLQ Record**.

`ON CONFLICT DO UPDATE` ensures a message that appears multiple times does not create duplicate rows. It updates cleanly on the same `id`.

## Putting It All Together: Simulation

The best way to understand the pattern is to watch it work. This simulation models a temperature sensor publishing readings to an HTTP API every 5 seconds. The mock API is deliberately configured to fail 80% of the time so you can watch the full cycle in action: messages attempting delivery, retrying with increasing delays, and after 5 failed attempts landing permanently in FlowFuse Tables.

Import the flow below directly into FlowFuse. It contains everything: the sensor data simulator, the mock API, the retry logic, the DLQ handler, and a query button to inspect what landed in the database.

> **Note:** In the simulation, the retry state initialization from Step 1 is folded directly into the **Simulate Reading** function node rather than existing as a separate node. In a real deployment you would keep them separate as described in the tutorial.

::render-flow{:height='300'}
```json
[{"id":"3f70e1b09c698a8b","type":"group","z":"b413f96e006352db","name":"Create Table","style":{"label":true},"nodes":["676f468a5eacf480","f24fcdcd3c682474"],"x":174,"y":239,"w":572,"h":82},{"id":"676f468a5eacf480","type":"inject","z":"b413f96e006352db","g":"3f70e1b09c698a8b","name":"Create Table on Deploy","props":[],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":330,"y":280,"wires":[["f24fcdcd3c682474"]]},{"id":"f24fcdcd3c682474","type":"tables-query","z":"b413f96e006352db","g":"3f70e1b09c698a8b","name":"Create DLQ Table","query":"CREATE TABLE IF NOT EXISTS \"dlq\" (\n  \"id\" TEXT PRIMARY KEY,\n  \"topic\" TEXT,\n  \"payload\" TEXT,\n  \"attempts\" INTEGER,\n  \"last_error\" TEXT,\n  \"captured_at\" TEXT\n)","split":false,"rowsPerMsg":1,"x":630,"y":280,"wires":[[]]},{"id":"1ed8538c313cd812","type":"group","z":"b413f96e006352db","name":"Query DLQ Records","style":{"label":true},"nodes":["98bd5b23672993a1","281734e9a00b621e","ad2553f403d14b2f"],"x":174,"y":759,"w":692,"h":82},{"id":"98bd5b23672993a1","type":"inject","z":"b413f96e006352db","g":"1ed8538c313cd812","name":"Click to see DLQ records","props":[],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":330,"y":800,"wires":[["ad2553f403d14b2f"]]},{"id":"281734e9a00b621e","type":"debug","z":"b413f96e006352db","g":"1ed8538c313cd812","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":770,"y":800,"wires":[]},{"id":"ad2553f403d14b2f","type":"tables-query","z":"b413f96e006352db","g":"1ed8538c313cd812","name":"Query DLQ Table","query":"SELECT * FROM \"dlq\";","split":false,"rowsPerMsg":1,"x":590,"y":800,"wires":[["281734e9a00b621e"]]},{"id":"85c883f958a8248e","type":"group","z":"b413f96e006352db","name":"DLQ Implementation","style":{"label":true},"nodes":["8e0ac077e92630b1","d8871599d4c76ed6","aece3dfb5407b2be","ddbfd80ec3da0419","18976ac55bc49b95","086adbd104082fc6","e23ce8129b8aa06a","ffc30231275f6b15","92504ed47d1acc08","a6d2276f504fb649","c1df30e71498b75e","0e16cc1c80d8d28c"],"x":174,"y":439,"w":1652,"h":202},{"id":"8e0ac077e92630b1","type":"http request","z":"b413f96e006352db","g":"85c883f958a8248e","name":"POST /ingest","method":"POST","ret":"obj","url":"http://localhost:1880/ingest","x":1270,"y":500,"wires":[["d8871599d4c76ed6"]]},{"id":"d8871599d4c76ed6","type":"function","z":"b413f96e006352db","g":"85c883f958a8248e","name":"Check Response","func":"// restore retry state from protected property\nmsg.retry = msg._retry;\n\nif (msg.statusCode !== 200) {\n    msg.error = `API returned ${msg.statusCode}`;\n    node.error(msg.error, msg);\n    return null;\n}\n\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":1470,"y":500,"wires":[["aece3dfb5407b2be"]]},{"id":"aece3dfb5407b2be","type":"debug","z":"b413f96e006352db","g":"85c883f958a8248e","name":"Success","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","x":1660,"y":500,"wires":[]},{"id":"ddbfd80ec3da0419","type":"catch","z":"b413f96e006352db","g":"85c883f958a8248e","name":"Catch Errors","scope":["8e0ac077e92630b1","d8871599d4c76ed6"],"uncaught":false,"x":270,"y":560,"wires":[["18976ac55bc49b95"]]},{"id":"18976ac55bc49b95","type":"function","z":"b413f96e006352db","g":"85c883f958a8248e","name":"Normalize Error","func":"msg.retry = msg._retry;\n\nif (typeof msg.error === 'object') {\n    msg.error = msg.error.message || JSON.stringify(msg.error);\n}\n\nmsg.error = msg.error || 'Processing failed';\nreturn msg;","outputs":1,"x":460,"y":560,"wires":[["086adbd104082fc6"]]},{"id":"086adbd104082fc6","type":"function","z":"b413f96e006352db","g":"85c883f958a8248e","name":"Retry Manager","func":"const MAX_ATTEMPTS = msg.retry.maxAttempts || 5;\nconst BASE_DELAY_MS = 1000;\nconst MAX_DELAY_MS = 30000;\n\nmsg.retry.attempts += 1;\nmsg.retry.lastError = msg.error || 'Unknown error';\nmsg.retry.lastAttemptAt = new Date().toISOString();\n\n// keep _retry in sync\nmsg._retry = msg.retry;\n\nif (msg.retry.attempts >= MAX_ATTEMPTS) {\n    msg.retry.exhausted = true;\n    msg.dlq = {\n        reason: 'Max retries exceeded',\n        attempts: msg.retry.attempts,\n        lastError: msg.retry.lastError,\n        deadAt: new Date().toISOString()\n    };\n    return [null, msg];\n}\n\nconst exponential = BASE_DELAY_MS * Math.pow(2, msg.retry.attempts - 1);\nconst jitter = Math.random() * 1000;\nconst delay = Math.min(exponential + jitter, MAX_DELAY_MS);\n\nmsg.delay = Math.round(delay);\n\nnode.status({\n    fill: 'yellow',\n    shape: 'ring',\n    text: `Retry ${msg.retry.attempts}/${MAX_ATTEMPTS} in ${Math.round(delay / 1000)}s`\n});\n\nreturn [msg, null];","outputs":2,"x":660,"y":560,"wires":[["e23ce8129b8aa06a"],["92504ed47d1acc08"]]},{"id":"e23ce8129b8aa06a","type":"delay","z":"b413f96e006352db","g":"85c883f958a8248e","name":"Backoff Delay","pauseType":"delayv","timeout":"1","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"outputs":1,"x":880,"y":540,"wires":[["ffc30231275f6b15"]]},{"id":"ffc30231275f6b15","type":"change","z":"b413f96e006352db","g":"85c883f958a8248e","name":"Restore Payload","rules":[{"t":"set","p":"payload","pt":"msg","to":"_originalPayload","tot":"msg"}],"x":1080,"y":500,"wires":[["8e0ac077e92630b1"]]},{"id":"92504ed47d1acc08","type":"change","z":"b413f96e006352db","g":"85c883f958a8248e","name":"Build DLQ Params","rules":[{"t":"set","p":"queryParameters","pt":"msg","to":"{}","tot":"json"},{"t":"set","p":"queryParameters.id","pt":"msg","to":"_msgid","tot":"msg"},{"t":"set","p":"queryParameters.topic","pt":"msg","to":"retry.topic","tot":"msg"},{"t":"set","p":"queryParameters.payload","pt":"msg","to":"$string(_originalPayload)","tot":"jsonata"},{"t":"set","p":"queryParameters.attempts","pt":"msg","to":"retry.attempts","tot":"msg"},{"t":"set","p":"queryParameters.last_error","pt":"msg","to":"retry.lastError","tot":"msg"},{"t":"set","p":"queryParameters.captured_at","pt":"msg","to":"$now()","tot":"jsonata"}],"x":890,"y":600,"wires":[["0e16cc1c80d8d28c"]]},{"id":"a6d2276f504fb649","type":"debug","z":"b413f96e006352db","g":"85c883f958a8248e","name":"DLQ Record Saved","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","x":1690,"y":600,"wires":[]},{"id":"c1df30e71498b75e","type":"link in","z":"b413f96e006352db","g":"85c883f958a8248e","name":"link in 1","links":["e0addcc09f36a025"],"x":945,"y":480,"wires":[["ffc30231275f6b15"]]},{"id":"0e16cc1c80d8d28c","type":"tables-query","z":"b413f96e006352db","g":"85c883f958a8248e","name":"Insert DLQ Record","query":"INSERT INTO \"dlq\" (\"id\", \"topic\", \"payload\", \"attempts\", \"last_error\", \"captured_at\")\nVALUES ($id, $topic, $payload, $attempts, $last_error, $captured_at)\nON CONFLICT (\"id\") DO UPDATE SET\n  \"attempts\" = EXCLUDED.\"attempts\",\n  \"last_error\" = EXCLUDED.\"last_error\",\n  \"captured_at\" = EXCLUDED.\"captured_at\"","split":false,"rowsPerMsg":1,"x":1290,"y":600,"wires":[["a6d2276f504fb649"]]},{"id":"7cf8d797670d4025","type":"group","z":"b413f96e006352db","name":"Simulated API, Fails 80% of the Time","style":{"label":true},"nodes":["5bda1677a303bad5","16098f6123028007","87108585e5177d34"],"x":174,"y":659,"w":732,"h":82},{"id":"5bda1677a303bad5","type":"http in","z":"b413f96e006352db","g":"7cf8d797670d4025","name":"POST /ingest","url":"/ingest","method":"post","x":270,"y":700,"wires":[["16098f6123028007"]]},{"id":"16098f6123028007","type":"function","z":"b413f96e006352db","g":"7cf8d797670d4025","name":"Mock API 80% Fail","func":"const shouldFail = Math.random() < 0.8;\n\nif (shouldFail) {\n    msg.statusCode = 503;\n    msg.payload = { error: \"Service unavailable\", status: 503 };\n} else {\n    msg.statusCode = 200;\n    msg.payload = { success: true, status: 200 };\n}\n\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":590,"y":700,"wires":[["87108585e5177d34"]]},{"id":"87108585e5177d34","type":"http response","z":"b413f96e006352db","g":"7cf8d797670d4025","name":"Send Response","x":800,"y":700,"wires":[]},{"id":"a23e7b96d9aa726e","type":"group","z":"b413f96e006352db","name":"Simulate Sensor Reading","style":{"label":true},"nodes":["dd1b1440e1bf6cd4","2a9285c099b974a4","e0addcc09f36a025"],"x":174,"y":339,"w":622,"h":82},{"id":"dd1b1440e1bf6cd4","type":"inject","z":"b413f96e006352db","g":"a23e7b96d9aa726e","name":"Every 5s","repeat":"5","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":280,"y":380,"wires":[["2a9285c099b974a4"]]},{"id":"2a9285c099b974a4","type":"function","z":"b413f96e006352db","g":"a23e7b96d9aa726e","name":"Simulate Reading","func":"msg.payload = {\n    sensorId: 'sensor-001',\n    temperature: +(Math.random() * 40 + 10).toFixed(2),\n    unit: 'celsius',\n    timestamp: new Date().toISOString()\n};\nmsg.topic = 'sensors/temperature';\nmsg._originalPayload = RED.util.cloneMessage(msg.payload);\n\nif (!msg._retry) {\n    msg._retry = {\n        attempts: 0,\n        maxAttempts: 5,\n        lastError: null,\n        originalTimestamp: new Date().toISOString(),\n        topic: msg.topic\n    };\n}\n\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":630,"y":380,"wires":[["e0addcc09f36a025"]]},{"id":"e0addcc09f36a025","type":"link out","z":"b413f96e006352db","g":"a23e7b96d9aa726e","name":"link out 1","mode":"link","links":["c1df30e71498b75e"],"x":755,"y":380,"wires":[]},{"id":"10288c58ceddb722","type":"global-config","env":[],"modules":{"@flowfuse/nr-tables-nodes":"0.2.1"}}]
```
::

## Closing Thoughts

Every message your system drops was someone's data. A sensor reading that never made it. A transaction that silently disappeared. An event that the downstream system never knew existed. In most IIoT deployments these failures are invisible. No record, no alert, no way to recover what was lost.

That is the problem this pattern solves.

A Dead Letter Queue does not make your system more reliable. Reliability comes from good infrastructure, careful design, and redundancy. What a DLQ gives you is honesty. An honest record of every message that could not be delivered, with enough context to understand why, and enough structure to do something about it.

You deploy it once and it works quietly in the background until the moment you need it.

And you will need it. Not because your flows are poorly built, but because distributed systems fail. APIs go down. Networks drop. Services timeout at the worst possible moment. The question has never been whether that happens. It is whether you are ready when it does.

Now you are.


# How to Monitor Industrial Network Health Using SNMP

Industrial networks fail quietly. A saturated uplink, a flapping interface, or a device nearing its resource ceiling degrades silently until a line goes down or a control loop breaks.

SNMP exists precisely to prevent that. Decades proven, it remains the most reliable protocol for extracting health telemetry from switches, routers, PLCs, and RTUs. No agents, no overhead, runs on everything.

The gap has always been implementation. Most teams either over-engineer it with heavyweight NMS platforms or under-engineer it with brittle scripts. Neither is acceptable when network visibility is an uptime and safety concern.

This guide walks through building a production-grade SNMP monitoring pipeline with FlowFuse, polling device metrics, discovering interfaces, and feeding telemetry into a FlowFuse Dashboard where your team can act on it.

## Prerequisites

Before getting started, make sure you have the following in place:

- **FlowFuse:** A running FlowFuse instance on your edge device. If you do not have an account yet, [sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} to get started and follow this [guide to get Node-RED running](https://flowfuse.com/blog/2025/09/installing-node-red/).
- **An SNMP-enabled device:** Any managed switch, router, PLC, or RTU with SNMP enabled and UDP port 161 accessible from your FlowFuse instance. If you do not have a real device available, you can run a local SNMP agent for testing, see [net-snmp.org](http://www.net-snmp.org/download.html){rel="&#x22;nofollow&#x22;"} for installation instructions for your platform.
- **UDP port 161 access:** Confirm your community string and ensure firewall rules permit SNMP polling from your FlowFuse host to the target device.

## Understanding SNMP

[SNMP](https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol){rel="&#x22;nofollow&#x22;"} operates on a simple manager-agent model. The **manager** (your FlowFuse instance) sends requests to the **agent** (a network device or server running an SNMP daemon) and the agent responds with the requested data. All communication happens over UDP port 161.

Data on the agent is organized in a &#x2A;*Management Information Base (MIB)**, a hierarchical tree of objects, each identified by an &#x2A;*Object Identifier (OID)**. Every piece of information you can query from a device, its uptime, interface status, traffic counters, CPU load, has a unique OID.

There are three operations you will use in this guide:

- **GET:** Fetch the value of a specific OID from a device.
- **WALK:** Traverse an entire OID subtree and return all values beneath it. Useful for querying all interfaces at once.
- **SUBTREE:** Fetch a specific OID subtree and everything beneath it. More targeted than a full walk.

SNMP also has versions. **SNMPv1** and **v2c** use a plain-text community string as authentication. **SNMPv3** adds user-based authentication and encryption. For production industrial environments, v3 is the right choice. For this guide, we use v2c to keep the focus on the implementation.

## Installing SNMP Package in FlowFuse

The `node-red-node-snmp` package provides a set of nodes for communicating with SNMP-enabled devices directly from your flows. Before building the monitoring pipeline, install it into your FlowFuse instance.

1. Open your FlowFuse instance and navigate to the Node-RED editor.
2. Click the hamburger menu in the top-right corner and select **Manage Palette**.
3. Go to the **Install** tab.
4. Search for `node-red-node-snmp`.
5. Click **Install** and wait for the installation to complete.

Once installed, you will see the following nodes available in your palette under the network category:

- **snmp**, fetch one or more specific OIDs
- **snmp walker**, walk from a given OID to the end of the MIB tree
- **snmp subtree**, fetch a specific OID subtree and everything beneath it
- **snmp table**, fetch structured SNMP table data
- **snmp set**, write values back to a device

![SNMP nodes available in the Node-RED palette after installing node-red-node-snmp](https://flowfuse.com/blog/2026/03/images/snmp-nodes.png)*SNMP nodes available in the Node-RED palette after installing node-red-node-snmp*

For this guide we will be working with **snmp**, **snmp walker**, and **snmp subtree**. These three cover the core read operations needed for network health monitoring.

## Polling Device Metrics with SNMP GET

The snmp node sends a GET request to the agent and returns the values of the OIDs you specify. You can pass a single OID or a comma-separated list, the node fetches all of them in one request and returns the results as an array. This is the right operation when you know exactly what you want to fetch, system uptime, device name, description.

We will poll three key system OIDs in a single GET request every five seconds. All three sit under the `system` group (`1.3.6.1.2.1.1`), which is part of [MIB-II](https://www.rfc-editor.org/rfc/rfc1213.html){rel="&#x22;nofollow&#x22;"}, the standard MIB supported by virtually every SNMP-enabled device. Standard OIDs are consistent across vendors, so the same OID returns `sysUpTime` whether you are querying a Cisco switch, a Siemens PLC, or a Linux server. Vendor-specific metrics live under `1.3.6.1.4.1` and vary by device, you will need the vendor's MIB file for those. For browsing standard OIDs, see the [OID reference for the system group](https://www.alvestrand.no/objectid/1.3.6.1.2.1.1.html){rel="&#x22;nofollow&#x22;"}.

| OID                 | Name      | What it returns                                    |
| ------------------- | --------- | -------------------------------------------------- |
| `1.3.6.1.2.1.1.3.0` | sysUpTime | How long the device has been running, in timeticks |
| `1.3.6.1.2.1.1.5.0` | sysName   | The configured hostname of the device              |
| `1.3.6.1.2.1.1.1.0` | sysDescr  | A full description of the hardware and OS          |

1. Drag an **inject** node onto the canvas and double click it. Set the repeat interval to **every 5 seconds** and click **Done**.
2. Drag an **snmp** node onto the canvas and double click it to configure:

| Field     | Value                                                   |
| --------- | ------------------------------------------------------- |
| Host      | IP address of your target device, e.g. `192.168.1.1`    |
| Community | `public`                                                |
| Version   | `v2c`                                                   |
| OIDs      | `1.3.6.1.2.1.1.3.0,1.3.6.1.2.1.1.5.0,1.3.6.1.2.1.1.1.0` |

> Note: OIDs in the list must be comma-separated with no spaces between them.

3. Click **Done**.
4. Drag a **debug** node onto the canvas, connect it to the snmp node output, and click **Deploy** to verify the raw response first.

You will notice the response is not immediately human-readable. OctetString values such as `sysName` and `sysDescr` come back as byte arrays, and `sysUpTime` arrives as a raw TimeTicks integer:

```json
[
  { "oid": "1.3.6.1.2.1.1.3.0", "type": 67, "value": 317537, "tstr": "TimeTicks" },
  { "oid": "1.3.6.1.2.1.1.5.0", "type": 4, "value": [34, 116, 101, 115, 116, ...], "tstr": "OctetString" },
  { "oid": "1.3.6.1.2.1.1.1.0", "type": 4, "value": [68, 97, 114, 119, 105, ...], "tstr": "OctetString" }
]
```

We need a function node to convert byte arrays to strings and TimeTicks to a readable uptime format.

5. Drag a **function** node onto the canvas and insert it between the snmp node and the debug node.
6. Double click it and add the following code:

```javascript
const parsed = msg.payload.map(item => {
    let value = item.value;

    if (item.tstr === "OctetString") {
        value = Buffer.from(value).toString("utf8").replace(/"/g, "");
    }

    if (item.tstr === "TimeTicks") {
        const totalSeconds = Math.floor(value / 100);
        const days = Math.floor(totalSeconds / 86400);
        const hours = Math.floor((totalSeconds % 86400) / 3600);
        const minutes = Math.floor((totalSeconds % 3600) / 60);
        const seconds = totalSeconds % 60;
        value = `${days}d ${hours}h ${minutes}m ${seconds}s`;
    }

    return { oid: item.oid, name: item.tstr, value };
});

msg.payload = parsed;
return msg;
```

> **Tip:** If you need different parsing logic for additional OID types or want to transform the output differently, you do not have to write it from scratch. FlowFuse's [AI-powered function generation](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/#function-code-generation) lets you describe what you need in plain English and generates the function node code for you directly inside the editor.

7. Click **Done** and click **Deploy**.

The debug panel will now show clean, readable output:

```json
[
  { "oid": "1.3.6.1.2.1.1.3.0", "name": "TimeTicks", "value": "0d 0h 52m 55s" },
  { "oid": "1.3.6.1.2.1.1.5.0", "name": "OctetString", "value": "test-device" },
  { "oid": "1.3.6.1.2.1.1.1.0", "name": "OctetString", "value": "Linux core-switch-01 5.15.0 #1 SMP x86_64" }
]
```

With system metrics polling cleanly, the next section covers using the snmp walker node to discover and monitor all network interfaces on the device.

## Discovering Interfaces with SNMP Walker

The snmp walker node traverses the MIB tree starting from a given OID and returns every object beneath it. Unlike GET where you specify exact OIDs, walker is useful when you do not know the full OID path in advance, for example, discovering all network interfaces on a device without knowing how many exist or what their index numbers are.

Network interfaces on any SNMP device live under the `ifTable` (`1.3.6.1.2.1.2.2`). Walking this subtree returns every interface along with its name, operational status, speed, and traffic counters, one entry per interface regardless of how many the device has.

| OID                    | Name         | What it returns                                   |
| ---------------------- | ------------ | ------------------------------------------------- |
| `1.3.6.1.2.1.2.2.1.1`  | ifIndex      | Unique index number for each interface            |
| `1.3.6.1.2.1.2.2.1.2`  | ifDescr      | Interface name, e.g. `eth0`, `GigabitEthernet0/1` |
| `1.3.6.1.2.1.2.2.1.8`  | ifOperStatus | Operational status, `1` = up, `2` = down          |
| `1.3.6.1.2.1.2.2.1.10` | ifInOctets   | Total inbound bytes on the interface              |
| `1.3.6.1.2.1.2.2.1.16` | ifOutOctets  | Total outbound bytes on the interface             |

Walking from `1.3.6.1.2.1.2.2` returns all of the above for every interface in one request. For the full ifTable OID reference see [alvestrand.no/objectid/1.3.6.1.2.1.2.2](https://www.alvestrand.no/objectid/1.3.6.1.2.1.2.2.html){rel="&#x22;nofollow&#x22;"}.

> **Note:** The walker node requires a device with a populated interface table. If you are using a lightweight test agent, increase the timeout in the walker node configuration to at least 30 seconds. On resource-constrained devices that cannot handle bulk requests, use the snmp subtree node instead.

1. Drag an **inject** node onto the canvas and double click it. Set the repeat interval to **every 10 seconds** and click **Done**.
2. Drag an **snmp walker** node onto the canvas and double click it to configure:

| Field     | Value                                                |
| --------- | ---------------------------------------------------- |
| Host      | IP address of your target device, e.g. `192.168.1.1` |
| Community | `public`                                             |
| Version   | `v2c`                                                |
| OID       | `1.3.6.1.2.1.2.2`                                    |
| Timeout   | `30`                                                 |

3. Click **Done**.
4. Drag a **function** node onto the canvas and insert it between the walker node and a debug node. Double click it and add the following code to parse the response into a readable structure:

```javascript
const interfaces = {};

msg.payload.forEach(item => {
    if (!item.oid.startsWith("1.3.6.1.2.1.2.2.1.")) return;

    const parts = item.oid.split(".");
    const ifIndex = parts[parts.length - 1];
    const subOid = parts.slice(0, -1).join(".");

    if (!interfaces[ifIndex]) interfaces[ifIndex] = { index: ifIndex };

    let value = item.value;

    const oidMap = {
        "1.3.6.1.2.1.2.2.1.1": "ifIndex",
        "1.3.6.1.2.1.2.2.1.2": "ifDescr",
        "1.3.6.1.2.1.2.2.1.8": "ifOperStatus",
        "1.3.6.1.2.1.2.2.1.10": "ifInOctets",
        "1.3.6.1.2.1.2.2.1.16": "ifOutOctets"
    };

    if (oidMap[subOid]) {
        if (subOid === "1.3.6.1.2.1.2.2.1.2") {
            const data = value.data || value;
            value = Buffer.from(data).toString("utf8").replace(/"/g, "").trim();
        } else if (subOid === "1.3.6.1.2.1.2.2.1.8") {
            value = value === 1 ? "up" : "down";
        }
        interfaces[ifIndex][oidMap[subOid]] = value;
    }
});

msg.payload = Object.values(interfaces).filter(i => i.ifDescr);
return msg;
```

5. Click **Done**.
6. Drag a **debug** node onto the canvas and connect it to the function node output.
7. Connect the inject node output to the walker node input, and the walker node output to the function node input.
8. Click **Deploy**.

The debug panel will show a clean array of interface objects like this:

```json
[
  {
    "index": "1",
    "ifIndex": 1,
    "ifDescr": "lo",
    "ifOperStatus": "up",
    "ifInOctets": 20526,
    "ifOutOctets": 20526
  },
  {
    "index": "2",
    "ifIndex": 2,
    "ifDescr": "enp0s1",
    "ifOperStatus": "up",
    "ifInOctets": 48159944,
    "ifOutOctets": 4263495
  }
]
```

Each entry represents one interface with its current operational status and traffic counters. In the next section we will use the snmp subtree node to fetch interface data more precisely by targeting a specific OID subtree.

## Fetching Interface Data with SNMP Subtree

The snmp subtree node is similar to walker but more targeted. Where walker reads from a given OID to the end of the entire MIB tree, subtree fetches everything beneath a specific OID and stops there. This makes it more predictable and efficient when you know the exact branch you want.

For network health monitoring, a practical use of subtree is pulling all operational status values for every interface in one shot by targeting `ifOperStatus` directly at `1.3.6.1.2.1.2.2.1.8`. This gives you a clean up/down status for every interface on the device without pulling traffic counters or other data you do not need at that moment.

1. Drag an **inject** node onto the canvas and double click it. Set the repeat interval to **every 10 seconds** and click **Done**.
2. Drag an **snmp subtree** node onto the canvas and double click it to configure:

| Field     | Value                                                |
| --------- | ---------------------------------------------------- |
| Host      | IP address of your target device, e.g. `192.168.1.1` |
| Community | `public`                                             |
| Version   | `v2c`                                                |
| OID       | `1.3.6.1.2.1.2.2.1.8`                                |

3. Click **Done**.
4. Drag a **function** node onto the canvas and insert it between the subtree node and a debug node. Double click it and add the following code to parse the interface status values:

```javascript
const statuses = msg.payload.map(item => {
    const parts = item.oid.split(".");
    const ifIndex = parts[parts.length - 1];
    return {
        ifIndex: ifIndex,
        ifOperStatus: item.value === 1 ? "up" : "down"
    };
});

msg.payload = statuses;
return msg;
```

> **Tip:** If you need different parsing logic for additional OID types or want to transform the output differently, you do not have to write it from scratch. FlowFuse's [AI-powered function generation](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/#function-code-generation) lets you describe what you need in plain English and generates the function node code for you directly inside the editor.

5. Click **Done**.
6. Connect the inject node to the subtree node, the subtree node to the function node, and the function node to a debug node.
7. Click **Deploy**.

The debug panel will show a concise status array for every interface:

```json
[
  { "ifIndex": "1", "ifOperStatus": "up" },
  { "ifIndex": "2", "ifOperStatus": "down" }
]
```

This is the most efficient way to run a continuous interface health check, one subtree poll every 10 seconds tells you the operational state of every interface on the device without fetching data you do not need.

With all three polling operations in place, the next step is wiring this data into a [FlowFuse Dashboard](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"} so the information is visible at a glance.

## Wrapping Up

Industrial networks don't announce their problems. They accumulate them silently until a line goes down, a control loop breaks, or production stops.

The pipeline you've built here changes that. GET, Walker, and Subtree give you precise, continuous visibility into every device on your network. FlowFuse delivers it without the infrastructure overhead of a full NMS platform or the maintenance burden of hand-rolled scripts.

Wire the telemetry into a FlowFuse Dashboard. Set threshold-based alerts. Extend your OID coverage to vendor-specific metrics as your requirements grow. The foundation is in place. Everything else is iteration.

Unmonitored networks are a liability. Now yours isn't.


# How to Parse Binary Data from Serial Devices

Your device is sending bytes. You don't know what they mean. The device manual is a 40-page PDF from 2003, and page 12 has a table of numbers with no explanation of what to do with them.

This is the situation most engineers hit when they connect a legacy serial device for the first time. The serial connection works. The bytes arrive. But nothing tells you what those bytes represent, and there is no standard to fall back on the way there is with Modbus.

This article gives you a repeatable method for decoding binary output from any serial device. We'll use an industrial weighing scale as the example. By the end, you'll know exactly how to approach your own device, regardless of what it sends.

## The Method

Every binary parsing problem follows the same four steps.

**Read the manual.** Find the communication protocol section, not the installation guide. You are looking for the frame structure, the byte order, and the data types for each field. If the manual calls it a "data format" or "output format" section, that is the one. Everything else depends on this.

**Identify the frame type.** Frames from serial devices arrive in one of three structures. Fixed length frames are the simplest, every message is always the same number of bytes. Delimiter terminated frames end with a specific byte or sequence. Length prefixed frames include a byte early in the message that tells you how many bytes follow. Knowing which type your device uses determines how you validate and reassemble frames before parsing.

**Validate before you parse.** Every frame should pass a basic sanity check before your parsing logic runs. At minimum, verify the frame length and any start or end markers your device includes. If your device provides a checksum, verify that too. A frame that fails validation gets dropped. A corrupted value that passes through and ends up on a dashboard or in a database is far more damaging.

**Map the bytes.** Once a frame passes validation, assign every byte a meaning based on the manual. Name, type, offset, endianness, scale. This is where FlowFuse's Buffer Parser node does its work, visually, without code, with every field visible at a glance.

The rest of this article walks through all four steps using a concrete example.

## The Example: Industrial Weighing Scale

We'll use a common industrial weighing scale that outputs data over RS-232. You'll find this type of device in packaging lines, logistics warehouses, and food processing plants. It has no Modbus support. It sends its own fixed binary frame every time a stable reading is available.

The manual specifies a fixed-length frame of exactly 10 bytes:

| Byte | Value            | Description                                      |
| ---- | ---------------- | ------------------------------------------------ |
| 0    | `0x02`           | STX, start of frame                              |
| 1–4  | 32-bit float     | Weight value, little-endian                      |
| 5    | `0x01` or `0x02` | Unit indicator, 1 = kg, 2 = lb                   |
| 6    | Bitfield         | Status flags                                     |
| 7    |                  | Reserved                                         |
| 8    | Byte             | Checksum, sum of bytes 1–7 truncated to one byte |
| 9    | `0x03`           | ETX, end of frame                                |

Byte 0 is always `0x02`. Byte 9 is always `0x03`. These are your frame markers. Bytes 1 through 4 carry the weight as a 32-bit IEEE 754 float in little-endian order, meaning the least significant byte comes first. Byte 5 tells you whether the scale is set to kilograms or pounds. Byte 6 is a status bitfield where individual bits carry meaning, bit 0 is stable, bit 1 is overload, bit 2 is zero.

This is the raw buffer the scale sends for a 23.5 kg stable reading:

```text
<Buffer 02 00 00 bb 41 01 03 00 5f 03>
```

By the end of this article, that buffer becomes:

```json
{
  "weight": 23.5,
  "unit": "kg",
  "stable": true,
  "overload": false,
  "zero": false
}
```

## Building the Flow in FlowFuse

We'll simulate the device output using an Inject node so you can follow along without hardware. In a real deployment, the Inject node is replaced by a Serial In node receiving bytes directly from the device. The parsing logic, the validation, the Buffer Parser configuration, all of it stays identical. The only difference is where the bytes come from. If you want to set up the actual serial connection, [this article covers that](https://flowfuse.com/blog/2025/07/connect-legacy-equipment-serial-flowfuse/).

The flow is: **Inject node** connected to a **Function node** connected to a **Buffer Parser node** connected to a **Switch node**, each output of the Switch connected to its own **Change node**, both Change nodes connected to a &#x2A;*Debug node.**

### Step 1: Install the Buffer Parser Node

The Buffer Parser node is not included in Node-RED by default. To install it:

1. Open your Node-RED editor
2. Click the hamburger menu (top right)
3. Go to **Manage palette** → **Install** tab
4. Search for node-red-contrib-buffer-parser
5. Click **Install**

Once installed, the node will appear in your palette and you can proceed with building the flow. If you're on FlowFuse, your administrator may have already added it to your shared palette, check before installing.

### Step 2: Simulate the Device

1. Drag an **Inject** node onto the canvas and double-click it
2. Set **msg.payload** type to **Buffer** from the dropdown
3. Enter: `[2,0,0,188,65,1,3,0,1,3]`
4. Click **Done**

Every time you click the Inject button, the flow receives these 10 bytes exactly as it would from a live serial connection.

### Step 3: Validate the Frame

Add a **Function node** and paste in the following. This is the only JavaScript in the entire flow.

```javascript
const buf = msg.payload;

// Check frame length
if (buf.length !== 10) {
    return null;
}

// Check start and end markers
if (buf[0] !== 0x02 || buf[9] !== 0x03) {
    return null;
}

// Validate checksum
let sum = 0;
for (let i = 1; i <= 7; i++) {
    sum += buf[i];
}
if ((sum & 0xFF) !== buf[8]) {
    return null;
}

return msg;
```

Three checks: frame length, start and end markers, checksum. If any fail, the message is dropped. Only clean, verified frames reach the Buffer Parser.

### Step 4: Parse the Bytes

Add a **Buffer Parser node** and double-click it. Set **Output** to **key/value**. Then add one row for each field.

**Weight**

- Name: `weight`
- Type: `floatle` (32-bit IEEE 754 float, little-endian)
- Offset: `1`
- Length: `1`

**Unit**

- Name: `unit`
- Type: `uint8`
- Offset: `5`
- Length: `1`

**Status flag, stable**

- Name: `stable`
- Type: `bool`
- Offset: `6`
- Bit Offset: `0`

**Status flag, overload**

- Name: `overload`
- Type: `bool`
- Offset: `6`
- Bit Offset: `1`

**Status flag, zero**

- Name: `zero`
- Type: `bool`
- Offset: `6`
- Bit Offset: `2`

![Buffer Parser node configuration showing weight, unit, and status flag fields mapped to their respective byte offsets](https://flowfuse.com/blog/2026/03/images/buffer-parser.png)*Configuring the Buffer Parser node to extract weight, unit, and status flags from the 10-byte frame*

The float conversion, the byte reading, the individual bit extraction, all handled visually without code. The `bool` type with Bit Offset is what makes bitfield parsing possible here. Each status flag is packed into a single byte, and the Buffer Parser pulls them out one bit at a time. If you want a deeper walkthrough of every Buffer Parser field and configuration option, [this article covers it in full](https://flowfuse.com/blog/2025/12/node-red-buffer-parser-industrial-data/).

### Step 5: Map the Unit Value

The Buffer Parser gives you `1` or `2` for the unit byte. A **Switch node** routes the message based on that value, and a **Change node** on each route sets the correct label.

Configure the Switch node:

- Property: `msg.payload.unit`
- Rule 1: equals `1` → output 1
- Rule 2: equals `2` → output 2

Connect each output to its own Change node:

- Output 1 Change node: set `msg.payload.unit` to the string `"kg"`
- Output 2 Change node: set `msg.payload.unit` to the string `"lb"`

Connect both Change nodes to the Debug node. Click **Deploy**, then click the Inject button. Your debug panel will show:

```json
{
  "weight": 23.5,
  "unit": "kg",
  "stable": true,
  "overload": true,
  "zero": false
}
```

::render-flow{:height='300'}
```json
[{"id":"d8bc179d698f39a2","type":"group","z":"FFF0000000000001","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["5ee755d20d300b60","e07e9371618f926f","aedfa06fb7109f18","045959569e84a098","947db003dbd32127","23c25ca58a0784b0","e541260b3b581eac"],"x":1294,"y":719,"w":1012,"h":122},{"id":"5ee755d20d300b60","type":"inject","z":"FFF0000000000001","g":"d8bc179d698f39a2","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"[2,0,0,188,65,1,3,0,1,3]","payloadType":"bin","x":1390,"y":780,"wires":[["e07e9371618f926f"]]},{"id":"e07e9371618f926f","type":"function","z":"FFF0000000000001","g":"d8bc179d698f39a2","name":"Validate Frame","func":"const buf = msg.payload;\n\n// Check frame length\nif (buf.length !== 10) {\n    return null;\n}\n\n// Check start and end markers\nif (buf[0] !== 0x02 || buf[9] !== 0x03) {\n    return null;\n}\n\n// Validate checksum\nlet sum = 0;\nfor (let i = 1; i <= 7; i++) {\n    sum += buf[i];\n}\nif ((sum & 0xFF) !== buf[8]) {\n    return null;\n}\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1560,"y":780,"wires":[["aedfa06fb7109f18"]]},{"id":"aedfa06fb7109f18","type":"buffer-parser","z":"FFF0000000000001","g":"d8bc179d698f39a2","name":"Parse Frame","data":"payload","dataType":"msg","specification":"spec","specificationType":"ui","items":[{"type":"floatle","name":"weight","offset":1,"length":1,"offsetbit":0,"scale":"1","mask":""},{"type":"uint8","name":"unit","offset":5,"length":1,"offsetbit":0,"scale":"1","mask":""},{"type":"bool","name":"stable","offset":6,"length":1,"offsetbit":0,"scale":"1","mask":""},{"type":"bool","name":"overload","offset":6,"length":1,"offsetbit":1,"scale":"1","mask":""},{"type":"bool","name":"zero","offset":6,"length":1,"offsetbit":2,"scale":"1","mask":""}],"swap1":"","swap2":"","swap3":"","swap1Type":"swap","swap2Type":"swap","swap3Type":"swap","msgProperty":"payload","msgPropertyType":"str","resultType":"keyvalue","resultTypeType":"return","multipleResult":false,"fanOutMultipleResult":false,"setTopic":true,"outputs":1,"x":1750,"y":780,"wires":[["045959569e84a098"]]},{"id":"045959569e84a098","type":"switch","z":"FFF0000000000001","g":"d8bc179d698f39a2","name":"Map Unit","property":"msg.payload.unit","propertyType":"msg","rules":[{"t":"eq","v":"1","vt":"num"},{"t":"eq","v":"2","vt":"num"}],"checkall":"true","repair":false,"outputs":2,"x":1920,"y":780,"wires":[["947db003dbd32127"],["23c25ca58a0784b0"]]},{"id":"947db003dbd32127","type":"change","z":"FFF0000000000001","g":"d8bc179d698f39a2","name":"Set kg","rules":[{"t":"set","p":"payload.unit","pt":"msg","to":"kg","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":2070,"y":760,"wires":[["e541260b3b581eac"]]},{"id":"23c25ca58a0784b0","type":"change","z":"FFF0000000000001","g":"d8bc179d698f39a2","name":"Set lb","rules":[{"t":"set","p":"payload.unit","pt":"msg","to":"lb","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":2070,"y":800,"wires":[["e541260b3b581eac"]]},{"id":"e541260b3b581eac","type":"debug","z":"FFF0000000000001","g":"d8bc179d698f39a2","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":2210,"y":780,"wires":[]},{"id":"f0a3951924692010","type":"global-config","env":[],"modules":{"node-red-contrib-buffer-parser":"3.2.2"}}]
```
::

## When Things Get Harder

The weighing scale had a clean, fixed-length frame. Not every device will.

### Frames Arriving Split Across Multiple Messages

Depending on baud rate and buffer size, a single frame can arrive as two or more separate messages. If you try to parse a partial frame, you get garbage. The fix is a reassembly Function node placed before the validation step, using node context to accumulate bytes until a full frame is available:

```javascript
let buffer = context.get("buffer") || Buffer.alloc(0);
buffer = Buffer.concat([buffer, msg.payload]);

if (buffer.length < 10) {
    context.set("buffer", buffer);
    return null;
}

msg.payload = buffer.slice(0, 10);
context.set("buffer", buffer.slice(10));

return msg;
```

For delimiter-terminated frames, replace the length check with a search for your end byte. For length-prefixed frames, read the length byte first and use that as your target size.

### When Buffer Parser Is Not Enough

Buffer Parser handles fixed-structure protocols well. Two situations require a Function node instead.

The first is conditional structure, where the layout of later bytes depends on the value of an earlier byte. Buffer Parser parses a fixed specification every time. If your frame changes shape based on its own content, you need code.

The second is complex computed fields. If your device sends a raw ADC value that requires a multi-step calibration formula, Buffer Parser's scale field won't cover it. Add a Function node after Buffer Parser to handle only that calculation.

In both cases: let Buffer Parser do what it can, and add a Function node only for the parts it cannot.

> If you're on FlowFuse, you don't need to write that JavaScript yourself. Describe what you need to the [FlowFuse Expert](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/#function-code-generation) in plain English and paste the relevant section of your device manual. It will generate the Function node directly on your canvas.
>
> **Example prompt you can use:**
>
> ```text
> I have a serial device sending binary data with this frame structure:
> - Byte 0: 0x02 (start)
> - Byte 1: message type
> - Bytes 2–5: 32-bit float (little-endian)
> - Byte 6: status bitfield
> - Last byte: checksum (sum of bytes)
>
> The frame structure changes based on the message type.
>
> Generate a Node-RED Function node that:
> 1. Validates the frame (start, length, checksum)
> 2. Parses fields based on message type
> 3. Extracts bitfield values into booleans
> ```
>
> Paste your device manual section along with the prompt for best results.

## Applying This to Your Own Device

The weighing scale is one device. To show the method transfers, here is how it applies to a completely different device, an industrial barcode scanner.

The scanner sends a variable-length frame every time it reads a label. The manual specifies a delimiter-terminated structure ending with `0x0D` (carriage return). Here is the frame layout:

| Byte | Value       | Description                   |
| ---- | ----------- | ----------------------------- |
| 0    | `0x02`      | STX, start of frame           |
| 1    | uint8       | Scanner ID                    |
| 2–N  | ASCII bytes | Barcode data, variable length |
| N+1  | `0x0D`      | CR, end of frame              |

The device and the frame look nothing like the weighing scale. The method is identical.

**Read the manual.** Frame structure: delimiter terminated, ends with `0x0D`. Data types: ASCII bytes for the barcode value, uint8 for the scanner ID.

**Identify the frame type.** Delimiter terminated. Your reassembly logic searches for `0x0D` instead of checking a fixed length.

**Validate before you parse.** Check for the STX start byte at position 0 and the `0x0D` end byte at the last position. No checksum on this device, so those two markers are your full validation.

**Map the bytes.** In the Buffer Parser, one row for the scanner ID at offset 1 as uint8. The barcode data is ASCII from offset 2 to the end of the frame, which you read as a string type with the appropriate length.

Four steps. Different device, different frame structure, same process. The Buffer Parser configuration looks different because the bytes are different. The thinking behind it is the same.

This is what the method gives you. Not a recipe for one specific device, but a way of reading any device manual and turning what you find there into a working flow.

If you are managing flows across multiple edge devices, FlowFuse deploys the same configuration everywhere through its remote deployment pipeline, with snapshots to roll back if anything changes on the device side.

## Final Thoughts

Modbus made binary parsing approachable because someone defined the rules in advance. Raw serial devices hand you a PDF instead. That is the real difficulty, not the parsing itself.

The method in this article works for weighing scales, barcode scanners, RFID readers, CNC machines, and whatever proprietary hardware is sitting on your factory floor with no documentation beyond a table of hex values. Once you have applied it once, you will recognize the pattern in every device you connect after it.

The factories with the most valuable operational data are often the ones running the oldest hardware. That data is accessible. It just requires knowing how to read it.


# The Last Mile Problem in Industrial AI

There is a slide that lives in almost every industrial AI project deck.

On the left: data collection, model training, validation. On the right: operational value, reduced downtime, optimized throughput. In the middle, a small box labeled "deployment" that nobody in the room questions, because everyone has already moved on to the numbers on the right.

That box is where most industrial AI projects end.

Not with a failure report. Not with a cancelled contract. They end slowly, in staging environments that quietly become permanent, in quarterly reviews where "ongoing" gets said for the fourth time with less conviction than the third. The model is fine. The model has always been fine. The floor looks exactly the same as it did before the project started.

What lives inside that box is harder than the model and less interesting to talk about. It is the work of connecting intelligent software to a plant that was not built to receive it. Machines that predate wireless. Protocols designed for reliability, not interoperability. Engineers who know every quirk of every line and have watched enough consultants walk through with laptops to reserve judgment until something actually works.

In logistics, the last mile is the final stretch of a delivery, the leg that accounts for more than half the cost of shipping and has defeated every attempt to engineer it away. Industrial AI has the same problem. Not measured in distance. Measured in the gap between a model that performs and a plant that benefits.

Most industrial AI projects are funded to build the model. The mile after it gets a box on a slide.

## The Scoping Lie

Every industrial AI project proposal looks roughly the same.

There is a discovery phase. A data assessment. A model development stage with clear milestones and measurable accuracy targets. And then, near the bottom of the document, a deployment section that is usually one page, sometimes half a page, occasionally a single bullet point that says something like "integration with existing systems" without specifying which systems, how long that will take, or who is responsible for it.

That bullet point is where the project dies. It just takes six months to find out.

The people writing these proposals are not being dishonest. They are being optimistic in the way that every vendor is optimistic when the contract has not been signed yet. The integration work is real, they know it is real, but it is also the part of the project that is hardest to scope without knowing the plant, the protocols, the historian configuration, the network topology, the IT security policies, and a dozen other variables that only become visible once someone is standing on the floor with access credentials and a growing sense of unease.

So it gets compressed. One line. One assumption. One box on a slide.

And the buyer approves it, because the buyer is looking at the numbers on the right side of the timeline, the ones showing reduced downtime and optimized throughput, and the deployment box is between them and those numbers, and it looks small.

It is not small.

The integration work in a real industrial environment is not a technical footnote. It is the project. Connecting an AI model to a plant means touching systems that the OT team has kept stable for a decade and does not want anyone near. It means translating between protocols that were never designed to talk to each other. It means getting IT and OT into the same room, agreeing on data ownership, network access, security boundaries, and update procedures for infrastructure that both teams think belongs to the other.

None of that is in the proposal. All of it determines whether the proposal was worth signing.

## The Cost of Standing Still

Pilot purgatory feels like a neutral state. The project is not cancelled. Progress is being made. The model is ready whenever the integration catches up.

It is not neutral.

Every month an AI model sits in staging is a month of decisions made on instinct instead of intelligence. A predictive maintenance model that never reached the floor did not just fail to deliver value. It failed to prevent every unplanned downtime event it would have caught. Every quality escape the anomaly detector would have flagged. Every maintenance window scheduled too late or too early because the optimization model was still "ongoing."

That cost does not appear in any project report. It is invisible precisely because the thing that would have measured it never got deployed. But it is real, and it compounds.

Every stalled initiative also makes the next one harder to fund. The VP who approved the last pilot is not writing another check with the same enthusiasm. The organizational appetite for transformation is not infinite. Stalled pilots consume it without producing anything in return.

## The Ownership Vacuum

Here is a question worth asking before the next industrial AI project gets funded.

When the model is in production and something goes wrong at 2 a.m. on a Saturday, who gets the call?

In most manufacturing organizations, nobody has a clean answer to that. The data science team built the model but does not own the plant systems it connects to. The OT team owns the plant but did not build the model and does not have visibility into why it is behaving the way it is. IT owns the network the data travels across but considers the edge devices an OT problem. Nobody owns the pipeline between them.

This is not a technology problem. It is a leadership problem that has been dressed up as one.

The technology gap between a trained model and a production deployment is real, but it is solvable. Talented engineers solve harder problems every day. What stops them is not the complexity of the integration. It is the absence of anyone whose job it is to own the outcome. When the integration work falls between two teams and neither team has it in their objectives, it does not get done. It gets discussed. It gets escalated. It gets added to the agenda of a cross-functional meeting that gets rescheduled twice and then produces a decision to form a working group.

Meanwhile the model sits in staging.

The IT/OT divide gets talked about as a technical challenge, a matter of protocols and network segmentation and data formats. Those things are real. But the deeper divide is organizational. Two teams, built for different purposes, measured on different outcomes, reporting to different leaders, looking at the same plant and seeing completely different problems. IT sees a security perimeter to protect. OT sees uptime to defend. Neither is wrong. Neither is looking at the gap between them.

That gap does not close itself. It closes when someone in the organization is explicitly responsible for closing it, with the authority to make decisions across both teams and the mandate to finish what the project started.

Most industrial AI initiatives are not structured that way. The project has a data science lead and a project manager and a steering committee. It does not have an integration owner. And so the last mile, the mile that requires both teams to move toward each other, stays exactly as wide as it was on day one.

## What Closing the Last Mile Actually Requires

The answer is not a better model. It is not a bigger data science team. It is not another vendor promising that this time the integration will be straightforward.

It is infrastructure. Built deliberately, before the model needs it, designed for the environment it will actually run in.

That means starting with connectivity that meets the plant where it is, not where the vendor deck imagines it to be. Real plants run Modbus, OPC-UA, Siemens S7, proprietary historian formats, and protocols that were old before most current software engineers started their careers. The integration layer has to speak all of it, fluently, without requiring the OT team to replace equipment that is working perfectly and will continue working perfectly for another decade.

It means edge execution that does not depend on the cloud. A prediction that requires a round trip to a cloud inference endpoint is a prediction that fails the moment the network hiccups, which in a manufacturing environment is not a rare event. Intelligence needs to run close to the equipment it is monitoring, locally, with enough resilience to keep functioning when connectivity is degraded and enough security to satisfy the IT team that approved it onto the network.

It means deployment infrastructure that OT teams can actually own. The data scientist who trained the model will not be available at 2 a.m. on a Saturday. The update that fixes the drift in the anomaly detector cannot wait for a change request to clear a two-week approval queue. The people running the plant need to be able to deploy, update, monitor, and roll back AI systems through tooling that respects their domain knowledge without demanding software development skills they were never hired to have.

And it means governance that scales across facilities from the beginning. One plant is a pilot. Twelve plants is a program. The infrastructure that works for one site needs to work for all of them, with consistent versioning, auditable change history, role-based access, and the ability to push a validated update across a fleet without touching each device individually. Organizations that build for one site and retrofit for scale spend years rebuilding what they should have built once.

This is what the proposal compressed into a single box on a slide. Not one problem. Four interconnected ones, each of which can stop a deployment on its own, all of which need to be solved together before the model delivers anything.

## The Mile Is Closable

The last mile problem in industrial AI is not a technology problem waiting for a breakthrough. The technology exists. The manufacturers still stuck in pilot purgatory cannot blame the tools.

It is a prioritization problem. A scoping problem. A decision, made early in every project, about what the work actually is and what it will take to finish it.

The manufacturers generating real operational value from AI today made a different decision. They treated integration as the foundation, not the footnote. They gave the last mile the budget it deserved, the ownership it required, and the infrastructure it needed to hold. And then they built models on top of that foundation and watched them actually run.

That is the sequence. Infrastructure first. Intelligence on top of it. Not the other way around.


# Rethinking Edge AI's Core Orchestration

Every week, another vendor promises "AI on the edge" with glossy demos and yet another dashboard. With FlowFuse customers though, in real factories, the hard part is not the model; it is getting trustworthy, contextual data from all machines to the right AI, at the right time.The real competitive advantage will not come from who has the flashiest model, but from who owns the most reliable connecting tissue between hardware, IT systems, AI agents, and the cloud. This tissue empowers better model accuracy and creates an operational advantage for our customers.

## Why AI Deployments Fail When You Forget About Connectivity

Manufacturers that have already modernized their SCADA or rolled out cloud data lakes, lake houses, and other lake-based properties, are often surprised by how fragile their "AI initiative" becomes once it touches the factory floor.
It is no secret that data is trapped in proprietary PLCs and vendor‑locked SCADA systems, with IT and OT speaking different languages or protocols, and every site maintaining its own patchwork of scripts, gateways, and one‑off integrations.
So what happens? You end up with predictable problems: fragile, one-off connections, IT changes that take half a year, OT changes that have impact on data semantics but go unnoticed and AI projects that look great on paper but never actually run in the real world at scale.
The fundamental issue lies in the deep divide between Information Technology (IT) and Operational Technology (OT). Shop floor teams are often left in the dark about how their data is leveraged by upstream systems, while IT teams struggle to grasp the operational significance underlying the tags and signals they process. This unbridged gap ensures that every AI initiative remains an expensive, custom-built, and inherently brittle undertaking.

## The new stack: AI‑driven edge connectivity

A different architecture is emerging: a unified, future-proof connectivity layer that sits between machines, plant networks, enterprise systems, and AI services. This layer becomes the common ground where IT and OT share a unified model of metrics from assets, other events, and decisions made, ensuring that neither side operates in a vacuum. And I have to say that I’m proud of stating that FlowFuse is at the forefront of this innovation.
In this new paradigm we’re facing, edge devices run a consistent runtime, such as open-source Node‑RED, so that connectivity, transformation, and control logic look the same on every line, every site, and every device family.
AI is then wired directly into this connective tissue via emerging AI standards like Model Context Protocol (MCP) and other native AI nodes, turning the connectivity fabric into a living "nerve system" where agents can safely read, reason, and act on live operational data.

## OK but… what "Future-Proof" means at the edge?

Getting AI, especially large language models (LLMs), to work with the edge isn't just about sticking them onto your existing middleware. It means that AI is embedded into how connectivity is designed, deployed, and operated: models and agents that turn natural‑language descriptions into flows, blueprints that spin up AI chat agents over plant data, and smart suggestions that propose the next node or transformation in context.
The main thing is, it also means that AI agents can run close to the process, on a gateway or industrial PC, using ONNX models for things like spotting defective parts produced, and predicting maintenance and downtime, while the cloud handles the rules, oversight, and updates for the whole fleet.
That split (smart procedures happening at the edge, and the cloud just keeping things organized) is precisely what makes the IT and OT worlds finally click. OT gets to be fast and independent, and IT still has the main view and control over the whole shebang.

## We can finally say goodbye to the IT/OT gap.

FlowFuse was built on a simple belief: industrial teams need one platform that can connect any machine, move data across any protocol, model it in any data platform, and run applications wherever they create the most value.
Both IT and OT get the tools they need, from a wide connectivity suite, to Git integration, and a platform to scale it to hundreds or thousands of different devices.It hooks up to things like PLCs, sensors, and existing Operational Technology (OT) gear using standard protocols like Modbus, OPC UA, and MQTT. This lets you securely stream data to the cloud or your own premises without messing around with complicated firewalls or VPNs. You name it, FlowFuse will connect everything.
At the enterprise level, FlowFuse Cloud provides the central "control tower" to standardize blueprints, ensure version consistency, enforce security policies, and roll out changes across hundreds or thousands of devices with a single action. For an [automotive](https://flowfuse.com/industries/automotive/) and and other manufacturers, that's what keeps AI initiatives across multiple teams standardized and governed instead of turning into a collection of disconnected, one-off solutions.

On top of this connectivity fabric, FlowFuse Expert acts as the AI assistant tuned for industrial teams that will make your life easier as you never imagined.
Grounded via MCP in your actual machines, brokers, and databases, it does much more than chat: it generates live Node‑RED flows, data mappings, dashboards, and even queries that are directly deployable into your environment. Because it connects to both OT sources (PLCs, industrial brokers, historians) and IT systems (data lakes, CMDBs, corporate apps), Expert sees, understands and manages both halves of the map. 100% control of both IT and OT. It translates plant-floor requirements into IT-compliant flows and ensures that security and governance policies are automatically applied to edge configurations. It acts as the structural bridge that finally closes the IT/OT gap.
For OT engineers, this means months‑long projects compress into days or minutes; for IT, it means governance and security controls stay intact even as more of the work shifts closer to the plant floor.

![IT/OT Gap Diagram](https://flowfuse.com/blog/2026/03/images/rethinking-edge-ais-core-orchestration-diagram.png)*IT/OT Gap Diagram*

## From pilots to a scalable "AI nerve system"

Here’s the thing - Most companies will not win by building the most sophisticated individual model, but by institutionalizing a repeatable pattern: connect, contextualize, and act on data at the edge, with AI embedded at every step. If you’ve followed FlowFuse’s history you’ve probably seen how our tagline and our storytelling has been evolving following that logic. “Connect, Collect, Build and Scale with FlowFuse” - This is what this is about.
FlowFuse gives manufacturers that pattern in a form they can actually operate: open‑source at the core with Node‑RED, industrial‑grade features for deployment and observability, and a layer of proprietary Artificial Intelligence that actually understands the realities of plant networks, not just cloud APIs.
The result is a new kind of infrastructure: a persistent "AI nerve system" that spans hardware, IT, AI, and cloud, so that when the next model, vendor, or use case arrives, your connectivity is already in place, deployed and ready to scale. This structural bridge ensures that the historical friction between IT and OT becomes a foundation for collaboration.
If the last decade was about moving workloads to the cloud, the next decade in manufacturing will be about bringing intelligence to the edge. And how this must be done? Safely, consistently, and fast enough to matter.
The companies that treat AI‑driven edge connectivity as a strategic foundation, not a side project, will be the ones that turn experiments into durable competitive advantage.


# Why OPC UA Is Not Replacing Modbus (Yet)

**Everyone in industrial automation agrees: OPC UA is the future. The specs are richer. The security is real. The semantic modeling is genuinely elegant. The industry consortia say so. The whitepapers say so. Vendors say so constantly, especially the ones selling OPC UA stacks.**

**Modbus is still winning.**

Not in keynotes. Not in roadmaps. On the factory floor, in new device datasheets, in RFQs sent out this quarter, Modbus keeps showing up where OPC UA was supposed to have taken over by now.

In January, we wrote about [why Modbus refuses to die](https://flowfuse.com/blog/2026/01/why-modbus-still-exist/), the installed base, the zero-cost implementation, the vendor neutrality, the brutal simplicity that makes it work at 3 AM when nothing else will. That piece hit a nerve. The responses fell into two camps: engineers who nodded along because they live this every day, and architects who pushed back insisting OPC UA adoption is accelerating.

Both camps are right. And that's exactly the problem.

OPC UA isn't losing because it's a bad protocol. It's losing ground in places it should dominate because the gap between what OPC UA *can* do and what most facilities *need* done remains wider than the standards bodies want to admit. Capability isn't the same as adoption. A Ferrari doesn't win in a parking lot.

This isn't a eulogy for OPC UA. It's a sober look at the structural reasons why a protocol with every technical advantage on paper hasn't delivered the displacement its advocates have been predicting for fifteen years, and what would actually need to change for the "yet" in that title to disappear.

## The Promise vs. The Reality

OPC UA was ratified in 2008. That's eighteen years ago. The pitch was compelling: a unified, secure, semantically rich protocol that would finally bring industrial automation into the modern era. The OPC Foundation had vendor backing. The specification was thorough. The vision was clear.

Optimistic predictions followed. The expectation in many quarters was that by the mid-2010s OPC UA would be the dominant machine-level protocol, that Modbus would be a legacy concern by 2020, and that the transition would be essentially complete by the middle of this decade. Those expectations reflected genuine enthusiasm for the protocol's capabilities, not sourced forecasts, but they shaped investment decisions and roadmaps across the industry nonetheless.

None of that happened.

The [Modbus TCP market was valued at [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[1.35]{.mord}[bi]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[i]{.mord.mathnormal}[o]{.mord.mathnormal}[nin]{.mord.mathnormal}[2024]{.mord}[an]{.mord.mathnormal}[d]{.mord.mathnormal}[i]{.mord.mathnormal}[s]{.mord.mathnormal}[p]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[j]{.mord.mathnormal style="margin-right:0.0572em;"}[ec]{.mord.mathnormal}[t]{.mord.mathnormal}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[t]{.mord.mathnormal}[or]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[a]{.mord.mathnormal}[c]{.mord.mathnormal}[h]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 2.55 billion by 2032](https://www.futuremarketreport.com/industry-report/modbus-communication-module-market){rel="&#x22;nofollow&#x22;"}. That isn't legacy drag. That's active investment. New Modbus devices are being designed, manufactured, purchased, and installed in 2026, not as fallback options, but as deliberate first choices. Meanwhile, OPC UA adoption, while genuinely growing, remains concentrated in specific layers of the automation stack: SCADA systems, MES integrations, and IT/OT gateways. At the field device level, Modbus still dominates.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

The gap between expectation and reality isn't a failure of OPC UA's design. The protocol does what it promises. The gap exists because adoption in industrial automation doesn't follow software industry timelines. A protocol doesn't win by being technically superior. It wins by becoming the path of least resistance across every layer of the ecosystem simultaneously: device manufacturers, integrators, maintenance teams, procurement departments, and plant managers all have to move together. That has never happened with OPC UA, and understanding why requires looking at each layer honestly.

## The Complexity Tax Nobody Talks About

OPC UA's biggest competitor isn't Modbus. It's its own specification.

The full OPC UA specification runs across fourteen separate documents. A developer picking up Modbus for the first time can read the entire protocol specification over a weekend and ship a working implementation by Monday. A developer picking up OPC UA faces months of study before they can confidently build something production-ready.

This isn't an unfair criticism. It's the honest cost of doing more. Modbus reads and writes registers. OPC UA models information, manages sessions, handles subscriptions, enforces security policies, and describes data with rich metadata. That capability has a price, paid in implementation time, developer hours, and operational complexity.

For device manufacturers, the math is punishing. A Modbus RTU interface costs roughly [[]{.katex-mathml}[[[]{.strut style="height:0.6444em;"}[5]{.mord}[t]{.mord.mathnormal}[o]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 10 in silicon and a few days of firmware work. A proper OPC UA server, implemented correctly with certificate management, secure channels, and a meaningful information model, requires a capable processor, sufficient memory, and weeks of engineering time. For a sensor company shipping into a price-sensitive market, that difference doesn't show up as a line item in the spec sheet. It shows up in whether the product gets built at all.

Certificate management alone has quietly killed more OPC UA deployments than any technical limitation. Certificates expire. They need to be provisioned, rotated, and trusted across every client and server. In an IT environment with dedicated security teams, this is manageable. In a plant where the automation engineer also handles PLC programming, HMI design, and network troubleshooting, it becomes an ongoing burden that nobody budgeted for and nobody wants to own.

The OPC Foundation recognized this. Companion specifications like OPC UA FX and the Field Level Communications initiative are genuine attempts to bring the protocol closer to the field device layer. Progress is real but slow, and in the meantime, device manufacturers continue defaulting to Modbus because it ships today without a compliance checklist.

Complexity isn't a dealbreaker when the problem demands it. Nobody complains that OPC UA is too complex when it's modeling an entire production line in a SCADA system. The complexity tax only becomes fatal when the problem is simple and a simpler tool is sitting right there, already understood by the team, already working.

## The Skills Gap on the Floor

Protocols don't run themselves. People configure them, troubleshoot them, and fix them at 2 AM when production is down. And the people doing that work in most manufacturing facilities today learned Modbus, not OPC UA.

This isn't a generational complaint. It's a workforce reality with direct operational consequences. The automation technician who has spent fifteen years on a plant floor can read a Modbus register map the way a mechanic reads an engine. They know register 40023 on device 12 is the motor temperature. They know what value triggers an alarm. They know how to pull up a protocol analyzer and spot the problem in minutes.

Ask that same technician to troubleshoot an OPC UA subscription that stopped delivering updates and the confidence evaporates. Is it a certificate issue? A session timeout? A misconfigured sampling interval? A namespace problem? The diagnostic path is longer, the tooling is more complex, and the required knowledge base is fundamentally different. The problem gets escalated, production stays down longer, and the experience gets filed away as evidence that OPC UA is unreliable. The protocol isn't unreliable. The skills to operate it confidently just aren't evenly distributed yet.

Training helps but doesn't solve the structural problem. OPC UA expertise is concentrated in system integrators and automation vendors, not in the maintenance teams who keep plants running day to day. Facilities that have gone deep on OPC UA often find themselves dependent on a small number of people who truly understand the stack, creating exactly the kind of single point of failure that conservative plant managers spend their careers avoiding.

The skills gap will close eventually. Engineering curricula are adding industrial networking content. Younger engineers are entering the field with broader protocol exposure. But eventually in industrial automation means a decade, not a release cycle. The plants being designed today will be maintained by the workforce that exists today, and that workforce is fluent in Modbus in a way it simply isn't in OPC UA yet.

## The Hardware Reality

Modbus RTU was designed in 1979 for the hardware constraints of 1979, worth noting that Modbus TCP, the networked variant that dominates modern installations, didn't arrive until 1999. But the original serial protocol's frugality is what set the expectation, and the ecosystem never abandoned it.

A bare-minimum Modbus RTU slave implementation can run on an 8-bit microcontroller with around 10KB of flash and 1.5KB of RAM. A robust, production-grade implementation with full error handling and edge-case coverage needs more, typically several times that, but the floor is still extremely low compared to almost any alternative. Device manufacturers building sensors, meters, drives, and actuators work within tight BOM constraints where every dollar multiplies across thousands of units. Modbus fits inside the microcontroller they were already using. It adds no hardware cost and minimal firmware complexity.

OPC UA has a different story. A properly implemented OPC UA server needs a real processor capable of running a TCP/IP stack, handling cryptographic operations, and managing runtime memory requirements. Lightweight stacks like open62541 have brought the floor down meaningfully, a constrained OPC UA server can run in under 100KB of flash with careful implementation, but that still represents a significant step up from a Modbus RTU slave, and a full-featured server with a rich information model typically requires several hundred kilobytes of RAM or more.

The OPC Foundation's work on OPC UA FX targets exactly this problem, aiming to bring the protocol down to devices with 256KB of flash and 64KB of RAM. That's genuine progress. It's also still an order of magnitude more resource-intensive than a minimal Modbus implementation on equivalent hardware, and FX-capable devices are only beginning to reach the market.

For established device categories the cost difference compounds quickly. A manufacturer selling thousands of flow meters into water treatment, oil and gas, and chemical processing isn't just buying components. They're buying tooling, certifications, and support infrastructure built around specific hardware platforms. Changing the processor family to support OPC UA means requalifying the entire product, retesting for environmental and EMC compliance, and retraining field service teams. The protocol upgrade triggers a full product redesign, and the business case rarely pencils out when the existing Modbus version is selling reliably into a market that hasn't asked for OPC UA.

Until OPC UA can run comfortably on the same class of hardware Modbus runs on today, at comparable cost and without requiring a platform redesign, the field device market will continue defaulting to Modbus. Not because engineers prefer old technology, but because the economics of building physical hardware into conservative industrial markets leave very little room for protocol idealism.

## Where OPC UA Actually Wins

This isn't a one-sided argument. OPC UA dominates in specific contexts and deserves the credit it gets there. Conflating the two is how bad architecture decisions get made in both directions.

At the SCADA and MES layer, OPC UA is the right answer. When you need to aggregate data from hundreds of heterogeneous devices and feed it into manufacturing execution systems, historian databases, and enterprise analytics platforms, Modbus gives you registers with no context. OPC UA gives you structured, self-describing data with units, ranges, relationships, and meaning baked in. At scale, that semantic layer saves thousands of engineering hours.

Security requirements close the conversation quickly. The moment a system needs to be accessible from outside the plant network, Modbus is disqualified. Not because it can't be hardened with compensating controls, but because its security model is nonexistent by design. OPC UA with TLS encryption, certificate-based authentication, and role-based access control provides the foundation connected industrial systems actually need.

Large equipment builders and machine OEMs increasingly ship with OPC UA as the primary integration interface, for good reason. A packaging line, CNC machining center, or industrial robot is a complex asset with hundreds of meaningful data points. OPC UA companion specifications from industry groups like OMAC, EUROMAP, and the VDMA define standardized information models for entire equipment categories. A machine built to the PackML OPC UA companion spec integrates with any PackML-aware SCADA system without custom mapping work. That interoperability has real commercial value.

Greenfield installations with modern hardware and no legacy constraints are where arguments for Modbus at the field level are weakest. When the BOM can absorb the hardware cost and the team has OPC UA skills, there is no compelling reason to default to a register-based polling protocol from 1979.

The pattern is consistent. OPC UA wins where complexity is justified by the problem, where security is non-negotiable, and where people and hardware resources exist to implement it properly. Those conditions describe the upper layers of the automation stack and modern greenfield projects. They do not yet describe the majority of the field device layer, and that distinction is exactly why the "yet" still belongs in this article's title.

## The Gateway Middle Ground

The industry didn't wait for OPC UA to win. It built a workaround and quietly made it the standard architecture.

Edge gateways now sit at the boundary between the field device layer and everything above it, speaking Modbus to the equipment that has always spoken Modbus and presenting OPC UA, MQTT, or REST to the systems that need structured, secure data. It isn't a temporary fix pending full OPC UA adoption. For most facilities, it is the architecture, and it works well enough that the pressure to replace Modbus at the source has largely evaporated.

This reflects how industrial modernization actually happens. Plants don't replace working equipment to adopt better protocols. They add intelligence at the edge and leave the field devices alone. A Modbus temperature transmitter installed in 2008 keeps transmitting exactly as it always has. The gateway reads its registers, maps the raw value to a properly typed OPC UA node with engineering units and metadata attached, and publishes it upstream. The transmitter never knows the difference. The SCADA system gets clean, contextualized data. Nobody touched the wiring.

The business case is straightforward. Replacing field devices across a large facility to gain native OPC UA at the source costs millions of dollars, requires production downtime, and delivers no improvement in the process being controlled. Adding an edge gateway costs thousands, takes days to deploy, and delivers the same data quality improvement. The ROI calculation ends quickly.

FlowFuse is built around exactly this architecture. Node-RED flows running on the edge read Modbus registers from legacy field devices, apply context and normalization, and publish structured data over MQTT or OPC UA to cloud systems, historians, and analytics platforms. The Modbus equipment keeps running. The modern data infrastructure gets what it needs. The migration happens at the connectivity layer rather than the device layer, which is the only migration path that makes economic sense for most operational facilities.

The gateway middle ground isn't a compromise born of failure. It's a pragmatic recognition that the automation stack has always been heterogeneous and always will be. New protocols don't replace old ones in industrial environments. They get added on top, and the translation layer between them becomes the most important piece of architecture in the building.

## What Would Actually Accelerate OPC UA Adoption

Diagnosing why OPC UA hasn't replaced Modbus is useful. Identifying what would actually change the trajectory is more useful. Not wishlist thinking, but a realistic assessment of the specific friction points that, if addressed, would move the needle in ways that eighteen years of industry advocacy has not.

The most immediate lever is simplification at the implementation level. Device manufacturers make platform decisions years before products ship. Every year that lightweight OPC UA profiles remain incomplete or poorly supported by silicon vendors is another product generation that defaults to Modbus. Finalizing FX profiles, getting them supported in major embedded toolchains, and making reference implementations genuinely production-ready would lower the barrier in ways that specification documents alone cannot.

Certificate management needs to be solved, not documented. The current approach requires automation engineers to operate like IT security professionals in environments where that expertise simply does not exist. Automated certificate lifecycle management, built into OPC UA servers and clients by default, would remove one of the most common reasons deployments stall or fail after going live. Several vendors are working on this. It needs to become a baseline expectation, not a premium feature.

Open source needs to catch up. Modbus has dozens of mature, well-documented stacks across every embedded platform imaginable. OPC UA open source options have improved, open62541 in particular has become a credible foundation, but the ecosystem remains thinner and less consistent in quality and maintenance overall. A developer evaluating both protocols reaches for the option with better community support and lower risk of hitting an undocumented edge case six months before launch. Closing that gap requires sustained investment from the OPC Foundation, major vendors, and the broader industrial open source community.

Interoperability between vendor implementations remains more aspirational than actual. Passing certification does not guarantee seamless interoperability across every feature combination two products might use together. Tightening conformance requirements and expanding interoperability testing infrastructure would give integrators the confidence that OPC UA devices from different manufacturers actually work together reliably, the way Modbus devices have for forty years.

Finally, the total cost of ownership narrative needs to be addressed honestly. OPC UA advocates often present the protocol's benefits without fully accounting for implementation costs, support burden, and skills investment. Facilities that have been oversold and then struggled become skeptics who push back on the next modernization proposal. Engineers trust data and specifics. Give them that.

None of these changes are impossible. Some are already in progress. But progress in industrial standards moves at the pace of the least motivated stakeholder, and the least motivated stakeholders are the ones who have something that works today.

## Conclusion: The "Yet" Has a Deadline, But Nobody Knows It

OPC UA will win. That part isn't in dispute.

The semantic modeling is too useful to ignore forever. The security requirements of connected industrial systems are too real to patch around indefinitely. The demand for self-describing, context-rich data will only grow as analytics, AI, and remote operations become standard expectations. The protocol that delivers all of that is OPC UA, not Modbus.

But winning eventually and winning now are two entirely different things. Fieldbus was supposed to replace 4-20mA. It did, mostly, over thirty years. Industrial Ethernet was supposed to eliminate serial communication. Serial communication is still everywhere. Better technology wins in industrial automation on a timeline set by depreciation schedules, workforce transitions, and the risk tolerance of people whose primary job is keeping production running. Those timelines are measured in decades and they do not compress because a standards body publishes a roadmap.

The "yet" in this article's title has a deadline. The honest answer, based on everything the industry has demonstrated about how protocol transitions actually unfold, is that it is further away than the whitepapers suggest and closer than the Modbus installed base makes it feel.

Plan accordingly. Build the gateway layer. Invest in OPC UA skills before you need them urgently. Specify OPC UA where the problem justifies it today. And stop expecting the field device layer to look like the SCADA layer anytime soon.

Modbus will be there when you get back.


# Cloud, Edge, or Both? How to Choose Your Deployment Before an Outage Does It For You

A production line at a mid-size manufacturer goes dark for 22 minutes. Not because the machines failed. Because the WAN link between the factory and the cloud dropped. The logic controlling the line was hosted in the cloud. Without a connection, it couldn't execute. By the time the link recovered, the shift had lost a batch.

The fix wasn't complicated. The logic needed to run on hardware at the line, not in a datacenter 400 miles away. But by then, the decision had already been made, by default, on day one, when getting something running fast felt more important than getting the architecture right.

FlowFuse supports three deployment models: cloud-hosted instances, Remote Instances running on your own hardware via the Device Agent, and hybrid architectures that combine both. Each model reflects a different set of trade-offs. Here's exactly what each one means and where each one breaks.

![A comparison table of FlowFuse's three deployment models - cloud instances, Remote Instances, and hybrid - across latency, offline capability, setup, cost, failure modes, and best-fit use cases.](https://flowfuse.com/blog/2026/04/images/deployment_models.svg)&#x2A;FlowFuse deployment models at a glance: cloud instances trade connectivity dependence for zero operational overhead; Remote Instances trade hardware ownership for local resilience; hybrid splits workloads across both layers.*

## Cloud instances: fast to start, dependent on connectivity

[Cloud instances](https://flowfuse.com/docs/user/introduction/#creating-a-node-red-instance) run in FlowFuse's managed environment. You build integration and automation logic. FlowFuse handles everything else: container orchestration, uptime monitoring, restarts, scaling, and Node-RED runtime maintenance. You get persistent context storage, environment variable management, role-based access control, and the complete FlowFuse feature set with no infrastructure to own.

**This is the right model when:**

- Your data sources are cloud-based: SaaS APIs, external databases, third-party platforms
- Your workflows don't have hard latency requirements
- No compliance constraint requires processing to stay on-premises
- Your data sources do not include plant-floor equipment on OPC-UA, Modbus, or similar protocols - those require a device on the local network regardless of where your logic runs

It's also the fastest and cheapest starting point. Instances run in minutes, nothing to install, and the operational overhead is near zero. No hardware to procure, no OS to patch, no physical failures to debug. You can migrate workloads to the edge later when the need becomes clear.

**Where it breaks:**

Cloud instances require a persistent connection to execute. If your workflows control or monitor equipment on a factory floor, that link becomes a single point of failure. A 30-second outage doesn't slow things down. It stops execution entirely. That's not recoverable by restarting a service.

Beyond connectivity, latency is the other hard constraint. A cloud round-trip typically adds 20 to 100ms of network overhead, more on congested links. For dashboards and reporting, that's invisible. For a quality inspection workflow issuing a pass/fail signal to a reject gate, it can be the difference between a functional system and one that fails unpredictably under load.

## Remote Instances: resilient by design, owned by you

[Remote Instances](https://flowfuse.com/docs/device-agent/register/) run on hardware you control, whether that's an industrial PC, a gateway at the production line, or a compatible gateway device, via the FlowFuse Device Agent. Workflow execution happens entirely on-device, independent of network state.

Deployment works through snapshots: build and test logic on a development instance, capture a snapshot, then mark it as the target for one or more remote devices. On first deployment, the Device Agent installs Node-RED along with the required dependencies, then runs the snapshot locally. Subsequent snapshot updates replace the running flows without reinstalling the runtime. If the device is offline when you push an update, it receives the snapshot on next reconnect.

**This is the right model when:**

- Latency matters: a quality inspection workflow issuing a pass/fail in under 50ms can't absorb a cloud round-trip
- Connectivity is unreliable: remote sites, offshore infrastructure, or environments where WAN uptime can't be guaranteed
- Compliance requires data processing to stay on-premises

**Where it breaks:**

You own the hardware, and that ownership is non-trivial. Device failures, resource contention, OS-level conflicts, and network interface issues become your responsibility. FlowFuse substantially reduces the operational burden through remote deployment, remote terminal access (Team and Enterprise tiers), centralized health monitoring, and automatic snapshot recovery, but it doesn't eliminate the reality of managing physical machines.

The cost structure also shifts. Cloud instances carry a predictable per-instance fee with no capital outlay. Edge deployments require upfront hardware investment, ongoing maintenance, and staff time to manage device lifecycle. At low device counts, this is manageable. At scale, across dozens of sites and hundreds of devices, it becomes a meaningful operational line item that needs to be planned for, not discovered.

## Hybrid: the architecture most serious deployments land on

Most production industrial deployments use both models. Logic that directly controls or monitors equipment runs at the edge. It is latency-sensitive, connectivity-dependent, and often required by policy to stay on-site. Logic that aggregates, contextualizes, and integrates runs in the cloud: dashboards, ERP and MES connections, cross-site analytics, external alerting.

Here's what that looks like in practice for a multi-site manufacturing operation:

**At each site (edge):** read sensor data via OPC-UA or Modbus, issue control commands to PLCs, run local alarming and anomaly detection, buffer telemetry during connectivity loss.

**In the cloud:** aggregate normalized data across sites, power operations dashboards, connect to ERP and MES systems, write to the historian.

![A hybrid FlowFuse architecture showing Remote Instances running locally at each site via the Device Agent, communicating with
FlowFuse cloud instances over an intermittent WAN link, with store-and-forward buffering, an optional plant network tier, and
cloud-side dashboards, historian, and ERP/MES integration.](https://flowfuse.com/blog/2026/04/images/hybrid-architecture.png)&#x2A;Remote Instances handle local execution and buffering at each site. Cloud instances aggregate, integrate, and manage from a single
interface. The WAN link between them is treated as unreliable by design - not a dependency.*

FlowFuse manages both environments from a single interface. The same snapshot system, DevOps pipelines, and version history work across hosted and Remote Instances.

The technically important piece is how cloud and Remote Instances communicate when connectivity is intermittent. FlowFuse Project Nodes (available on Team and Enterprise tiers) provide native instance-to-instance messaging within the platform. Note that Project Nodes are not a durable message queue - if a device is offline when a message is sent, that message is dropped. The [store-and-forward](https://flowfuse.com/blueprints/getting-started/store-and-forward/) pattern handles this correctly: the edge device writes incoming data to a local SQLite buffer continuously, then flushes to the cloud on reconnect. This is a well-established FlowFuse architecture, but it needs to be designed in explicitly at the device level. It won't emerge on its own.

**Where hybrid breaks:**

Ownership is the failure mode, not complexity. When nobody has explicitly decided who is responsible for each layer, edge and cloud configurations drift apart. One team updates a cloud flow without knowing the Remote Instance depends on it. An incident happens and two people are debugging two environments, each assuming the other owns the problem. The architecture is sound. The gap is organizational, not technical.

## Four questions that determine your architecture

![A decision tree flowchart showing how to choose between Cloud, Edge, and Hybrid FlowFuse deployment models. Starting from data source - plant-floor equipment (OPC-UA, Modbus, PLCs) or cloud APIs - the tree branches through latency requirements, WAN reliability, and hardware ownership capacity to reach one of four outcomes: Edge, Hybrid, Hybrid or Edge, or Cloud. Plant-floor workloads never reach the Cloud outcome.](https://flowfuse.com/blog/2026/04/images/deployment-decision-tree.png)&#x2A;Answer these four questions in order and your architecture becomes a decision, not a guess.*

Start with where your data lives. Plant-floor equipment talking OPC-UA or Modbus has no business depending on a WAN link to execute. Cloud APIs and SaaS platforms do. The data source usually tells you where the compute belongs - and for plant-floor workloads, it rules out cloud-only from the start.

Then ask how much latency you can absorb. A closed-loop control workflow issuing a command to a PLC can't wait for a cloud round-trip. A dashboard aggregating shift data can. If the answer to "what happens if this takes 100ms longer than expected" is anything other than "nothing," you need edge execution.

Connectivity posture comes next. Reliable, high-bandwidth WAN changes the calculus - cloud instances can handle cloud-native data acquisition when the link is solid. But if uptime can't be guaranteed, edge removes the dependency entirely rather than trying to hedge against it.

The last question is operational. Edge deployments require hardware, capital, and people to manage device lifecycle. Cloud instances require none of that. If your team doesn't have the bandwidth to own physical hardware and your workloads are genuinely cloud-native - SaaS integrations, external APIs, cross-system reporting - cloud instances are the right starting point. For plant-floor workloads talking OPC-UA or Modbus, hardware ownership isn't optional. The question isn't whether to run edge, it's how to manage it well.

## Conclusion

Most manufacturers don't discover the wrong deployment architecture in a planning meeting. They discover it when the WAN drops and the line stops.

Getting something running quickly feels more important than getting the architecture right, and that trade-off is invisible until it isn't. Cloud instances are fast to start, easy to manage, and the obvious choice when you're moving quickly and your data sources are accessible over the internet. That's not wrong. It's wrong when the workload depends on a connection that can't be guaranteed, when a 100ms round-trip matters, or when plant-floor protocols require a device on the local network regardless of where your logic runs.

The three models in this post reflect three different sets of trade-offs, not three tiers of sophistication. Cloud is not a stepping stone to edge. Edge is not more serious than cloud. Hybrid is not always better than either. The right model is the one that matches where your data lives, how much latency your workflows can absorb, how reliable your connectivity is, and how much operational ownership your team can take on.

Get those four questions answered before you deploy, not after. The architecture you start with has a way of becoming the architecture you're stuck with.


# How to Connect Industrial Edge Devices to AWS IoT Core

Every industrial site generates data. Getting it to AWS securely is where most teams get stuck.

AWS IoT Core is Amazon's managed service for connecting edge devices to the cloud over MQTT. It handles secure device authentication, message routing, and fan-out to any AWS service in your stack: Lambda, DynamoDB, S3, and more. No broker to manage, no infrastructure to maintain.

FlowFuse is an industrial application platform that connects machines, collects data across any protocol, and builds and deploys industrial applications at scale. In this guide, we'll use FlowFuse as the edge platform to connect to AWS IoT Core.

We'll walk through the full setup from scratch: creating an IoT Thing in AWS, generating X.509 certificates, configuring the right policy, publishing your first message from the edge, and **verifying** it live in the AWS console.

If you're new to MQTT and want to understand how it works before diving in, [this guide covers the fundamentals](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/).

## Prerequisites

Before you begin, make sure you have the following in place:

- A FlowFuse account with a running instance. If you don't have one yet, [sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"}.
- An AWS account with access to the IoT Core service.
- Basic familiarity with the AWS console.

## Step 1: Create an IoT Thing in AWS

A Thing is how AWS IoT Core represents a device. Every connection you make from FlowFuse will be tied to a Thing.

1. Open the [AWS IoT Core console](https://console.aws.amazon.com/iot){rel="&#x22;nofollow&#x22;"}.
2. In the left sidebar go to **Manage > All devices > Things**.
3. Click **Create things**.

!["AWS IoT Core Things page with the Create things button highlighted in the top right corner"](https://flowfuse.com/blog/2026/04/images/aws-console-1-step.png)*AWS IoT Core Things page with Create things button*

4. Select **Create a single thing** and click **Next**.

!["AWS IoT Core setup wizard showing the Create a single thing option selected"](https://flowfuse.com/blog/2026/04/images/aws-console-2-step.png)*AWS IoT Core showing Create a single thing option selected*

5. Give your Thing a name, for example `flowfuse-edge`. This name will be used as the MQTT Client ID later. Leave everything else as default and click **Next**.

!["AWS IoT Core Thing configuration page with flowfuse-edge entered in the Thing name field"](https://flowfuse.com/blog/2026/04/images/aws-console-3-step.png)*AWS IoT Core Thing name field with flowfuse-edge entered*

6. Select **Auto-generate a new certificate** and click **Next**.

!["AWS IoT Core certificate creation page with Auto-generate a new certificate option selected"](https://flowfuse.com/blog/2026/04/images/aws-console-4-step.png)*AWS IoT Core certificate creation page with Auto-generate a new certificate option selected*

7. The next screen asks you to attach a policy. A policy defines what your device is allowed to do: connect, publish, subscribe, or receive. Without one, AWS will reject every connection even if the certificate is valid. Click **Create policy** in the top right. A new tab opens.

!["AWS IoT Core policy attachment screen with the Create policy button visible in the top right"](https://flowfuse.com/blog/2026/04/images/aws-console-5-step.png)*AWS IoT Core policy attachment screen with the Create policy button visible in the top right*

8. Give it a name like `flowfuse-policy`, switch to the **JSON** editor and paste the following:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iot:Connect",
        "iot:Publish",
        "iot:Subscribe",
        "iot:Receive"
      ],
      "Resource": "*"
    }
  ]
}
```

!["AWS IoT Core policy editor in JSON mode with the flowfuse-policy name entered and the permission JSON pasted in"](https://flowfuse.com/blog/2026/04/images/aws-console-6-step.png)*AWS IoT Core policy editor in JSON mode with the flowfuse-policy name entered and the permission JSON pasted in*

> This wildcard policy works for initial setup. In production, replace `*` with specific ARNs for your Thing, topics, and client ID to follow least-privilege principles.

9. Click **Create** and close the tab.
10. Back on the policy attachment screen, refresh the policy list, select `flowfuse-policy`, and click **Create thing**.

!["AWS IoT Core policy attachment screen with flowfuse-policy selected and the Create thing button ready to click"](https://flowfuse.com/blog/2026/04/images/aws-console-7-step.png)*AWS IoT Core policy attachment screen with flowfuse-policy selected and the Create thing button ready to click*

## Step 2: Download Certificates

Before leaving the confirmation screen, download all three certificate files. You cannot retrieve the private key again after this point.

| File                | What it is                                    |
| ------------------- | --------------------------------------------- |
| Device certificate  | Identifies your FlowFuse instance to AWS      |
| Private key         | Paired with the certificate, never share this |
| Root CA certificate | Verifies AWS IoT Core on your side            |

Click **Download** next to each file. Also download the **Amazon Root CA 1** from the link provided on the same page.

!["AWS IoT Core certificate download screen showing the device certificate, private key, and Root CA download buttons"](https://flowfuse.com/blog/2026/04/images/aws-console-8-step.png)*AWS IoT Core certificate download screen showing the device certificate, private key, and Root CA download buttons*

> Keep these files safe. You cannot download the private key again after leaving this page. If you lose it, you will need to create a new certificate.

## Step 3: Find Your AWS IoT Endpoint

Every AWS account has a unique IoT Core endpoint. This is the host address you will use in FlowFuse.

1. In the left sidebar go to **Connect > Domain configurations**.
2. Click on the default domain configuration to open it.
3. Copy the **Endpoint**. It looks like this:

```text
xxxxxxxxxxxxxxx-ats.iot.us-east-1.amazonaws.com
```

Rather than pasting this endpoint directly into the Node-RED broker configuration, store it as a [FlowFuse environment variable](https://flowfuse.com/docs/user/envvar/), for example, `SERVER`. You can then reference it as `${SERVER}` in the Server field. This keeps the endpoint out of your flow JSON and means the same flow snapshot deploys across multiple edge instances pointing at different AWS accounts or regions without any edits.

## Step 4: Configure the MQTT Connection in FlowFuse

With your certificates downloaded and your endpoint copied, open your FlowFuse instance and go to the Node-RED editor.

First, upload your certificates so Node-RED can use them for the TLS handshake.

1. Drag an **mqtt out** node onto the canvas and double-click it to open its settings.
2. Click the pencil icon next to the **Server** field to create a new broker configuration.
3. Set the following on the **Connection** tab:

| Field      | Value                                                 |
| ---------- | ----------------------------------------------------- |
| Server     | `${SERVER}`, set via FlowFuse environment variable    |
| Port       | `8883`                                                |
| Client ID  | `${CLIENT_ID}`, set via FlowFuse environment variable |
| Keep alive | `60`                                                  |

Define `SERVER` and `CLIENT_ID` under your instance's environment settings in FlowFuse. See [FlowFuse Environment Variables](https://flowfuse.com/docs/user/envvar/) for how to configure them. Keeping these values out of the flow JSON means you can deploy the same flow to multiple edge instances, each with its own Thing name and endpoint, without touching the flow itself. The Client ID must still match your Thing name exactly, so each instance gets its own variable value.

4. Check **Enable TLS**. A TLS configuration field appears.
5. Click the &#x2A;*+** icon next to it to add a new TLS config.
6. Upload each of the three certificate files you downloaded in Step 2:

| Field          | File to upload                  |
| -------------- | ------------------------------- |
| Certificate    | Device certificate (`.pem.crt`) |
| Private Key    | Private key (`.pem.key`)        |
| CA Certificate | Amazon Root CA 1 (`.pem`)       |

7. Enable **Verify server certificate**.
8. Click **Update** to save the TLS config, then click **Update** again to save the broker config.

!["Node-RED MQTT broker configuration showing the Connection tab with the AWS IoT endpoint entered, port set to 8883, and Enable TLS checked"](https://flowfuse.com/blog/2026/04/images/Connection-tab.png)*MQTT broker configuration showing Connection tab with endpoint, port 8883, and Enable TLS checked*

!["Node-RED TLS configuration dialog with the device certificate, private key, and CA certificate uploaded and Verify server certificate enabled"](https://flowfuse.com/blog/2026/04/images/tls-config.png)*TLS configuration dialog showing the three certificate upload fields and Verify server certificate enabled*

> AWS IoT Core requires mutual TLS: both sides authenticate each other. Port 8883 is the standard MQTT over TLS port. Connecting on port 1883 without TLS will be rejected.

## Step 5: Build a Flow and Publish Your First Message

With the broker configured, build a simple flow to publish a test message.

For this demo we'll use an **inject** node as the data source. In a real deployment, this would be any node reading live data: an OPC-UA reader, a Modbus poll, a database query, or a sensor feed.

1. Drag an **inject** node onto the canvas and connect it to the **mqtt out** node.
2. Double-click the **inject** node and set the payload to a JSON object, for example:

```json
{ "temperature": 22.5, "unit": "celsius", "source": "flowfuse-edge" }
```

3. Double-click the **mqtt out** node and set the **Topic** to `flowfuse/telemetry`. This is the topic AWS will receive messages on.
4. Click **Done**, then click **Deploy** to apply the flow.

Once deployed, the **mqtt out** node should show a green **connected** status indicator beneath it. If it shows red or is in a reconnecting state, double-check the endpoint, port, client ID, and certificate files.

!["Node-RED canvas showing the mqtt out node configured with the AWS IoT Core endpoint as the server and flowfuse/telemetry as the topic"](https://flowfuse.com/blog/2026/04/images/mqtt-out-aws-endpoint.png)*mqtt out node configuration showing AWS IoT Core Endpoint selected as the server and flowfuse/telemetry set as the topic*

5. Click the button on the **inject** node to trigger a manual publish.

## Step 6: Verify the Message in AWS

Confirm the message arrived in AWS using the built-in MQTT test client.

1. In the AWS IoT Core console, go to **Test > MQTT test client** in the left sidebar.
2. Under **Subscribe to a topic**, enter `flowfuse/telemetry` and click **Subscribe**.
3. Go back to FlowFuse and click the inject button again.
4. The message appears in the AWS test client within seconds.

:video{ariaLabel="AWS IoT Core MQTT test client showing the successfully received JSON payload on the flowfuse/telemetry topic" autoPlay="true" height="619" loop="true" muted="true" playsInline="true" preload="none" width="1280"}*AWS MQTT test client showing the received JSON message on the flowfuse/telemetry topic*

You've successfully connected FlowFuse to AWS IoT Core. Data published from your FlowFuse instance now flows securely into AWS over mutual TLS, ready to be routed to Lambda, DynamoDB, S3, or any other service in your stack via IoT Core rules.

## What's Next

You've got a working edge-to-cloud pipeline. FlowFuse is publishing data. AWS IoT Core is receiving it.

From here, the real work begins: routing that data somewhere useful. In AWS IoT Core, go to **Message Routing > Rules** to forward your `flowfuse/telemetry` messages to DynamoDB for storage, Lambda for processing, or S3 for archiving, no extra infrastructure needed.

On the edge side, swap the inject node for a live data source. An OPC-UA reader, a Modbus poll, a database query. The broker configuration stays the same. Only the source changes.

A few things worth doing before you go to production:

**Tighten your policy.** The wildcard policy from Step 1 is fine for testing. Replace the `*` resource with specific ARNs scoped to your Thing, your topics, and your client ID.

**Rotate certificates on a schedule.** AWS IoT Core supports certificate rotation without downtime. Build that into your operations plan now.

**Monitor connection state.** Add a status node in Node-RED connected to your mqtt out node. If the connection drops, you'll want to know immediately, not when someone notices missing data an hour later.

Industrial data pipelines aren't complex. They just have a lot of small steps that have to be right. You've done the hard part.

For more on how FlowFuse connects PLCs and edge devices, via OPC UA, EtherNet/IP, Siemens S7, and Modbus, to cloud and enterprise systems, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).


# Diagnosing Modbus Degradation: From CRC Errors to TCP Timeouts

Modbus doesn't fail loudly. It drifts, and by the time operators notice, you've already lost the easy fix.

It shows up as slightly stale values, a poll cycle that's somehow three times slower than configured, operators filing tickets about data that "seems off." Never a hard fault. Never a clear cause.

The [previous article](https://flowfuse.com/blog/2026/04/modbus-polling-best-practices/) covered setup mistakes. This one covers what breaks after that: how to read CRC errors and TCP failures correctly, how dead devices silently consume your poll cycle, and what metrics catch degradation before your operators do.

## Serial and TCP Fail Through Different Mechanisms

Modbus RTU and Modbus TCP share the same application protocol. The similarity ends there.

![Comparison of Modbus RTU on RS-485 and Modbus TCP over Ethernet, showing shared serial bus versus network-based communication paths](https://flowfuse.com/blog/2026/04/images/modbus-rtu-and-tcp-physical-layer-image.png)*Comparison of Modbus RTU on RS-485 and Modbus TCP over Ethernet, showing shared serial bus versus network-based communication paths*

They fail through fundamentally different mechanisms, and the most common diagnostic mistake is applying serial troubleshooting logic to a TCP problem, or vice versa. It doesn't just waste time; it produces fixes aimed at the wrong layer entirely.

### RS-485: physical and timing failures

On [RS-485](https://en.wikipedia.org/wiki/RS-485){rel="&#x22;nofollow&#x22;"} serial segments, failure is almost always physical or timing-related.

RS-485 is a shared medium with no collision detection built into the protocol. Modbus RTU relies on a strict master-slave architecture where only the master initiates requests and only one device responds at a time. When the physical layer degrades (damaged cable, missing termination resistor, ground loop between panels, high-current wiring running parallel to the RS-485 pair) the master sees [CRC errors](https://en.wikipedia.org/wiki/Cyclic_redundancy_check){rel="&#x22;nofollow&#x22;"}. The request frame goes out clean. The device receives noise. It either drops the frame silently or sends back something corrupted.

The pattern of where and when errors appear is what makes serial failure diagnosable.

CRC errors distributed across all devices on a segment point to the shared medium: cable damage, missing or doubled termination resistors, ground potential differences between panels. Note that unterminated segments can still produce uneven error distributions. A device at the end of an unterminated run will often show higher CRC error rates than devices at midpoints due to signal reflection, even though the root cause is a shared physical problem. Errors that cluster on one or two specific devices point to those devices: a UART that can't sustain the configured baud rate, a transceiver pulling down bus voltage, or a passive RS-485 converter that doesn't fully meet the electrical spec. Errors that appear at predictable times of day point to induced noise. A 30-meter RS-485 run sharing a cable tray with a 460V motor feed will see induced voltage during motor start transients. Routing away from high-current runs, using shielded twisted pair, and grounding the shield at one end resolves it. Widening the timeout does not.

**Duplicate Slave IDs** are an underappreciated source of corruption. If two devices on the same segment share the same address (a common result after device replacement when the replacement unit ships with a default address already in use) both will respond simultaneously to the same request, corrupting the frame with no physical cause. Before assuming the wiring is at fault, verify that every device address on the segment is unique.

One failure mode that gets far less attention than it deserves: bus contention from a transmit driver that doesn't release the line cleanly.

RS-485 is half-duplex. After sending a request, the master must de-assert its transmit driver before the device can respond. If the driver stays asserted even a few hundred microseconds too long (firmware timing bug, misconfigured enable pin, USB adapter with incorrect turnaround handling) the device's response overlaps with the master's still-active driver. The result is frame corruption on every transaction, every time, and it's indistinguishable from a severely damaged cable.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

A [protocol analyzer](https://en.wikipedia.org/wiki/Protocol_analyzer){rel="&#x22;nofollow&#x22;"} confirms it immediately by showing both signals active simultaneously. Before you pull cable on a segment where every transaction is corrupted, swap the serial adapter or test with a different master. It takes ten minutes and it's right more often than people expect.

### Modbus TCP: connection management and latency

On Modbus TCP, failure is almost always about connection management and latency. There's no shared medium and no electrical noise path. Instead, you get connection-level problems that the polling stack surfaces as device-offline errors, which are easy to misread as device failures when the device is fine.

The most common TCP failure pattern is connection table exhaustion. Modbus TCP devices enforce a hard limit on simultaneous connections at the firmware level, but this limit varies considerably across hardware, from as few as 1 connection on some embedded devices to 16 or more on capable gateway hardware. A common midrange figure for simple PLCs and meters is 4 to 8, but you should check your device's datasheet rather than assume. If your polling stack opens a fresh [TCP connection](https://en.wikipedia.org/wiki/Transmission_Control_Protocol){rel="&#x22;nofollow&#x22;"} for every request rather than maintaining a persistent one, it can fill the connection table within seconds. Once full, the device responds to new connection attempts with a TCP RST. Your stack logs this as the device being offline. The device is operating normally.

Those connection slots release when the idle-connection timeout or the TCP FIN/RST sequence clears them. On most embedded Modbus TCP firmware, this idle timeout is typically 60 to 120 seconds, producing a failure cycle with a consistent interval: errors for roughly 90 seconds, reconnect, fill the table again, repeat.

![Cyclical Modbus TCP connection exhaustion loop showing connection creation, table saturation, TCP resets, and idle timeout recovery](https://flowfuse.com/blog/2026/04/images/modbus-tcp-connection-cycle.png)&#x2A;Cyclical failure pattern caused by connection table exhaustion. Diagnostic signal: failures repeat at a consistent interval.*

That regularity is the diagnostic signal. A device with intermittent hardware faults fails unpredictably. A device whose connection table is being exhausted fails on a clock. If you're seeing periodic offline events with suspiciously consistent timing, check your connection handling before you assume the device is faulty.

**Transaction ID handling** is worth checking in high-concurrency polling configurations. The [Modbus application protocol specification](https://www.modbus.org/file/secure/modbusprotocolspecification.pdf){rel="&#x22;nofollow&#x22;"} defines Transaction IDs to match requests with responses. A polling stack that reuses Transaction IDs before receiving a response to the previous one can match incoming responses to the wrong pending request. When this occurs, the symptom is correct values appearing in the wrong registers. It doesn't show up as an error at all, which makes it unusually difficult to diagnose. If you're seeing values that are off by a plausible amount but never produce error codes, check whether your stack's Transaction ID handling is correct under concurrent load.

The second TCP failure mode that's become more common as industrial networks gain remote access infrastructure is latency on routed network paths pushing transaction times past configured timeouts. This applies to any routed path: site-to-site VPNs, SD-WAN appliances, MPLS links with QoS misconfiguration, or firewalls with deep-packet inspection enabled for industrial protocols. Modbus TCP on a dedicated plant-floor LAN has round-trip latency in single-digit milliseconds. The same configuration over a site-to-site VPN or through a stateful firewall can see 80 to 200ms per transaction. If your timeouts were calculated against a local network and you've since added any routing hops, your effective timeout margin may now be zero under any congestion. The failures are load-dependent: worse during business hours, cleaner overnight, invisible when you run a manual test. The fix is the same as in the last article: measure actual round-trip time under realistic load, then set your timeout to 1.5 to 2x that value.

### The hybrid case: serial-to-Ethernet converters

Most production Modbus installations aren't purely serial or purely TCP. They're RS-485 segments accessed through a serial-to-Ethernet converter with TCP on the network side and RS-485 on the fieldbus side. Both failure modes can exist simultaneously, and the converter adds its own at the boundary.

The most common converter-specific failure is inter-frame gap violation. The [Modbus over Serial Line specification](https://www.modbus.org/file/secure/modbusoverserial.pdf){rel="&#x22;nofollow&#x22;"} requires a minimum 3.5-character silent interval between frames. When concurrent TCP requests arrive simultaneously, a converter that doesn't enforce this gap between queued RS-485 dispatches corrupts the second transaction, even when the cable is perfect and both devices are healthy. The error looks serial. The cause is software. Disabling concurrency and forcing strictly sequential requests to that segment is the fastest confirmation: if errors stop, the converter's queuing was the cause.

Three other failure modes are worth knowing before you chase wiring:

**Buffering latency.** Some converters buffer TCP data before forwarding to RS-485, adding variable latency under load. Failures become load-dependent, mimicking electrical problems. Reducing polling concurrency or adding a small inter-request delay often resolves it without hardware changes.

**Silent connection limits.** Like the devices they front-end, converters enforce connection limits, but some accept the connection and then stop responding rather than refusing it. If timeouts resolve when the polling engine restarts but not otherwise, check for a converter connection limit and configure persistent connection reuse.

**Baud rate or parity mismatch.** After any converter replacement, verify baud rate, parity, and stop bits match the segment. A mismatch corrupts every transaction and is easy to miss if the previous unit's settings weren't documented.

Most converters expose diagnostic statistics through a web UI or Telnet interface. Pull those first. Near-zero serial error counters with nonzero queue depth during failures points to a software queuing problem. Climbing serial error counters points to a real physical fault on the RS-485 side.

## Exception Codes Tell You What Type of Error You're Dealing With

Before treating every failed transaction as a generic timeout or communication fault, check the [Modbus exception code](https://www.modbus.org/file/secure/modbusprotocolspecification.pdf){rel="&#x22;nofollow&#x22;"}. When a device receives a valid request but can't fulfill it, it returns an exception response, and that code is specific enough to redirect your troubleshooting immediately.

The codes you'll encounter most often:

![Modbus exception codes quick reference table showing error codes, meanings, common causes, and first troubleshooting steps](https://flowfuse.com/blog/2026/04/images/exception-table-modbus.png)*Modbus exception codes quick reference table showing error codes, meanings, common causes, and first troubleshooting steps*

**Exception 0x01, Illegal Function**: The device doesn't support the function code you sent. Usually a configuration issue: the polling stack is sending a [function code](https://en.wikipedia.org/wiki/Modbus#Supported_function_codes){rel="&#x22;nofollow&#x22;"} the device firmware doesn't implement.

**Exception 0x02, Illegal Data Address**: The requested register address doesn't exist on this device. This is the most diagnostic exception for register batch problems. If a batch that spans a gap in the device's register map produces this exception, split the batch into two separate reads covering the contiguous ranges.

**Exception 0x03, Illegal Data Value**: The value in a write request is outside the range the device accepts. Relevant for write operations; not typically seen on reads.

**Exception 0x04, Device Failure**: The device received and understood the request but encountered an internal error. This is a device-side problem, not a communication problem. Persistent 0x04 responses on a specific register range warrant checking the device's own diagnostics.

**Exception 0x06, Device Busy**: The device received the request but is temporarily unable to process it. Consistent 0x06 responses mean you're polling faster than the device can handle. Reduce the poll rate for that device or increase the inter-request delay.

Log exception codes as a separate field alongside transaction success/failure. A poll list generating steady 0x02 responses on one device and steady 0x06 on another has two different problems requiring two different fixes.

## Dead Devices Are Draining Your Bus on Every Poll Cycle

There is a problem in almost every Modbus installation that's been running for more than a year: the poll list contains devices that no longer respond, and the master is spending measurable time waiting for them on every single cycle.

Take a serial network with 18 active devices and 3 that are offline. With a 300ms timeout and 2 retries configured, each unresponsive device costs 900ms per cycle. Three offline devices: 2.7 seconds of dead time on every poll cycle. On a bus where each active device transaction takes 70ms, that's the equivalent of roughly 40 active transactions blocked per cycle.

![Modbus poll cycle timeline showing active transactions and dead device waits consuming majority of cycle time](https://flowfuse.com/blog/2026/04/images/modbus-poll-cycle-dead-time.png)&#x2A;Dead devices dominate the poll cycle: \~5.1s actual vs 500ms target, with 2.7s wasted on non-responsive devices.*

If your fast-tier registers are supposed to poll at 500ms, your actual cycle time is now well over three seconds. Data still flows. Values still update. Nothing throws a hard error. The system looks operational while running at a fraction of its designed capacity.

### The runtime fix: backoff

After a device fails a configurable number of consecutive polls, move it out of the normal rotation and into a low-frequency check, once every 60 seconds is a reasonable starting point. When it responds again, restore it to the normal rotation immediately.

Most commercial [SCADA](https://en.wikipedia.org/wiki/SCADA){rel="&#x22;nofollow&#x22;"} systems and industrial gateways support this natively, usually labeled as device backoff, retry holdoff, or failure-state polling interval. In FlowFuse, you implement this explicitly: track a failure counter per device address, suppress it from the main poll rotation when the counter exceeds your threshold, and run it on a separate low-frequency timer.

Backoff is a runtime mitigation, not a solution. Backoff entries should be reviewed quarterly, and anything that hasn't responded in 30 days warrants a direct question: is this device expected to return, or is it permanently gone? If it's gone, remove it. The poll list should reflect the actual field.

## The Metrics That Tell You What's Actually Happening

A device running at 91% transaction success rate isn't failing visibly. Data still flows, values still update. But 9 out of every 100 polls are producing errors. If that 91% has been drifting down from 99% over six weeks, something is changing: a connector degrading, electrical conditions worsening. The window to investigate at low cost is open right now. It closes when the rate hits 70% and starts producing visible data gaps.

The four metrics worth tracking continuously are transaction success rate, response time, segment-level CRC error count, and poll cycle completion time. Your Modbus master has all of this information on every transaction. The only question is whether you're capturing and storing it.

**Transaction success rate** per device, measured as a rolling average over the last 100 polls, is the primary health indicator. Healthy devices run above 99%. A device that's been at 95% for two weeks is telling you something has changed. The distinction between gradual drift and a sudden drop tells you whether you're looking at environmental degradation or a discrete fault.

**Response time** per device, trended over time, is often a leading indicator of developing problems, though not always. Gradual degradation due to worsening electrical conditions, increasing bus load, or a device struggling under heavier firmware load typically shows up as rising response times before timeouts begin. That said, some failure modes are abrupt: a cable that finally breaks, a device that locks up, a switch port that goes down. These jump straight to timeout failures without any response time warning. Treat response time trending as a useful early-warning signal for gradual faults, not as a guarantee that failures will always be preceded by visible latency drift.

**CRC error count** should be tracked at the segment level, not just per device. A simultaneous uptick across all devices on a segment points to a shared-medium change. One device's error rate rising while the others stay flat points to that device specifically.

**Poll cycle completion time** should be stable. A slow upward drift means something is adding latency: response times lengthening, backoff not engaging on newly failed devices, devices added to the rotation without reviewing the impact on total cycle time. A sudden jump usually means a device started timing out that wasn't before. By the time individual device success rates start dropping visibly, cycle time has usually already been warning you for days.

### Putting it into practice

Instrument your polling layer to write a timestamped record on every transaction: device address, function code, success or failure, response time in milliseconds, exception code on failures, and error type (timeout vs. CRC vs. exception response). Write those records to a [time-series store](https://flowfuse.com/node-red/database/). [InfluxDB](https://flowfuse.com/node-red/database/influxdb/) is a common choice for industrial deployments; a [PostgreSQL](https://flowfuse.com/blog/2025/08/getting-started-with-flowfuse-tables/) table with a timestamp index works fine too.

A reasonable retention strategy is to keep raw transaction records for 7 days and roll up to hourly aggregates (per-device success rate, median response time, CRC error count) for 90 days of trend data.

From that raw stream, you want three derived views:

**Per-device rolling success rate** calculated over a sliding window of the last 100 transactions, not a fixed time window. Time windows conflate a healthy device polled infrequently with a struggling device polled every 500ms.

**Per-device response time baseline and deviation**: compute the [median](https://en.wikipedia.org/wiki/Median){rel="&#x22;nofollow&#x22;"} response time per device over the prior 30 days, then flag any device whose current 1-hour median exceeds twice that baseline. Median rather than mean, because a single timeout event skews the mean and obscures the underlying trend.

**Segment-level CRC error rate**: sum CRC failures across all devices sharing a physical segment or converter, and plot that alongside the individual device rates. The divergence between the segment total and any individual device is the diagnostic signal.

In FlowFuse, write a structured record after each Modbus response (device ID, timestamp, success boolean, response time, error type) to a flow targeting your time-series backend.

Build a dashboard that flags any device whose rolling success rate drops below 97%, or whose current response time median exceeds twice its 30-day baseline. Treat these thresholds as starting points. High-noise environments or older legacy devices may warrant looser thresholds; safety-critical systems warrant tighter ones. The goal is to make unplanned degradation visible early, not to produce alerts for every expected variance during a planned network change or device restart.

This is a few hours of implementation work. Done once, it runs indefinitely and gives you the diagnostic foundation that makes every future troubleshooting conversation shorter.

## What You Can Fix Without a Maintenance Window

Changes that affect only the master's behavior (what it polls, how it times out, how it handles failures) can be made at runtime. Changes that affect the physical bus or network topology require the bus to be quiet.

**One change per maintenance window.** If you adjust scan rates, timeout values, register batches, and the device list in the same two-hour window and something breaks, you've lost the ability to know which change caused it. One change per window keeps causality traceable and mistakes recoverable.

With that principle in place:

**Scan rate changes are hot-changeable.** Adding a device to the poll rotation, adjusting a scan interval, moving a register to a different poll tier, disabling a device in persistent backoff: none of these require the serial bus to go quiet. Make the change, watch bus metrics through one full cycle, confirm the outcome.

**Timeout values can be adjusted per device without touching anything else.** If a specific device's response time has increased and is now generating intermittent timeouts, raise that device's timeout to match its current behavior plus a real margin. Keep the change narrow: one device, one parameter, one observable outcome.

**Register batch restructuring can be done incrementally.** If a batch spans a gap in the register map and produces exception 0x02 responses, split it into two clean batches covering the contiguous ranges. The [Modbus data model](https://www.ni.com/en/shop/seamlessly-connect-to-third-party-devices-and-supervisory-system/the-modbus-protocol-in-depth.html){rel="&#x22;nofollow&#x22;"} defines four distinct address spaces (coils, discrete inputs, input registers, holding registers) and batches must not cross between them.

Physical changes to the RS-485 segment (wiring, termination, baud rate or parity settings, converter replacement) require the bus to be quiet. So does any change to network topology on the TCP side. Everything else: don't wait.

## Where This Leaves You

What keeps a Modbus installation stable for years is mostly mundane: a poll list reviewed quarterly against the actual field, scan rates tiered with the reasoning written down, timeouts calculated from measured device response times rather than defaults, and per-device success rates visible on a dashboard that someone checks regularly enough to catch drift before it becomes failure. None of it is sophisticated. All of it requires treating the Modbus layer as something that needs ongoing maintenance, not a configuration artifact from the last integration project.

If you've worked through both parts and the installation is still misbehaving, you're likely past what configuration review can resolve. Power quality on the RS-485 segment, a device firmware bug producing malformed responses on specific register ranges, or a network infrastructure change that introduced unexpected latency: these are real causes that look like everything else until you rule everything else out. A [protocol capture](https://en.wikipedia.org/wiki/Packet_analyzer){rel="&#x22;nofollow&#x22;"} on the wire during an active failure event will tell you more in twenty minutes than another hour of configuration review. At that point, that's where to start.

For a guide to connecting Modbus PLCs, alongside OPC UA, EtherNet/IP, and Siemens S7, to MQTT, cloud, and enterprise systems, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).


# FlowFuse 2.29: FlowFuse Expert Comes to Self-Hosted Enterprise

FlowFuse 2.29 gives teams more control over how flows move through their stack, makes it easier to understand what changed between versions, and brings FlowFuse Expert to self-hosted enterprise customers.

## FlowFuse Expert, Available to More Teams and More Capable

*FlowFuse Expert is our integrated AI assistant, one consistent surface across the FlowFuse website, platform, and immersive Node-RED editor for troubleshooting, building, and getting targeted help.*

### Self-Hosted Enterprise

FlowFuse Expert was previously only available to cloud customers. Self-hosted enterprise teams had no equivalent surface for in-context troubleshooting and guidance.

Expert is now available for self-hosted enterprise FlowFuse instances. Your team gets the same contextual guidance and targeted help as cloud customers, with your operational data staying on your own infrastructure.

[Contact us](https://flowfuse.com/contact-us/?subject=FlowFuse%20Expert%20for%20Self-Hosted) to enable Expert on your self-hosted environment.

### Take Action Directly from Expert Responses

Expert responses previously surfaced information and suggestions. Acting on them, importing a flow, selecting relevant nodes, opening a new tab, required switching out of the conversation and doing it manually.

Expert responses can now include clickable action links. Click one and Expert performs the action directly in your editor: opening a new flow tab, selecting the nodes it just mentioned, or importing a flow from the conversation.

:video{ariaLabel="Expert action links demo" autoPlay="true" height="886" loop="true" muted="true" playsInline="true" preload="none" style="border: 2px solid #E5E7EB;" width="1400"}

Expert responses can now act on your behalf, click a link and Expert opens a tab, selects nodes, or imports a flow directly in your editor.

**Coming next:** spinning up Node-RED instances directly from Expert, letting you go from idea to running flow without leaving the chat.

::div{.ff-related-changelogs}
Changelog: [FlowFuse expert action links](https://flowfuse.com/changelog/2026/04/expert-action-links/)
::

### In practice

- You act on Expert suggestions in one click instead of manually applying them
- You stay in the conversation while Expert works in your editor

## More Visibility and Control Across Your Deployment Workflow

Managing flows across environments means tracking what changed, when, and by whom. When tooling gaps introduce friction here, or leave your version control workflow fragmented, they slow teams down at exactly the wrong moment.

### Azure DevOps Git Integration

FlowFuse's GitOps support previously required GitHub. Teams standardised on Azure DevOps had no native way to include Node-RED flows in their existing version control workflow.

FlowFuse 2.29 adds Azure DevOps as a supported Git provider. You can now push and pull snapshots directly from Azure DevOps repositories using Personal Access Tokens, configured under Team Settings → Integrations.

### In practice

- You connect Azure DevOps repos alongside or instead of GitHub
- Your Node-RED flows participate in the same version control workflow as the rest of your stack
- You authenticate with Azure Personal Access Tokens, with no secondary tooling required

### See Exactly What Changed in a Snapshot

FlowFuse's snapshot comparison view showed flows side by side, but the visual alone doesn't always tell the whole story. You could see that a node was different, but not which specific property changed. When a function node's code changed, you couldn't identify which lines were different without manually diffing two code blocks outside of FlowFuse.

![Snapshot diff demo](https://flowfuse.com/blog/2026/04/images/snapshot-comparision-view-2.29.png){dataZoomable="" style="border: 2px solid #E5E7EB;"}

The compare dialog now shows exactly which properties changed and highlights line-level differences in function code, templates, and JSON, no manual diffing required.

The compare dialog now includes a property-level diff sidebar: structural property changes old to new at a glance, and git-style line diffs for function code, template HTML, and JSON. A navigation bar steps through every changed, added, or deleted node with arrow key shortcuts. The canvas highlights and scrolls to the current node as you navigate.

### In practice

- You review what changed between dev and production without leaving FlowFuse
- You validate a teammate's update at the property level, not just the node level
- You debug why a flow changed after a deploy with the same tooling you use to promote it

## What else is new?

- **Expert opens by default**: FlowFuse Expert now opens automatically when you visit the editor for the first time. If you close it, that preference is remembered across browser sessions.
- **Embedded editor tab titles**: Hosted and Remote Instance editor tabs now show the actual Node-RED flow name rather than a generic title.
- **Instance URL env var**: Hosted Node-RED instances now expose an `FF_INSTANCE_URL` environment variable containing the instance's URL (default or custom hostname). Useful for flows that need to know their own address, like webhook callbacks or OAuth redirects.
- **Blueprint markdown rendering**: Blueprint descriptions now support markdown rendering, so formatting like headers and lists display as intended.

### Fixes

- **MCP server discoverability**: Older MCP servers that were registered on your instances were not showing up in Expert Insights mode. All registered MCP servers are now discoverable again.
- **Snapshot detail in the immersive editor**: Reviewing a snapshot from inside the immersive editor now opens it in a modal, so you can inspect snapshots without leaving the editor.
- **Developer Mode tab restored in the immersive editor**: The Developer Mode tab is back in the immersive editor drawer, letting you toggle Auto Snapshots and create snapshots without opening a second window.

### Node-RED

[Node-RED 4.1.8](https://github.com/node-red/node-red/releases/tag/4.1.8){rel="&#x22;nofollow&#x22;"} is now available as a stack option in FlowFuse. Highlights include function node tab badges (see at a glance which tabs contain code), theme plugin overrides for settings and menu options, configurable palette categories via theme plugins, and show-first/last-tab keyboard actions.

Looking ahead, [Node-RED 5.0](https://nodered.org/blog/2025/12/03/node-red-roadmap-to-5){rel="&#x22;nofollow&#x22;"} is in beta. It's a modernization and UI re-architecture that readies Node-RED for better AI-guided development and brings more clarity to manual editing. FlowFuse will ship 5.0 once it reaches stable release.

---

For detailed breakdowns of each feature with additional visuals, visit our [changelog](https://flowfuse.com/changelog/). For the complete list of everything included in FlowFuse 2.29, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases){rel="&#x22;nofollow&#x22;"}.

If something in this release improves your workflow, or if there is still friction we can remove, please [share feedback or report issues regarding this release](mailto\:contact@flowfuse.com?subject=Feedback%20on%202.29) to us.


# IT vs. OT: Who Actually Owns the Edge?

Ask IT who owns the edge. They'll say they do. Ask OT the same question. Same answer. That's the problem.

Both teams are wrong, and both teams are right. IT has the infrastructure discipline. OT has the operational knowledge. Neither has both, and the edge demands both. Until that tension gets resolved, deployments stall, workarounds multiply, and the line goes down at the worst possible moment while everyone figures out whose problem it is.

Edge ownership is genuinely uncomfortable to assign. It sits at the intersection of two teams with different mandates, different definitions of risk, and different answers to the same question: what does reliable actually mean here?

IT measures reliability in uptime percentages and patch cycles. OT measures it in whether the line ran today. Those are not the same thing, and pretending they are is where most edge governance conversations go wrong.

When the gateway goes down mid-shift and production stops, the finger points both ways simultaneously. IT says OT bypassed change management. OT says IT pushed an update without understanding what it would touch. Both are describing something that actually happened. Neither is wrong. And the line is still down.

That is not a technology problem. It is an ownership problem, and it is the single most expensive undocumented decision sitting inside your operation right now.

## IT can't own it alone

IT has the tools. The security frameworks, the patch management systems, the monitoring dashboards, the change control processes built over decades of managing distributed infrastructure. On paper, the edge is just another set of networked devices. IT knows how to manage networked devices.

The problem is what those devices are connected to.

A patch cycle that makes perfect sense for a corporate laptop makes no sense for a controller managing a filling line running three shifts. A maintenance window that costs IT nothing costs operations everything if it lands at the wrong moment. A security policy that locks down remote access protects the network and blinds the engineer who needs to diagnose a fault before the next shift starts.

IT optimizes for the network. That is their job and they are right to do it. But the edge isn't just network infrastructure. It's network infrastructure with a production line on the other end, and the consequences of getting it wrong are measured in stopped lines, missed shipments, and conversations with plant managers that nobody wants to have.

IT doesn't feel those consequences directly. OT does. And that asymmetry is why handing the edge entirely to IT always creates friction, always generates workarounds, and always ends with OT quietly building something on the side that IT doesn't know about.

## OT can't own it alone

OT understands the process. The equipment, the tolerances, the consequences of a bad decision at the wrong moment. They know which devices are critical, which lines can absorb disruption and which cannot, what reliable actually means when a machine has been running the same cycle for eleven years.

That knowledge is irreplaceable. It is also dangerously concentrated.

Most OT teams are not resourced to manage networked infrastructure at scale. They were built to keep production running, not to maintain firmware inventories, respond to CVEs, or architect secure remote access across fifty edge devices spread across three facilities. One engineer built the system. That engineer knows it. Nobody else does.

This works until it doesn't. A device gets compromised because nobody was tracking the patch state. A configuration change breaks something upstream and the only person who understands the dependency is on leave. A new facility comes online and the same system gets replicated by hand, slightly differently each time, by someone working from memory.

OT ownership without IT discipline doesn't produce reliable infrastructure. It produces infrastructure that runs reliably right up until the moment it doesn't, and when it fails, it fails in ways that are hard to diagnose, hard to fix, and impossible to hand off cleanly.

The edge needs OT's knowledge of consequence. It also needs IT's discipline around management. Neither team has both. That is not a criticism of either. It is just the reality of how these organizations were built, and what the edge actually demands.

## What actually happens when neither owns it

Nobody makes a decision to leave the edge ungoverned. It happens gradually, through a series of reasonable choices made by people under pressure.

A project needs to move. Someone from OT builds the integration because they understand the equipment. IT isn't involved because the timeline doesn't allow for a full security review. The deployment goes live. It works. Everyone moves on to the next thing.

Six months later that device is running firmware nobody has updated. The engineer who built it has moved to a different project. The documentation lives in a shared drive folder that hasn't been opened since the go-live. When something breaks, the first hour is spent figuring out what the system even does.

Multiply that across five deployments. Ten. Twenty. Facilities added over years, each one slightly different, each one carrying the assumptions and shortcuts of whoever built it at the time. No common tooling. No shared visibility. No way to answer the question that every operations director eventually asks: what is actually running out there, and is it safe?

This is not a hypothetical. It is the current state of edge infrastructure in most manufacturing organizations, not because people were negligent, but because the ownership question was never answered clearly enough to prevent it.

The cost is not just operational. It is strategic. Every ungoverned device is a constraint on what you can do next. You cannot scale what you cannot see. You cannot secure what nobody owns. And you cannot build the next layer of capability on top of infrastructure that exists, in any meaningful sense, only in one person's memory.

## What shared ownership actually looks like

Shared ownership is not a committee. It is not a cross-functional task force that meets monthly and produces a governance document nobody reads. Those things exist in organizations where the ownership question got escalated instead of answered.

Real shared ownership starts with accepting that IT and OT are not fighting over the same thing. They have different jobs at the edge and the jobs are genuinely complementary. IT owns the infrastructure layer: security, patch state, remote access, monitoring, compliance. OT owns the operational layer: what runs, when it runs, what it touches, what the consequences of changing it are. The seam between those two layers is where decisions get made together, not where one team overrules the other.

In practice this means a few concrete things.

Change management that understands production schedules. Not IT's change window imposed on OT's environment, but a shared process that routes decisions through the people who feel the consequences of getting them wrong.

Visibility that both sides can read. IT needs to know patch state, connection status, security posture. OT needs to know what changed, when, and whether it affected anything downstream. These are not the same dashboard but they need to come from the same system.

Clear escalation lines for the decisions that genuinely require both. Not every edge decision needs a joint conversation. Most don't. But the ones that do, such as a forced update on a critical controller, a new device on the production network, or a remote access policy that affects fault response time, need a process that doesn't depend on whoever happens to be in the room that day.

None of this requires a reorganization. It requires an honest conversation about where the current model breaks down and what it would take to fix the specific breaks, not the whole system at once.

## The edge needs a platform both sides can trust

Most of the governance problems described above are made worse by tooling that was built for one side of the organization and tolerated by the other.

IT deploys a device management platform designed for corporate infrastructure. OT works around it because it doesn't understand production constraints. OT builds flows in a standalone [Node-RED](https://flowfuse.com/node-red/) instance nobody else can see. IT flags it as an unmanaged asset. Both are doing the rational thing given what they have.

The tooling shapes the behavior. If the platform forces a choice between IT visibility and OT autonomy, organizations will keep making that choice badly, sometimes defaulting to IT control and generating workarounds, sometimes defaulting to OT autonomy and generating risk.

What the edge actually needs is a platform that doesn't force that choice. One where IT can see patch state, manage access, enforce security policy, and audit what changed and when, without touching the operational logic that OT built and depends on. And where OT can deploy, modify, and operate flows on their own schedule, within guardrails that IT set and both sides agreed to.

That is what [FlowFuse](https://flowfuse.com) is built for. Node-RED runs on the factory floor under OT's operational constraints. FlowFuse wraps it with the management layer IT requires: [role-based access control](https://flowfuse.com/docs/user/role-based-access-control/), [DevOps pipelines](https://flowfuse.com/docs/user/devops-pipelines/), [snapshots](https://flowfuse.com/docs/user/snapshots/), [audit trails](https://flowfuse.com/docs/user/logs/), [centralized visibility](https://flowfuse.com/blog/2024/10/managing-node-red-instances-in-centralize-platfrom/) across every device in the fleet. Neither team has to compromise what they actually need. The seam gets managed instead of argued over.

The ownership question doesn't go away. But with the right platform underneath it, it becomes a conversation both sides can have without the tooling making it harder.


# Most Modbus Polling Setups Are Wrong: Here's How to Fix Yours

**Modbus polling looks simple. It is simple. That's the problem.**

You set a scan rate, point it at a device, start reading registers, and data flows. It works. So nobody looks at it again.

Except "working" and "working correctly" are different things in Modbus polling, and the gap between them is where most engineers quietly lose data, burn network bandwidth, and cause the intermittent device dropouts that get blamed on hardware.

The mistakes aren't exotic. They're the same ones across almost every installation: polling everything at the same rate, ignoring timeouts, stacking too many registers into single requests, or hammering slow devices with back-to-back queries they were never designed to handle. None of these are obvious from the outside because Modbus doesn't complain. It just silently drops a frame or lets the device go quiet, and your polling stack fills in the gap by returning the last successfully read value, making the problem invisible until someone notices the data has stopped changing.

This article isn't about the basics of how Modbus works. If you need that, start [here](https://flowfuse.com/blog/2026/01/why-modbus-still-exist/). This is about the specific configuration decisions that separate a polling setup that stays stable for years from one that causes problems at the worst possible time. It covers the three mistakes made at commissioning. The next article covers what happens after the system is running.

## The Myth of the Universal Scan Rate

Every Modbus polling setup has a scan rate. Most setups have one scan rate. That's where the trouble starts.

The default in most SCADA systems, Node-RED flows, and industrial gateways is to configure a single polling interval and apply it uniformly across every register on every device. 500ms. 1 second. 5 seconds. Pick a number, apply it everywhere, call it done. It's the configuration decision that takes thirty seconds and then gets inherited by every engineer who touches the system after you.

The problem isn't the interval you picked. The problem is that one interval is the wrong answer for almost every real installation.

Consider what's actually living in a typical Modbus device: a temperature reading that changes slowly over minutes, a motor running-hours counter that increments once per hour, an alarm status bit that can flip in under a second, and a setpoint register that only changes when an operator touches it. These are not the same kind of data. Polling all of them at the same rate means you've optimized for nothing and made tradeoffs you never consciously chose.

**Polling too fast punishes your bus and your devices.** RS-485 is a shared medium. Every query you send to one device occupies the bus for the duration of that transaction: the request frame, the device processing time, and the response frame. On a 9600 baud network with 20 devices, a 500ms scan rate across all of them isn't 500ms per device. It's a queue. If each transaction takes 50ms, your 20-device poll cycle takes a full second to complete, which means the data you're getting from device 20 is already a second stale before you even start the next cycle. Slow sensors get polled ten times before their value could possibly have changed. Fast-changing signals still get missed.

**Polling too slow loses events.** A motor fault flag that goes high for 800ms and then clears on its own will be completely invisible to a 1-second polling interval. Not occasionally invisible, reliably invisible. The bit flipped, the motor logged an internal fault, the fault self-cleared, and your polling cycle saw nothing but normal values on both sides of the event. You'll hear about that fault months later when the motor fails completely and maintenance pulls the device logs.

:cta-image{alt="Aperia Technologies stopped reprogramming controllers station by station with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/aperia-book-demo.png"}

The fix isn't complicated, but it requires making a deliberate decision you've probably been deferring: &#x2A;*categorize your data by how fast it actually changes, then assign poll rates to match.**

A practical starting framework for most industrial installations:

- **Fast (100 to 500ms):** Alarm and fault status bits, safety interlocks, process variables driving closed-loop control. These are registers where a missed state change has operational or safety consequences.
- **Normal (1 to 5 seconds):** Running process values such as flow rates, pressures, temperatures, and current draws. These change continuously but not instantaneously. A 2-second poll captures meaningful trends without hammering the bus.
- **Slow (30 seconds to 5 minutes):** Accumulated counters, runtime hours, setpoints, device configuration registers. These either change by operator action only or accumulate so slowly that polling them fast is pure waste.
- **On-demand only:** Nameplate data, firmware versions, serial numbers, calibration constants. Poll once at startup and cache. Never poll again during normal operation.

This tiered approach does something important beyond just reducing bus load: it aligns your polling architecture with the operational reality of the process you're monitoring. An engineer reading your configuration can look at the scan rates and immediately understand which signals the system treats as critical and which it treats as background. That's information that doesn't exist in a flat 1-second-everything setup.

The pushback you'll hear is that tiered polling is harder to configure and harder to document. That's true. A single scan rate is simple to explain and simple to hand off. But simple to configure and correct are different things, and a polling architecture that silently misses events or saturates a serial bus isn't simple. It's a problem that hasn't surfaced yet.

One more thing worth stating plainly: your scan rate has to account for the device's actual response capability, not just the rate you want data. Some field devices, including older PLCs, low-cost sensors, and anything running on an 8-bit microcontroller with slow UART handling, need 50 to 150ms just to process a request and formulate a response. If your fast-tier scan rate is 100ms and your device needs 120ms to respond, you're not getting 100ms data. You're getting collisions, timeouts, and a maintenance headache. Measure actual device response times before setting your fast-tier interval. The device datasheet will give you a starting point; a protocol analyzer will give you the truth.

## How Timeout Misconfiguration Kills Stability

Timeouts are the most quietly destructive configuration parameter in a Modbus polling setup. Set them wrong and your system doesn't fail loudly. It just becomes unreliable in ways that are genuinely difficult to trace back to the source.

Here's what actually happens when a Modbus master sends a request: it waits. There's no explicit acknowledgment mechanism beyond the response itself, no "I got your request, give me a moment." The master sends the frame and sits in silence until either a valid response arrives or the timeout expires. What happens after that expiry, whether retry, skip, error, or log, is entirely up to whatever stack you're using. Modbus itself has no opinion.

That silence is where most setups go wrong.

**The too-tight timeout problem**

The instinct when configuring timeouts is to set them aggressively short. Short timeouts mean fast failure detection. Fast failure detection means the polling cycle doesn't stall when a device goes quiet. That logic is correct in theory and damaging in practice.

The issue is that "device response time" isn't a fixed number. It varies. A device that normally responds in 40ms might take 90ms when its processor is busy handling an internal alarm condition. It might take 130ms during a firmware-driven self-diagnostic that runs every few hours. It will almost certainly take longer under electrical noise conditions where the first frame gets corrupted and the device is waiting for a valid request that never arrives cleanly.

If your timeout is 100ms and your device occasionally needs 130ms, you get a spurious timeout. The master marks the request as failed and moves on to the next poll. The device, meanwhile, finishes processing and transmits a perfectly valid response, but the master has already abandoned that transaction. Those late bytes now sit in the master's receive buffer. When the next legitimate response arrives, those orphaned bytes are still there, and the master's parser reads a combined stream of garbage from both, corrupting the next response and producing another error. On RS-485 networks this compounds faster than on TCP because there's no underlying transport layer to absorb or sequence the damage. One misconfigured timeout on one device can introduce intermittent errors across the entire bus segment.

**Calculating a timeout that actually makes sense**

Timeout values aren't arbitrary. They have a floor set by physics and firmware, and your configured value needs to sit above that floor with enough margin to absorb real-world variation. The floor has three components:

*Transmission time* is how long it takes to physically clock the request frame onto the wire. At 9600 baud, each bit takes roughly 104 microseconds. A typical Modbus RTU request runs 8 bytes, which at 11 bits per byte (1 start bit, 8 data bits, 1 stop bit, plus parity) comes to roughly 88 bits, so about 9ms just to transmit at 9600 baud. At 19200 baud it halves. At 115200 baud it becomes negligible.

*Device processing time* is how long the device takes to receive the complete request, validate the CRC, look up the register values, and build the response. Budget 20 to 50ms for most industrial devices, 50 to 100ms for older PLCs and slower microcontrollers, and up to 150ms for devices known to have slow UART handling.

*Response transmission time* is the time to clock the response frame back. A read response for 10 registers runs about 25 bytes, roughly 25ms at 9600 baud.

Add those up for a 9600 baud network reading 10 registers from a moderately slow device: 8ms transmit + 75ms processing + 25ms response = 108ms minimum. A 100ms timeout fails this transaction every time. A 150ms timeout passes it usually but fails it when the device is under load. A 250ms timeout gives you real margin.

The general rule: calculate your floor, then multiply by 1.5 to 2 as a stability margin. That margin isn't wasted time. It's the difference between a system that runs cleanly for years and one that produces unexplained errors every few days. For Modbus TCP the math changes but the principle doesn't. TCP eliminates the baud rate component, but device processing time still dominates, and now you've added network latency and TCP stack overhead on both ends. A 500ms timeout is reasonable for most TCP deployments. Anything under 200ms can lead to intermittent failures depending on device response time and network conditions.

**The too-loose timeout problem**

The other failure mode gets less attention because it doesn't cause errors. It causes slowness, which is easier to ignore.

A timeout set at 5 seconds on a serial network means every unresponsive device costs you 5 seconds of dead time per poll cycle. If you have 3 offline devices on a 20-device bus, you're burning 15 seconds per cycle waiting for responses that will never come. This is particularly common in systems that were built to poll 20 devices and are now down to 12 because equipment was removed without anyone updating the polling configuration. The device list grows stale, the timeouts fire on phantom addresses, and the cycle time balloons silently.

**Retries: the configuration that multiplies your problems**

Most Modbus stacks let you configure a retry count. The default in many tools is 3. That sounds conservative. It isn't.

Three retries at a 250ms timeout means a single unresponsive device costs you 1 full second per poll cycle before the master gives up and moves on. On a fast-tier signal you're trying to poll at 500ms, one bad device makes your entire fast-tier effectively useless. The right retry count for most industrial installations is 1, sometimes 2. A single retry catches genuine transient errors. Multiple retries on a serial bus create the congestion that causes the errors you're trying to catch. Set your timeout correctly and you need fewer retries. Set your timeout too tight and no retry count will save you.

## Register Batching: Do It Right or Don't Do It

Register batching is the Modbus optimization that every engineer knows about and most engineers get half right. The concept is simple: instead of sending ten separate read requests for ten individual registers, send one request that reads a contiguous block covering all ten. One transaction instead of ten. One round-trip instead of ten. The bus thanks you.

What gets left out of that explanation is the word *contiguous*, and that omission is where batching goes from optimization to problem.

Every Modbus transaction carries fixed overhead regardless of how many registers you're reading. On a 9600 baud RS-485 network, a single-register read transaction takes roughly 10ms in transmission time alone. Reading 50 registers one at a time: potentially 500ms or more in wire time. Reading those same 50 registers in one batched request: one transaction, maybe 30ms. The efficiency difference isn't marginal. It's an order of magnitude.

The advice to batch your reads is correct. The problem is what happens when engineers apply it without reading the register map first.

**The contiguous register requirement**

Modbus function code 03 reads a starting address plus a quantity, that block, sequentially, with no gaps. If you want registers 40001, 40050, and 40099, you cannot batch those in one request. You need three separate requests, or you read the entire range from 40001 to 40099 and discard the 96 registers you don't need.

That second option is where the mistake happens. Engineers conclude that reading a larger block is always better than reading a smaller one. So they batch aggressively: read registers 40001 through 40200 in one shot and parse out the handful of values they actually need.

This works fine until you hit a gap in the register map containing a reserved or unimplemented register. Modbus devices are not required to return valid data for registers that aren't defined in their implementation. Many return zero. A significant number return an exception response, Modbus error code 02 (illegal data address), which terminates the entire read request and returns nothing. Your aggressive batch that was supposed to read 50 useful values returns an exception because register 40047 isn't implemented on this firmware version, and now you have no data from any of those 50 registers until the next poll cycle.

This is one of the most common sources of intermittent data gaps in Modbus installations. The polling works fine during commissioning on a bench setup, then produces sporadic errors in the field when devices from a different firmware revision have slightly different register implementations.

**How to batch correctly**

Start with the device register map from the vendor documentation. Read it to understand the layout, not just to find the registers you want. Where are the gaps? Which registers are reserved? Which are only valid in certain operating modes?

Then group registers into contiguous or near-contiguous clusters where the gap between any two consecutive needed registers is small, using 10 registers or fewer as a starting heuristic. Each cluster becomes one batch request. Clusters separated by larger gaps become separate requests.

For a device where you need registers 40001–40010, 40015–40020, and 40100–40110: the first two clusters are close enough that one request covering 40001 to 40020, reading 20 registers and wasting 5, is acceptable. The third cluster at 40100 is 80 registers away. That's a separate request.

**Batching and your poll rate tiers**

If your fast-tier registers are scattered through the same address space as your slow-tier registers, batching them together means polling slow registers at your fast rate, which defeats the tiering entirely. Design your batches per tier. Fast-tier batch: only fast-tier registers, polled at your fast interval. Slow-tier batch: only slow-tier registers, polled at your slow interval. If registers from different tiers happen to be contiguous in the address map, resist the temptation to merge them. A slightly less efficient batch that preserves your polling architecture is better than an efficient batch that collapses your scan rate strategy.

**A note on writes**

Function code 16 allows batching writes the same way FC03 batches reads. But write batching carries a risk read batching doesn't: a single malformed batch can corrupt multiple independent settings simultaneously. For writes, err toward smaller, focused transactions even at the cost of bus efficiency. When you're writing to a live device controlling an active process, the reliability argument outweighs the performance argument.

## Where This Leaves You

The three problems this article covers, scan rate uniformity, timeout miscalculation, and aggressive batching, share a common trait: none of them produce an immediate, obvious failure. They produce a system that works, mostly, until it doesn't. The errors they cause get blamed on hardware, on electrical noise, on the device vendor. The actual cause sits in a configuration file that nobody has looked at since commissioning.

The fix for all three is the same kind of work: deliberate, once, documented. Tier your scan rates to match how fast your data actually changes. Calculate your timeouts from the physics of your network rather than accepting defaults. Read the register map before you batch. None of this takes long. None of it requires downtime. It just requires treating these as decisions rather than defaults.

If you've made these changes and your installation is still misbehaving, the problem is in the operational layer: how your polling architecture handles the network and devices once they're running. The next article covers that: serial versus TCP failure modes, unresponsive device handling, live diagnostics, and how to fix what you find without taking production down.

For a complete guide to connecting Modbus PLCs, alongside OPC UA, EtherNet/IP, and Siemens S7, to MQTT, cloud, and enterprise systems, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).


# The Rosetta Stone for Factories: Why IIoT Needs a Common Language First

In July 1799, a French soldier digging fortifications near the Egyptian town of Rosetta struck something hard beneath the soil. What he pulled out was a slab of dark granodiorite, about the size of a small door, covered in dense carved text.

The same decree appeared three times. Once in Ancient Egyptian hieroglyphs. Once in Demotic script. Once in Ancient Greek.

!["A photograph of the Rosetta Stone on display at the British Museum, London. The dark granodiorite slab is covered in three scripts: Ancient Egyptian hieroglyphs, Demotic, and Ancient Greek."](https://flowfuse.com/blog/2026/04/images/rosetta-stone.jpg)&#x2A;A photograph of the Rosetta Stone on display at the British Museum, London. The dark granodiorite slab is covered in three scripts: Ancient Egyptian hieroglyphs, Demotic, and Ancient Greek.*

For nearly 1,400 years, nobody could read hieroglyphs. Not for lack of material. Carvings covered every temple wall, every tomb, every monument in Egypt. The knowledge was always there, present, physical, accumulating for centuries. It just could not be accessed. The moment scholars found a single shared reference point, an entire civilisation unlocked almost overnight. Not one inscription. Not one tomb. Everything. All at once.

Your factory has been sitting on the same problem. And the same opportunity.

## The inscriptions are already on the walls

Manufacturing has a data shortage the same way Egypt had a stone shortage. It does not.

A typical production line generates more operational data in a single shift than most businesses analysed in an entire year a decade ago. Every machine cycle logged. Every temperature deviation recorded. Every alarm captured, every throughput number written down, every pressure reading stored somewhere. The factory floor is covered in inscriptions.

And almost none of it is being read.

Not because the data does not exist. Because it exists in forms that cannot speak to each other. A PLC stores fault history in a proprietary register format that only its own software understands. A SCADA system captures the same event three seconds later under a different identifier in a different schema. A maintenance platform has a ticket opened two days earlier flagging an anomaly on the same line. An edge gateway has been forwarding raw telemetry upstream for months that no analytics tool has ever been configured to consume.

!["Diagram showing a motor overheating event represented differently across four systems: a PLC register value, a SCADA alarm, a CMMS work order, and an edge gateway telemetry stream, illustrating fragmented factory data with no shared reference point."](https://flowfuse.com/blog/2026/04/images/one-event-four-diffrent-records.png)&#x2A;Diagram showing a motor overheating event represented differently across four systems: a PLC register value, a SCADA alarm, a CMMS work order, and an edge gateway telemetry stream, illustrating fragmented factory data with no shared reference point.*

Four systems. Four records. One event. None of them know the others exist.

This is what fragmented factory data actually looks like in practice. Not a gap in coverage. A gap in shared meaning. The same truth inscribed repeatedly across disconnected systems, in incompatible formats, with no reference point that would let anyone recognise they are all saying the same thing.

The factory is not data-poor. It is data-illiterate. And there is a significant difference between the two.

## Why the obvious fix makes it worse

The standard response to this problem is integration. Build an adapter. Write a translation layer. Connect system A to system B and get the data flowing.

It works. For a while.

The part that nobody talks about honestly enough is what integration looks like at scale. Point-to-point connections do not grow with your factory. They grow faster. Five systems require ten connections to fully link them. Ten systems require forty-five. Twenty systems require one hundred and ninety. Every new machine, every new platform, every new analytics tool added to the floor multiplies the integration surface. Each connection is custom-built, specific to the two systems it bridges, and fragile the moment either side changes.

!["Diagram comparing point-to-point integrations with a single reference point, showing how many system-to-system connections create complexity while a central reference simplifies connectivity."](https://flowfuse.com/blog/2026/04/images/point-to-point-vs-one-reference-point.png)&#x2A;Diagram comparing point-to-point integrations with a single reference point, showing how many system-to-system connections create complexity while a central reference simplifies connectivity.*

Most factories do not feel this pain acutely until they are already deep in it. The integrations accumulate quietly. The team that built them moves on. The documentation, if it existed at all, goes stale. Then a vendor releases a firmware update, or a new system needs to connect to six existing ones, and suddenly the technical debt that was invisible becomes the main reason a project that was supposed to take three months takes eighteen.

This is the trap that hieroglyphic scholars would recognise immediately. If you try to decode an ancient language by building a custom translation between every pair of known scripts, you end up with an unmanageable web of bilateral dictionaries, each one valid only for the two scripts it connects, none of them reusable, all of them requiring maintenance forever.

That is not decipherment. That is the problem wearing a different hat.

The Rosetta Stone worked not because it translated one script into another. It worked because it provided a fixed reference point that everything could map to. One anchor. Unlimited readability in every direction.

## What a fixed reference point looks like in a factory

!["Diagram showing three aligned components of a common industrial data language: shared meaning, reliable transport, and a single reference point."](https://flowfuse.com/blog/2026/04/images/common-language-three-parts.png)&#x2A;A common language in industrial systems requires shared meaning, reliable transport, and a single reference point.*

A common language in industrial systems is not a single wire protocol. People hear "common language" and think: pick one standard, mandate it, enforce it everywhere. That is not how it works, and the factories that have tried it by mandate alone have the scars to prove it.

What actually works is three things aligned together.

**A shared data model.** Not just agreement on how to transmit a value, but agreement on what a value means. [OPC-UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/) is the industrial world's most serious attempt at this. It does something no previous protocol attempted at scale: it separates meaning from transport. A temperature reading in OPC-UA is not a number. It is a structured object that carries the units, the valid range, the source, and the relationship to other values. Any system that speaks OPC-UA reads that object and understands exactly what it means, with no assumptions, no custom mapping, no translator standing in between.

**A reliable transport layer.** OPC-UA defines the vocabulary. [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/) moves it. Lightweight, publish-subscribe, designed for the unreliable networks and constrained hardware that characterise real factory floors rather than data centre diagrams. Sparkplug B closes the gap that vanilla MQTT leaves open: without it, two systems both speaking MQTT can still be writing in different dialects. With it, every message has a predictable structure before you read a single byte of content.

**An architecture that removes the N² problem entirely.** The [Unified Namespace](https://flowfuse.com/use-cases/uns/) is what changes the geometry. Instead of bilateral connections between systems, every device and every application publishes to and subscribes from a single broker. The broker is the fixed reference point, the Rosetta Stone. Every system maps to it. Every system becomes readable to every other system, not because they were directly connected, but because they share the same anchor.

!["Industrial data flow from PLC to analytics via MQTT broker"](https://flowfuse.com/blog/2026/04/images/flowfuse-uns.png)*Industrial data flow from PLC to analytics via MQTT broker*

Add a new machine and it publishes to the namespace. Every downstream system already subscribed to that topic hierarchy gets the data automatically. No new integration project. No new translation layer. No new debt.

## The dimension that changes everything

Here is what the Rosetta Stone actually did that tends to get overlooked.

It did not make one inscription readable. It made every inscription readable, including ones not yet found, ones buried under cities that would not be excavated for another century, ones carved on monuments that had not yet been discovered. The key worked forward as well as backward. Once the reference point existed, the entire future of Egyptology changed.

This is the dimension of the factory problem that most IIoT conversations miss, because most IIoT conversations stop at connectivity. Connect this machine to that system. Get this data into that dashboard. Valuable, narrowly. But still bilateral. Still one connection at a time. The geometry has not changed.

A Unified Namespace changes the geometry permanently.

When every system in a factory maps to a shared data model published through a common broker, the value does not accumulate linearly. It compounds. A quality defect on line 3 is no longer four disconnected records across four systems. It is one event, described from four angles, readable from a single location, correlatable in minutes rather than days. A maintenance anomaly flagged two days before a failure is not a ticket in one system and an alarm in another. It is a pattern visible across the entire operational picture, searchable historically, usable for prediction. In [automotive manufacturing](https://flowfuse.com/industries/automotive/), where the same downtime code needs to mean the same thing on every line in every plant, that shared reference point is what turns twelve local definitions into one benchmark everyone can actually compare against.

!["Linear vs compounding data value graph"](https://flowfuse.com/blog/2026/04/images/power-of-single-reference-point.png)*Linear vs compounding data value graph*

And every new system added to this architecture inherits the full value of everything that came before it. A new analytics platform connects to the namespace and immediately has access to every data source already publishing there. A new machine comes online and immediately contributes to every model, every dashboard, every alert already consuming from that part of the namespace.

This is what a fixed reference point actually buys. Not a cleaner integration. A fundamentally different trajectory. The factory stops accumulating translation debt and starts accumulating readable knowledge.

## Most factories are closer than they think

IIoT has a reputation for difficult, expensive, multi-year transformations. Some of that reputation is earned. Connecting a thirty-year-old Modbus device to a modern data architecture is not trivial. Bridging IT and OT teams that have operated in separate worlds for decades takes more than a software deployment. Getting every vendor, every system, and every platform aligned on a shared model requires real organisational will.

But the standards themselves are not the bottleneck anymore. OPC-UA is mature and supported by every major automation vendor. MQTT runs in millions of industrial environments. Sparkplug B is stable and deployable today. The Unified Namespace has moved from architectural concept to production reality at manufacturers who were dealing with exactly the same fragmentation problems described in this article.

The gap for most factories is not the language. It is the practical infrastructure to implement it without a programme that outlasts the budget that funded it. Legacy devices need to be connected without ripping out working equipment. Data needs to be normalised into a consistent structure without stopping the line. The namespace needs to be built incrementally, starting with the highest-value data sources, expanding outward as confidence grows.

That is an engineering problem. Engineering problems are solvable.

[FlowFuse](https://flowfuse.com) is built for exactly this gap. It connects legacy devices running any protocol, Modbus, PROFINET, OPC-UA, whatever the floor is running, transforms their data into a consistent structure, and publishes it into a Unified Namespace that every downstream system can read from day one. The integration debt stops accumulating. The readable knowledge starts.

## The stone was always there

The French soldier who found the Rosetta Stone was not looking for it. He was building a wall. The breakthrough did not require a new expedition, a new theory, or a new technology. It required recognising what was already in the ground and understanding that the same inscriptions covering every wall around him were suddenly, finally, all saying the same thing.

Every factory producing data it cannot fully read is standing in that same courtyard.

The inscriptions are on the walls. The PLCs are writing. The SCADA systems are writing. The maintenance platforms are writing. The edge gateways are writing. The data has been accumulating for years, in some cases decades, in languages that have never had a shared reference point. Not because the knowledge wasn't there, but because nobody had found the stone.

The standards that make it readable are not experimental. They are proven, deployed, and supported by every major automation vendor on the planet. The Unified Namespace is not a roadmap item. It is running in production at manufacturers dealing with exactly the fragmentation described in this article. The stone has already been found. The decipherment has already begun.

What remains is the infrastructure to bring it to your floor without a multi-year programme, without ripping out working equipment, and without stopping the line to rebuild the architecture underneath it.

That is the gap [FlowFuse](https://flowfuse.com) was built for. Connect the legacy devices. Normalise the data. Publish it into a namespace every downstream system can read from day one. The translation debt stops. The readable knowledge starts compounding. And every new machine, every new system, every new analytical question you bring to the floor inherits everything that came before it.

The question is not whether this is possible. Several thousand production facilities have already answered that.

The question is how much longer your factory keeps building walls around inscriptions it cannot read.


# How to Stop Noisy Sensor Data from Flooding Your Industrial System

In industrial systems, sensors rarely sit perfectly still. A temperature probe, pressure transducer, or flow meter will constantly fluctuate. Not because the process is changing, but because of electrical noise, vibration, or quantization artifacts in the ADC. If your control system reacts to every tiny wiggle, it triggers unnecessary alarms, wears out actuators, and buries real events in a fog of jitter.

A deadband filter fixes this with a single rule: only report a new value if it has moved beyond a defined threshold from the last accepted reading. Computationally trivial and tunable with one parameter, it is the simplest first line of defense for any industrial sensor pipeline. In this post, we will break down how it works, when to use it, and how to implement one in FlowFuse.

## What is a deadband filter?

A deadband filter is a signal processing technique that suppresses small, insignificant changes in sensor readings. Instead of reporting every value the sensor produces, it only forwards a new reading when the value has changed by more than a defined threshold from the last accepted value. Anything that falls within that band is considered noise and silently discarded.

Think of it like a thermostat. Your home heating does not kick in every time the temperature shifts by 0.1°C. It waits until the temperature drops past a meaningful threshold before reacting. A deadband filter applies the same logic to any continuous sensor signal.

!["Raw sensor data vs deadband-filtered output showing noise suppression in industrial systems"](https://flowfuse.com/blog/2026/04/images/deadband-filter.png)&#x2A;Raw sensor data (left) vs. deadband-filtered output (right). The shaded band shows the deadband zone. The filter only updates when the signal crosses its boundary.*

As shown above, the raw signal on the left is erratic and full of jitter. The filtered output on the right steps cleanly. It only moves when the signal genuinely crosses the deadband boundary, ignoring everything in between.

## How does a deadband filter work?

The logic is straightforward. The filter keeps track of the last value it accepted and compares every new incoming reading against it. If the difference is greater than the deadband threshold, the new value is accepted and passed downstream. If not, it is ignored and the last accepted value is held in place.

!["Flowchart showing deadband filter decision logic, new reading arrives, if change exceeds threshold the value is accepted and forwarded, otherwise it is discarded and the last value is held"](https://flowfuse.com/blog/2026/04/images/deadband-filter-how-it-works.png)&#x2A;Each incoming sensor reading is compared against the last accepted value. Only readings that exceed the deadband threshold are forwarded. Everything else is silently discarded.*

That single comparison is the entire filter. No buffers, no history, no moving averages. Just one stored value and one threshold check per incoming sample.

## Choosing the right threshold

Setting the deadband too narrow lets noise through and defeats the purpose. Setting it too wide causes the filter to miss real process changes or report them too late. The right value sits just above your sensor noise floor.

A practical starting point is to measure your sensor output when the process is known to be stable, observe the peak-to-peak fluctuation, and set your deadband to roughly that value. From there, tune it in the field until alarms and updates reflect only genuine process changes.

## Prerequisites

Before getting started, you will need the following:

- A running FlowFuse instance. If you do not have one yet, start with a [free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and follow [this guide](https://flowfuse.com/blog/2025/09/installing-node-red/) to get up and running on your edge device.
- A sensor or data source publishing values to FlowFuse via MQTT, Modbus, OPC-UA, or a simulated inject node for testing.

## Collecting sensor data with FlowFuse

Before you can filter anything, you need data flowing in. In industrial environments that means connecting to whatever is already on the floor. PLCs, sensors, drives, and controllers that speak dozens of different protocols, many of them decades old.

This is where FlowFuse earns its place. It connects to virtually any industrial data source out of the box. OPC-UA, Modbus, MQTT, Siemens S7, BACnet, and more. No custom drivers, no middleware. Whether your data lives on a modern IIoT sensor or a legacy PLC that has been running since the 1990s, FlowFuse can reach it.

Every reading arrives ready to use. The sensor value lands in `msg.payload` exactly as it was read, and that is all the filter needs to do its job.

Not sure how to connect your specific device or protocol? [Contact us](https://flowfuse.com/contact-us/) and we will help you get your data flowing.

If you are following along and do not have a live sensor available, you can simulate one using an inject node. Set it to repeat on an interval, and use a JSONata expression to generate a noisy value:

```json
$round(45 + (($millis() % 10000) / 1000) + $random(), 2)
```

This simulates a sensor that drifts steadily over time with random noise on top, giving the signal enough range to realistically cross the deadband threshold.

!["Inject node configured as a noisy sensor simulator using JSONata expression in FlowFuse"](https://flowfuse.com/blog/2026/04/images/noisy-sensor-simulation.png)&#x2A;Inject node configured to simulate a noisy sensor, generating a drifting value with added jitter every second.*

## Implementing a deadband filter

FlowFuse has a built-in **filter** node that handles deadband filtering out of the box. No code required. It only passes data when the payload has changed by more than a specified amount, which is exactly what a deadband filter does.

### Step 1: Add the filter node

1. In your palette, search for **filter**.
2. Drag it onto the canvas.

### Step 2: Place it in your flow

1. Position the filter node between your sensor input node and your output node.
2. Wire the sensor input to the filter node input, and the filter node output to your output. Whether that is a dashboard node, a database write node, or an MQTT broker.

### Step 3: Configure the filter node

1. Double-click the filter node to open its settings.
2. Set the **Mode** to `block unless value change is greater than`.
3. Enter your deadband value in the threshold field. You can use an absolute value such as `1.5` or a percentage such as `5%`.
4. Set the comparison to `compared to last input value`. This ensures each new value is compared against the last value that was actually forwarded.
5. Leave the **Property** as `msg.payload` unless your sensor data arrives on a different property.
6. If your flow handles multiple sensors on different topics, check **Apply mode separately for each** and set it to `msg.topic`. This allows a single filter node to handle multiple sensors independently.
7. Click **Done** and deploy your flow.

!["Filter node configuration in FlowFuse showing deadband mode set to block unless value change is greater than threshold"](https://flowfuse.com/blog/2026/04/images/filter-node-deadband.png)&#x2A;Filter node configured in deadband mode with threshold set to 2.5. Only values that differ by more than 2.5 units from the last accepted reading are passed downstream.*

> **Note:** The first value that arrives is always passed through and stored as the reference point. From that point on, every incoming value is compared against it. Only values that differ by more than the threshold are forwarded. When one is, it becomes the new reference point for all comparisons that follow.

!["Side by side dashboard comparison showing filtered vs unfiltered sensor data in FlowFuse"](https://flowfuse.com/blog/2026/04/images/chart-with-deadband-and-without-it.png)&#x2A;The dashboard above shows two charts connected to the same sensor data. The left chart has the deadband filter applied, the right does not. Notice the noise difference.*

## Conclusion

Noisy sensor data is one of those problems that looks small until it is not. False alarms, worn actuators, bloated historian databases, and dashboards that are impossible to read. All of it traces back to the same root cause. A control system reacting to every fluctuation instead of only the ones that matter.

A deadband filter solves this with a single comparison. No complex logic, no additional infrastructure, no performance overhead. Just a threshold and a rule, applied consistently to every incoming reading.

But filtering noise is just one piece of a reliable industrial data pipeline. FlowFuse goes further. It simplifies collecting data from any device or protocol, implementing patterns like deadband filtering, [store and forward](https://flowfuse.com/blog/2025/11/store-and-forward-edge-data-buffering/) to handle network interruptions, [dead letter queues](https://flowfuse.com/blog/2026/03/how-to-implement-dlq-and-retries/) to catch and recover failed messages, and much more. All of it managed centrally, deployed consistently, and running reliably across your entire fleet.

The filter handles the noise. FlowFuse handles everything else.

For more on how FlowFuse connects PLCs and sensors, via OPC UA, Modbus, EtherNet/IP, and Siemens S7, to MQTT, cloud, and enterprise systems, see the [FlowFuse PLC integration overview](https://flowfuse.com/landing/plc/).


# The Real Cost of Over-Engineered Industrial Systems

**There is a system in your facility that your best engineer knows not to touch.**

Not because it's dangerous. Because the last time someone touched it, a three-hour troubleshooting session ended with a call to an integrator who no longer works at the company that built it. The system came back up. Nobody knows exactly what fixed it. The incident report says "configuration restored" and leaves it there.

That system was delivered on time. It passed commissioning. The project manager closed it as a success. What it delivered, along with the data integration it was scoped to provide, was a permanent dependency on knowledge that exists nowhere formally and in fewer heads every year.

This is what over-engineering looks like from inside a facility that didn't make bad decisions. It looks like a system that works, that everyone is quietly glad isn't their responsibility, and that will eventually fail in a way nobody can diagnose quickly. The complexity that created it didn't arrive as a mistake. It arrived as a series of reasonable choices made by people who weren't going to be there when the choices compounded.

## What Complexity Actually Costs You

The cost shows up in three places. None of them are in the project budget.

**Downtime that should take minutes takes hours.**

A simple system fails in a way that matches its architecture. A Modbus timeout is diagnosable by anyone who understands the protocol. A failure inside a multi-layer stack, where data moves through a gateway, a middleware service, a message broker, and a cloud connector before it reaches its destination, has no obvious entry point. Every layer is a candidate. Every layer requires different tooling to inspect. And while the team works through them one at a time, production waits.

The failure itself is often minor. The diagnostic time is what costs. And diagnostic time scales directly with architectural complexity, not with the severity of the fault.

**The person who understands it becomes the system.**

Every complex system eventually concentrates its operational knowledge in one or two people. Not by design. By attrition. The team that inherited the system learned the parts they needed to. The parts nobody needed to touch, nobody learned. Over time, the person who has touched the most parts becomes the single point of failure the system never documented.

When that person leaves, the system doesn't fail immediately. It just becomes untouchable. Problems get worked around. Upgrades get deferred. The system runs in a state of managed risk that everyone acknowledges privately and nobody escalates formally, because escalating it means admitting how fragile something critical has become.

**Modernization stops at the layer nobody understands.**

Every facility has a modernization initiative. Cloud connectivity. Real-time analytics. Unified namespace. The vocabulary changes but the ambition is consistent. What doesn't change is the conversation that happens six weeks into the scoping exercise, when the architect traces the data path and hits the layer nobody has documentation for.

That layer doesn't get modernized. It gets routed around. The new system gets built on top of the old one, inheriting its limitations and adding its own. The budget meant to move the facility forward ends up funding infrastructure that looks new from the outside and runs on assumptions from 2017 underneath.

## Simple Systems Outlive Sophisticated Ones

Industrial systems are not software products. They don't get refactored on a two-week sprint cycle. They run. For years. Sometimes decades. Through shift changes, workforce turnover, firmware updates that nobody planned for, and organizational restructures that change who owns them without changing what they do.

That timeline is what makes complexity so expensive in operational technology. A sophisticated architecture in a software product gets maintained by the team that built it, updated continuously, and replaced when it no longer fits. A sophisticated architecture in a plant gets handed to whoever is there three years later, maintained defensively, and never replaced, because replacement means downtime and downtime means a conversation nobody wants to have.

The systems that survive this timeline are not the most capable ones. They're the most understood ones. The ones where the logic is visible, the failure modes are predictable, and the next engineer can read the configuration and understand what it does without needing to call the person who wrote it.

That property, legibility, is not a soft preference. It's a hard operational requirement that almost never appears in a project specification and almost always determines whether a system ages well or becomes the thing nobody touches.

Workforce turnover alone makes the case. The average tenure of an industrial automation engineer is somewhere between three and five years. The systems they build are expected to run for fifteen to twenty. Every system will be operated, maintained, and eventually modified by people who had no part in designing it. The question is whether it was built with that reality in mind, or whether it was built to impress the people in the room on the day it was commissioned.

## Simplicity Is an Engineering Decision

Consider Modbus. It has been declared obsolete for thirty years. Richer protocols have been developed, standardized, and backed by industry consortia with considerably more resources than the original Modbus specification ever had. Modbus keeps running. Not because the industry failed to move on, but because for a significant class of problems, Modbus is exactly as capable as the problem requires and no more. That match between problem and solution is not a limitation. It's the definition of good engineering.

The instinct is to treat simplicity as the absence of something, less capability, less sophistication, the option you choose when budget runs out or when the team isn't skilled enough to operate something better. That instinct is wrong.

Simplicity in engineering is not what you start with. It's what you arrive at. It's the outcome of understanding a problem well enough to know what it doesn't require. That's a harder position to reach than adding another integration layer, and it's a harder position to defend in a project meeting where the vendor is presenting a roadmap. But facilities that get there build systems that outlast the people who designed them, systems that new engineers can inherit without a month of archaeology, and that fail in ways the overnight technician can diagnose without calling anyone.

If you're a plant manager or engineering lead looking at your current architecture, the useful question isn't "what could this system do." It's "what does this system need to do, and what is the simplest architecture that does it reliably." That question doesn't produce primitive infrastructure. It produces infrastructure your whole team can own, where new requirements can be added without excavating the past, and where five years from now the design looks like a deliberate decision rather than something that just accumulated.

The facilities with the best operational track records made a specific tradeoff early. They accepted less capability at design time in exchange for more resilience over time. They built systems their whole team could own, not systems only their best engineer could explain. That tradeoff looks conservative in a project meeting. It looks correct every year after.

## What a Well-Matched Architecture Actually Looks Like

A well-matched architecture is not a polite term for cheap. It is not a consolation for teams that couldn't get the budget for something better. It is a specific outcome, a system where every component earns its place, the stack matches the actual problem, and the team that operates it has complete visibility into how it works and why.

In practice it looks like this.

A facility has forty legacy devices on the floor. PLCs, drives, meters, sensors, most of them speaking Modbus, some speaking older serial protocols, none of them going anywhere soon because they're running processes that haven't changed and won't change. The facility needs that data upstream: a cloud historian, a SCADA system, an analytics platform the operations team has been waiting two years to get real data into.

The over-engineered answer replaces the devices, or layers a complex middleware platform across all of them, or implements a protocol migration that requires specialist involvement at every stage and produces an architecture the in-house team can monitor but not truly operate.

The right answer puts an edge gateway between the floor and everything above it. The gateway reads Modbus from the devices that have always spoken Modbus. It normalizes the data, applies context, and publishes it upstream over MQTT or OPC UA to whatever system needs it. The field devices keep running exactly as they always have. The modern infrastructure gets clean, structured data. The in-house team owns the entire stack because the entire stack is visible and configurable without a specialist on call.

That is not a compromise. It is the correct answer for that problem. It connects legacy infrastructure to modern systems without introducing dependencies the team can't manage, without requiring production downtime to implement, and without creating a layer that becomes untouchable eighteen months after the integrator leaves.

## How FlowFuse Keeps It Simple

The gateway architecture described above is not a new idea. Facilities have been running edge gateways for years. The problem has never been the concept. It has been the execution: gateways that are simple to deploy and complex to manage, that work correctly in isolation and become coordination problems at scale, that solve the connectivity challenge and create a new one around visibility, consistency, and control.

[FlowFuse](https://flowfuse.com) is an Industrial Application Platform built around [Node-RED](https://flowfuse.com/node-red/) at the edge. The FlowFuse Device Agent connects to the devices that have always been on the floor, Modbus, MQTT, OPC UA, serial protocols, and publishes structured data upstream to whatever system needs it. The flow is visible. The logic is readable. An engineer who has never touched the system before can open it and understand what it does without documentation that may or may not exist.

That last part matters more than any feature list. The single most expensive property of an industrial system is whether the team that inherits it can operate it confidently. FlowFuse is designed around that property. Flows are managed centrally, deployed consistently across every edge device in the facility using DevOps Pipelines, and monitored from a single place. When something changes, DevOps Pipelines push it across every device it needs to reach, with Snapshots providing version control and rollback, not through a manual process that depends on someone remembering which devices were updated and which weren't.

Where teams need to build faster or debug more confidently, FlowFuse Expert, the AI built into FlowFuse and the Node-RED editor, reduces friction at the design stage, before complexity has a chance to accumulate. It works in two ways. The Chat Interface, accessible directly within the Node-RED editor, supports flow-building assistance and live operational data queries via MCP tools. The AI in Node-RED works inside the editor itself: inline code completions, flow autocomplete, a function builder, a flow explainer, JSON generation, and CSS and HTML generation for FlowFuse Dashboard. It doesn't generate complete flows from scratch, but it assists meaningfully at each step, suggesting the next node, completing a function, explaining logic that was written by someone who's no longer there. The result is less time spent on archaeology and more time spent on the work that actually moves the facility forward.

The result is an architecture that connects legacy infrastructure to modern systems without adding the complexity that makes those connections fragile. The Modbus devices on the floor keep running. The cloud historian, the SCADA system, the analytics platform get the data they need in the format they expect. The in-house team owns the stack end to end because the stack was designed to be owned, not just operated.

The system nobody wants to touch is built by engineers who won't be there to maintain it. The system the next engineer is glad to inherit is built by engineers who understood the difference. That's the decision FlowFuse is designed to support.


# OEE Is Misleading Your Factory: Here's How to Fix It

"85% is called world-class OEE" gets repeated in every plant manager meeting. In reality, only [3-6% of manufacturers ever reach that level](https://oxmaint.com/industries/steel-plant/oee-benchmarks-by-manufacturing-industry){rel="&#x22;nofollow&#x22;"}, and most operate much closer to [60%](https://manufacturingleadgeneration.com/manufacturing-quality-statistics/){rel="&#x22;nofollow&#x22;"}.

A pharma plant running at 72% under FDA validation rules is probably outperforming the automotive line bragging about 84%, but the quarterly review never frames it that way.

The formula is simple. Implementing it honestly almost never is. Definitions drift between sites. Manual collection misses small stops. Ideal cycle times get fudged. Operators game whatever gets measured. And the math itself fights you, push one component up and another usually drops.

This article looks at where OEE typically goes wrong on the shop floor, in how data is captured, how it is defined, and how it gets used, and what to fix so the number starts matching reality.

## Most OEE numbers are made up

When operators log downtime on paper or fill in a spreadsheet at the end of the shift, [manual systems typically capture only 60-70% of actual downtime](https://oxmaint.com/industries/steel-plant/common-oee-mistakes-in-manufacturing){rel="&#x22;nofollow&#x22;"}. Micro-stops under five minutes get skipped almost entirely. Added up, [these small losses often represent 10 to 15% of production time](https://teeptrak.com/en/fiabilite-donnees-oee-erreurs-solutions/){rel="&#x22;nofollow&#x22;"}.

Operators rarely log events as they happen. They reconstruct the shift at the end, from memory, under time pressure. A 90-second jam that happened four hours ago becomes "a couple of minutes," gets folded into the next stop, or never gets logged.

Speed losses are worse. A line running at 85% of rated speed all shift logs zero downtime events but loses 15% of its output. Without a recorded actual rate, Performance defaults to 100% and the loss disappears.

Put it together and [manual OEE is often overestimated by 10-25%](https://www.jitbase.com/blog/en/blog/how-to-effectively-track-the-oee-of-your-machine-tools){rel="&#x22;nofollow&#x22;"}. The dashboard says 78%. The real number is closer to 60%. Decisions get made on the 78%.

The fix is structural. PLCs already know when a line stopped, how long it ran below rated speed, and how many parts came off. Connecting [FlowFuse](https://flowfuse.com) to the PLC over OPC-UA, Modbus, S7, or EtherNet/IP pulls that data straight off the machine. The operator's job changes from logging the stop to classifying the cause. [FlowFuse's OEE Dashboard blueprint](https://flowfuse.com/blueprints/manufacturing/oee-dashboard/) gives you the calculation and visualisation layer on top of that, one of [several manufacturing dashboard patterns](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/) built on the same connected data.

## Everyone calculates OEE differently

Two plants in the same company report 75% OEE. It looks comparable, but it usually is not.

One plant counts changeovers as planned downtime. The other counts them as unplanned. One uses the machine's rated speed as the ideal cycle time. The other uses whatever speed they managed last quarter. Same formula. Different inputs. Same number on the slide, different reality on the floor.

[Even in corporations using standardized MES systems, OEE figures are not automatically comparable](https://www.symestic.com/en-us/blog/oee/the-limits-of-oee){rel="&#x22;nofollow&#x22;"}. Small differences in how setup time, breaks, planned maintenance, or first-pass quality get classified can significantly change the final score.

The biggest distortion usually comes from ideal cycle time. It is supposed to be the machine's rated speed. In practice, [plants set it too low to account for aging machinery or material issues](https://www.ease.io/blog/oee-in-manufacturing/){rel="&#x22;nofollow&#x22;"}. The score improves, but the loss does not disappear, it just gets built into the baseline.

Quality has a similar issue. OEE is meant to count only first-pass good parts. Including reworked parts [hides the fact that opportunity exists for improving first-pass process quality](https://www.worximity.com/blog/the-biggest-mistakes-when-calculating-oee){rel="&#x22;nofollow&#x22;"}. The line still ships the part, but the rework effort keeps growing.

Then there is the "Other" category. Once that bucket grows past [10-15% of logged downtime events, the dataset cannot identify top failure modes or drive maintenance decisions](https://oxmaint.com/industries/fmcg/oee-data-collection-downtime-logging-checklist){rel="&#x22;nofollow&#x22;"}. You know the line stopped, but not why.

The fix here is not more tools, it is consistency. Define what counts as planned downtime. Fix the cycle time for each product. Agree on what qualifies as first-pass quality. Use structured reason codes instead of free text.

Without that, OEE comparisons across plants are not comparing performance. They are comparing definitions.

## People game whatever you measure

Put a target on a metric and attach it to performance reviews, and the metric stops measuring reality. It starts measuring how well people produce the number.

Stops under a certain length stop getting logged. Changeovers get coded as planned instead of unplanned. Difficult products get pushed to the next shift. Maintenance gets scheduled during "non-production" windows so it does not count. The number improves. The process does not.

[Publishing shift rankings and punishing low performers creates fear, data manipulation, and gaming. Operators learn to hide problems rather than expose them](https://oxmaint.com/industries/steel-plant/common-oee-mistakes-in-manufacturing){rel="&#x22;nofollow&#x22;"}.

The deeper damage is trust. Operators stop believing the dashboard because it does not reflect what actually happened. Managers stop trusting operators because the numbers look manipulated. Maintenance stops trusting downtime data because they know which codes get used to make availability look better.

There is also slower drift at the management level. Ideal cycle times get adjusted downward. Planned downtime definitions get widened. Scheduled production time gets narrowed. Each change is small and defensible. Over time, the score loses meaning.

The fix is removing the incentive to game. Use OEE as a diagnostic, not a scorecard. Stop ranking shifts on it. Stop tying it to bonuses. Make the goal "find the losses," not "hit 80%."

## The benchmark trap

The 85% number gets repeated like a rule. It came from [Seiichi Nakajima's TPM framework in the 1980s](https://en.wikipedia.org/wiki/Overall_equipment_effectiveness){rel="&#x22;nofollow&#x22;"}, based on 90% availability, 95% performance, and 99.9% quality. It was a directional target for stable, high-volume manufacturing, not a universal benchmark.

Apply it without context and it breaks. [Highly regulated industries see OEE 20-40% lower than less regulated ones](https://oxmaint.com/industries/steel-plant/oee-benchmarks-by-manufacturing-industry){rel="&#x22;nofollow&#x22;"}, and that gap is not always waste.

The bigger problem is focus. A plant at 45% does not need a roadmap to 85%. It needs to fix the biggest losses, which might move it to 55% in a quarter. [The real benchmark is continuous improvement over your own baseline](https://www.mrpeasy.com/blog/overall-equipment-effectiveness/){rel="&#x22;nofollow&#x22;"}, not someone else's industry average.

Plant-level averages hide everything. [Averaging OEE across an entire facility produces a meaningless number. You can't improve "the plant", you improve specific machines, lines, and processes](https://oxmaint.com/industries/steel-plant/common-oee-mistakes-in-manufacturing){rel="&#x22;nofollow&#x22;"}. A bottleneck at 58% matters more than multiple machines at 88%.

## Tracking without acting

A lot of plants have gone through the full OEE journey. Bought the software. Installed the dashboards. Trained the operators. Put the screens on the floor. Six months later the same three reasons still top the [Pareto chart](https://flowfuse.com/blog/2025/09/creating-pareto-chart/).

Material wait. Changeover. Minor stops. No change.

From a distance, the system looks active. On the floor, it feels like a report nobody uses.

The issue is ownership. Production logs downtime, but maintenance, engineering, or procurement must fix it. The insight sits in one team, the action in another, and nothing closes the loop.

This is also where OEE's structural limits show up. [A high OEE on a non-bottleneck machine is not a good thing, if a machine that is not the bottleneck runs at high OEE, it leads to a jam of parts before the bottleneck](https://www.allaboutlean.com/use-oee/){rel="&#x22;nofollow&#x22;"}. The machine looks efficient. The system does not improve. Focus OEE tracking on the bottleneck and the lines feeding it.

The fix is to connect data to action. A recurring failure should trigger a maintenance work order. A material delay should alert procurement and the line lead. A changeover overrun should create a kaizen task.

[FlowFuse](https://flowfuse.com) sits in that gap, taking a downtime event from the line and turning it into a maintenance ticket, a procurement alert, or an escalation in real time. The metric only matters if it leads to something changing on the floor.

## What to actually do

- **Get the data from the machines, not the operators.** The PLC already knows when the line stopped, how fast it ran, and how many parts came off. The operator classifies the cause. Everything else falls apart without this. This is the layer [FlowFuse](https://flowfuse.com) handles, pulling the data straight off the PLC over OPC-UA, Modbus, S7, or EtherNet/IP.
- **Write down your definitions.** Make every site calculate the same way before comparing any numbers. Use a hierarchical reason code tree, not free text. Kill the "Other" bucket.
- **Apply OEE where it maps to throughput.** The bottleneck and the lines feeding it. High OEE on a non-bottleneck machine is WIP piling up before the constraint.
- **Stop ranking shifts on the score.** The moment OEE becomes a stick, the data becomes fiction.
- **Pair OEE with metrics that catch what it misses.** Throughput. First-pass yield. On-time-in-full. MTBF. The single number is a summary, not the picture.
- **Wire the data into action.** A logged event that does not trigger a ticket, an alert, or a kaizen item is a row in a database, not a fix. This is where [FlowFuse](https://flowfuse.com) earns its place, turning a downtime event into a maintenance ticket, a procurement alert, or a kaizen task in real time.
- **Compare against your own baseline.** Not the industry. Not 85%. Last month, last shift, last product run.

## Closing

OEE is not broken. It is just often misunderstood.

Used as a target, it gets gamed. Used as a comparison, it misleads. But used as a diagnostic, grounded in real data and consistent definitions, it becomes one of the most useful tools on the shop floor.

The difference is not in the formula. It is in how honestly you measure and whether anything changes because of it.

The value of OEE is not the number you report. It is the problems you uncover and the actions you take next.


# How to Build Industrial Apps With FlowFuse AI Expert

FlowFuse Expert now builds applications for you. Describe what you need, and the flow is built in front of you on the canvas, wired and configured. Ask for a change, it updates on the spot.

We shared the initial announcement in the [2.30 release post](https://flowfuse.com/blog/2026/05/flowfuse-release-2-30/#flowfuse-expert-builds-your-industrial-application). This post walks through building your first flow with FlowFuse Expert and how Expert works alongside your environment.

:video{ariaLabel="FlowFuse Expert building a simulated packaging conveyor monitoring application" autoPlay="true" height="527" loop="true" muted="true" playsInline="true" preload="none" width="1024"}&#x2A;Expert building a packaging conveyor monitoring application: MQTT alerts, dashboard indicators, and real-time event simulation, from a single prompt.*

## What FlowFuse Expert sees before it builds

Before the first node lands on the canvas, Expert reads your environment. We're tuning the experience to load context agentically based on what each scenario needs. Depending on the task, that can include:

- **Your canvas state**: the nodes you've placed, how they connect, what they do.
- **Your installed palette**: which nodes are installed and at what version.
- **Your existing node configurations**: the settings already defined in the nodes on your canvas. You can also share context directly to let the Expert create the node configurations for external infrastructure, this is being improved into a more dedicated experience soon, and FlowFuse-native infrastructure will increasingly be recognised and considered automatically based on intent.
- **Your runtime data**: when you attach it from the debug sidebar, Expert sees the `msg` data, errors, and values flowing through each node. It reasons about runtime behavior, not just wiring. We're working on optimising and automating this soon.

The result is output you can trust to match what you expect, so you reach your intended outcome sooner.

## Get started in two minutes

FlowFuse Expert is in open beta on FlowFuse Cloud (Team and Enterprise) — no request needed. It is also available on Self-Hosted Enterprise; [contact us](https://flowfuse.com/contact-us/?subject=FlowFuse%20Expert%20Application%20Building) to get it set up. If you don't already have a FlowFuse account, [sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} first.

Once enabled, open the editor and [find the FlowFuse Expert chat](https://flowfuse.com/docs/user/expert/chat/#opening-the-chat-interface). The chat is our integrated AI across the whole suite, so you'll find it everywhere from FlowFuse to Node-RED Editor.

Paste this in:

*"Build a live dashboard monitoring three machines (Machine 1, Machine 2, Machine 3). Each one should keep switching on its own every 2 seconds between Running (green), Idle (yellow), or Fault (red), so at any moment they can be in different states, with the name, state, and colored indicator updating live on the page."*

You can watch Expert do its work as the flow is built on the canvas. A few seconds later it's wired up and ready. Hit Deploy, open the dashboard, and the cards start cycling through Running, Idle, and Fault.

You didn't go hunting through the palette or keep the documentation open in another tab. The flow just showed up saving you time and effort.

> FlowFuse Expert works on both Hosted and Remote Instances.

From there, you can replace simulated data with live machine data, redesign the dashboard, add alarms, connect MQTT or OPC UA sources, and keep refining the application through prompts instead of manual building.

:lite-youtube{style="width: 100%; aspect-ratio: 16/9; background-image: url('/blog/2026/05/images/flowfuse-expert-building-flow.jpg'); background-size: cover;" title="Building Industrial Apps With FlowFuse Expert" videoid="wzD02B7EaqM"}

## Working with Expert day-to-day

Describe outcomes, not outputs. Tell Expert what you want to end up with and let it figure out the building blocks. Fine-tune the specifics afterward. And you're never locked in: you can keep working manually on the canvas right alongside Expert.

A few patterns that help you get the most out of Expert today. We're continuing to tune things so these matter less over time.

### Share context when something looks off

If a card's blank or a value's wrong, you don't have to hunt for the cause yourself. Expert can look up runtime data on its own. If you want to point it at something specific, you can also share context directly through the debug sidebar.

### Build end-to-end, then refine

Get the whole thing wired up first. Data flowing, dashboard bound, the basic loop running. Then iterate. Don't be afraid to dig deeper on any piece as you go.

If you need to fix specific things, it's best to do them one at a time for now, so you can verify each result.

### Deploy with your context in mind

If the flow is connected to a production process, take a minute to look over what Expert built before hitting Deploy. If it's a sandbox or a prototype, deploy away and see what happens. As Expert keeps improving, you'll be able to trust the output earlier without the manual check.

### Start fresh when the chat gets noisy

AI models can get poisoned with unrelated context over time. If results start drifting, starting a new chat often gives better results than trying to dig out of a bad thread.

## Where to go next

For the full reference on what FlowFuse Expert reads, how it interacts with your canvas, and advanced usage, see the [FlowFuse Expert documentation](https://flowfuse.com/docs/user/expert/). We're updating these alongside the agentic experience as it evolves.


# FlowFuse 2.30: Expert Builds Your Industrial Application

FlowFuse 2.30 lets FlowFuse Expert build industrial applications for you from a description. Tell Expert what you need, and it assembles it on your workspace.

## FlowFuse Expert Builds Your Industrial Application

*FlowFuse Expert is our integrated AI assistant across FlowFuse's website, platform, and in the immersive Node-RED editor.*

Until now, Expert could surface information, suggest changes, and act on links you clicked. Translating those suggestions into a working OEE dashboard, MES handover screen, or Modbus-to-UNS bridge still meant placing every node and wire by hand.

Now you can describe what you want to build and the FlowFuse Expert builds it for you directly on the Node-RED workspace saving you time. Real-time tool-call status keeps you in the loop while it works, and you keep iterating in chat to refine what it produced so it maps correctly to your real life scenario.

Start your agentic development with for example:

- "An OEE dashboard for line 3 with downtime reasons and a daily target"
- "Get temperature from Modbus address 1001 and publish that to my UNS broker on factory/line3/temperature"
- "A shift handover screen showing outstanding alarms and recent operator notes"
- "An asset utilization dashboard for the packaging cell, refreshed every minute"

:video{ariaLabel="FlowFuse Expert assembling an application on the Node-RED workspace from a chat prompt" autoPlay="true" height="527" loop="true" muted="true" playsInline="true" preload="none" style="border: 2px solid #E5E7EB;" width="1024"}

FlowFuse Expert assembling an application on the Node-RED workspace from a chat prompt.

### Availability

Agentic Node-RED development is being soft launched to create a window of opportunity to fine tune the experience in order to scale right after. Right now it is available on **FlowFuse Cloud Team and Enterprise on request**. Self-hosted enablement follows shortly.

[Contact us](https://flowfuse.com/contact-us/?subject=FlowFuse%20Expert%20Application%20Building) to let us enable Agentic Node-RED development for your FlowFuse Cloud team. Please make sure to provide the email address associated with your FlowFuse Cloud team.

**Coming next:** self-hosted enablement, plus we are exploring "bring your own key" so teams can point Expert at their own AI provider.

> **Update (FlowFuse 2.31):** FlowFuse Expert is now in open beta, available on FlowFuse Cloud with no request needed, and on Self-Hosted Enterprise. It, now, works on both Hosted and Remote Instances. [Read the 2.31 release post](https://flowfuse.com/blog/2026/06/flowfuse-release-2-31/).

### In practice

- You go from a description to a working OEE dashboard, Modbus integration, or handover screen without needing to place each node by hand
- You see Expert's progress in real time as it builds, rather than waiting on a wall of suggestions to apply manually
- You iterate by talking, in addition to being able to control everything by hand through the workspace

## What else is new?

### A smoother iteration experience with Expert

We refined the immersive editor experience so working with FlowFuse Expert feels more natural and with less context switching. Platform controls like snapshots, environment variables, and instance settings now stay accessible alongside the workspace instead of covering your workspace.

### More usable snapshot comparisons

We continued refining the snapshot comparison experience introduced in 2.29 to make reviewing changes faster and less noisy. Position-only changes can be hidden, computed values no longer appear as modified, and the diff viewer now makes it easier to identify the type of node affected at a glance.

### Smaller updates and fixes

- **Markdown code blocks in Expert preserve line breaks again**: a regression from the 2.29 highlighting work is fixed.
- **Device editor auto-recovery**: when opening the editor on a remote instance fails on first load, the page now refreshes after three seconds rather than leaving you on a 502.
- **Force all users to use SSO**: admins can now redirect every login to a single configured SSO provider, removing the email and password fallback for organisations that need to enforce SSO across the org (Enterprise self-hosted).
- **Tooltip cleanup**: native `title` replaces the buggy custom directive. Less flicker, fewer stuck tooltips.
- **Suspended team logging**: when a billing failure or trial expiry leaves an instance running, we now log why so support can act faster.
- **Device palette settings**: saving palette changes on a device no longer accidentally sends sanitised security flags upstream.
- **Git integration feature flag**: `gitIntegration` respects the all-feature override (Azure DevOps users on edge configurations).
- **Expert chat request timeout**: front-end chat requests time out cleanly rather than hanging.
- **Audit log stop reasons**: stop events show the underlying reason in the audit log detail rather than a generic message.

**Looking ahead:** we're actively preparing support for Node-RED 5.0 in FlowFuse and currently expect it to become available as a stack option by the end of May. Until then, Node-RED 4.1 remains the default.

---

For detailed breakdowns of each feature with additional visuals, visit our [changelog](https://flowfuse.com/changelog/). For the complete list of everything included in FlowFuse 2.30, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases){rel="&#x22;nofollow&#x22;"}.

If something in this release improves your workflow, or if there is still friction we can remove, please [share feedback or report issues regarding this release](mailto\:contact@flowfuse.com?subject=Feedback%20on%202.30) to us.


# See Every Logic Change in Your IIoT MOC Review with Git-Style Diffs

Approving a logic change you cannot fully see is not MOC. It is a signature on a description.

Here is the problem that creates, and how FlowFuse snapshot comparison solves it.

## The Gap in Every IIoT MOC Process

[Management of Change](https://www.advancedtech.com/blog/what-is-moc-in-manufacturing/){rel="&#x22;nofollow&#x22;"} requires that every change to control logic or operating procedures is reviewed, approved, and documented before it reaches production. The intent is sound: catch problems before they cause incidents.

In practice, the reviewer sees a ticket. "Updated OEE calculation." "Modified threshold on line 4 flow." A threshold changed from 80 to 8. A retry block deleted. Nobody reviewing a ticket sees any of that. They read it, they sign it, and the change goes out.

That is not a process failure. It is a tooling failure. Until recently, there was no practical way for a reviewer to see the exact lines of function code that changed, or which environment variable was modified, or which nodes were added or removed. So teams worked around it with descriptions, and hoped the descriptions were accurate.

That is where incidents trace back to.

## What Snapshot Comparison Shows

A [snapshot](https://flowfuse.com/docs/user/snapshots/) in FlowFuse captures the complete state of an instance running your IIoT flows at a point in time: every node, function block, configuration value, and environment variable. Comparing two snapshots produces a diff of everything that shifted between them.

The engineer makes their changes and creates a named snapshot. That snapshot becomes the artifact attached to the MOC request.

The reviewer compares it against the snapshot currently running in production. What they see is not a description of the change. It is the change.

![FlowFuse snapshot diff showing a function node with line-by-line code changes highlighted between two deployments](https://flowfuse.com/blog/2026/05/images/snapshot-function-code-change.png)

For configuration changes, the view shifts to a side-by-side property comparison.

![FlowFuse snapshot diff showing modified node properties with changed configuration values highlighted between two snapshots](https://flowfuse.com/blog/2026/05/images/snapshot-prop-change.png)

Function node logic appears as a line-level code diff: red for removed, green for added. Property changes, such as a modified threshold, an updated endpoint, or a changed environment variable, show old and new values side by side. The left sidebar lists every node that was added, deleted, or changed, so the reviewer knows the full scope before they start.

This creates a real audit trail for industrial change control. Reviewers can see exactly what changed instead of relying on summaries or manual descriptions.

## From Review to Deployment

When the reviewer has worked through the diff, they approve the named snapshot. That snapshot is then set as the deployment target for the edge device, and the device pulls it on next check-in.

![Diagram showing the MOC workflow from engineer creating a named snapshot, through reviewer comparison and approval, to snapshot deployment on the edge device](https://flowfuse.com/blog/2026/05/images/moc-to-deployment.png)

In FlowFuse, the reviewed artifact and the deployed artifact are the same thing. For audits, incident investigations, and regulatory compliance, that traceability is what MOC was always meant to produce.

For teams on Team or Enterprise plans, FlowFuse also creates auto snapshots on every deploy, a passive safety net that captures the exact state running on each instance or device, even when a named snapshot was not part of the workflow. Up to ten auto snapshots are retained automatically, giving teams a recoverable history without any extra steps. The same approved snapshot can also be pushed to an entire fleet without re-entry. The [full snapshot documentation](https://flowfuse.com/docs/user/snapshots/) covers every available action.


# All-or-Nothing Manufacturing Software Is Killing Your Agility

Every software vendor's pitch follows the same pattern. You get a complete system. It does everything. You commit to the full scope upfront, sign a multi-year contract, and wait. Eighteen months later, if the implementation runs on schedule, you might see value.

The problem is obvious: if your operation changes-and it will-you're locked in.

Today's manufacturers can't operate this way. Product mix is higher. Customer demand shifts faster. Regulatory requirements evolve. Continuous improvement isn't a quarterly initiative anymore; it's an operational requirement. Yet most manufacturing software still demands the same all-or-nothing commitment it did twenty years ago.

There's a better way. You deploy the capabilities you need now, get them live in weeks, and build the rest only when you need it. Your manufacturing stack grows with your operation, not according to a vendor's implementation roadmap.

## Why the All-or-Nothing Model Is Broken

The monolithic MES was designed for a different world. Stable product lines. Infrequent change. A standard process that ran untouched for a decade. That made sense in the early 2000s.

It doesn't make sense anymore.

Vendors like Siemens and Rockwell offer comprehensive solutions, but comprehensiveness comes with a cost. Longer timelines. Higher costs. Larger IT teams just to maintain them. For enterprise manufacturers with dedicated implementation budgets, that trade-off works. For mid-sized plants with lean IT teams running mixed product lines, it doesn't.

The real problem isn't just implementation time or cost. It's flexibility. In a monolithic system, everything is wired together. Change one piece, and you risk breaking another. Add an ERP integration, and you need to revalidate the entire system. The cost of change becomes so high that you stop making changes. You stop improving.

Manufacturing teams end up running software that doesn't match how they actually operate, because updating it feels too risky.

## A Different Approach: Independent Capabilities

What if you didn't buy a complete system? What if you deployed the specific capabilities your plant needs today, then added more as your operation demands?

That's not an MES anymore. It's something better. It's a manufacturing stack built by and for your operation.

Here's how it works: your OEE tracking lives independently from your quality control system. Your batch scheduling is separate from your ERP integration. When a machine fault signal arrives, it routes simultaneously to OEE logging-which alerts the operator-and to quality review-which flags the batch and automatically creates a work order in your ERP. Two different outcomes from one signal. Two independent systems. Zero manual coordination.

When you need to update one capability, you update it. When you need to replace one, you replace it. When a new requirement emerges, you build it. The rest of your stack stays untouched.

For plant managers, this means faster decisions. For IT teams, it means lower risk. For the business, it means you can improve operations on your timeline, not your vendor's.

## Why FlowFuse Fits This Model

Most industrial platforms ask you to pick a vendor and adapt your operations around their roadmap. FlowFuse takes a different approach. Instead of forcing an all-or-nothing MES rollout, it gives manufacturers a flexible platform to build the capabilities they need, when they need them.

Here’s why it works well for incremental manufacturing transformation:

**Fast to deploy and iterate.**
With FlowFuse’s low-code environment, engineers can quickly build industrial applications using Node-RED flows, dashboards, and integrations, without relying on long software development cycles. Teams can start with a simple machine monitoring dashboard, then expand into OEE tracking, downtime analysis, quality workflows, or maintenance applications over time.

**Open and extensible by design.**
FlowFuse is built on open-source technology, which means your flows, integrations, and data models remain under your control. You’re not locked into proprietary tooling or forced to wait for vendor feature releases when requirements evolve.

**Built for industrial connectivity.**
Manufacturing environments rarely rely on a single standard. FlowFuse supports protocols including OPC UA, MQTT, Modbus, and EtherNet/IP, and gives teams access to over 5,000 Node-RED nodes for connecting machines, databases, APIs, cloud services, and enterprise systems. Legacy PLCs, edge devices, historians, and modern cloud platforms can all work together on one platform without heavy middleware projects.

**AI that accelerates application development.**
The latest version of FlowFuse introduces [major improvements to FlowFuse Expert](https://flowfuse.com/blog/2026/05/flowfuse-release-2-30/), an AI assistant designed for building and troubleshooting industrial flows. Instead of manually assembling every workflow, engineers can describe what they want to build in natural language, and Expert helps generate flows, debug issues, and explain implementation steps.

With [MCP](https://flowfuse.com/blog/2025/10/building-mcp-server-using-flowfuse/) integrations connecting Expert to your brokers, databases, APIs, and industrial systems, the assistant can work with the context of your actual environment, reducing repetitive engineering work when building new manufacturing capabilities.

## How It All Connects

A manufacturing stack built on FlowFuse works across three layers.

### Layer 1: Shop Floor Infrastructure

At the bottom is your shop floor infrastructure, including machines, PLCs, sensors, and SCADA systems continuously generating operational data. This is where your operation lives, every temperature reading, production count, alarm signal, and quality check originates here.

### Layer 2: The FlowFuse Integration & Data Backbone

FlowFuse sits in the middle layer, connecting to these systems through protocols like MQTT, OPC UA, Modbus, EtherNet/IP, and over 5,000 integrations. It collects raw production data, normalizes it, and turns it into usable operational context.

A key advantage is FlowFuse's built-in MQTT broker, which enables you to build a [Unified Namespace (UNS)](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/), a standardized data structure that simplifies how machines, applications, and business systems communicate. With a UNS in place, integrations become faster to build and easier to maintain as your stack grows.

On top of this data layer, manufacturers can build applications with [FlowFuse Dashboards](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"} for OEE tracking, quality workflows, downtime monitoring, maintenance alerts, and work order management. Because these capabilities remain independent, teams can deploy and improve them incrementally as requirements evolve.

FlowFuse also includes the enterprise capabilities needed to operate these applications at scale, including:

- Remote edge device management
- DevOps workflows
- Snapshots for version control and rollback
- High availability deployments
- Role-based access control
- Built-in security features

Teams can manage industrial applications across multiple sites without building additional infrastructure around them.

### Layer 3: Business Systems Integration

At the top layer are your business systems, including ERP platforms, reporting tools, quality systems, and cloud services. FlowFuse connects these systems through APIs and integrations so operational data moves seamlessly between the shop floor and the business.

### Why This Architecture Changes Everything

This modular approach changes how manufacturing software delivers value. Instead of waiting over a year for a full MES rollout, manufacturers can start with a single capability and expand over time. Machine monitoring can go live first, followed by OEE, quality management, or ERP integration when needed.

The result is a manufacturing platform that evolves continuously with your operations instead of becoming another rigid system that is difficult to change.

## The Shift Starts Now

Most manufacturers already know their biggest operational blind spots. Awareness isn't the problem. The problem is that doing something about it has felt impossible when you're locked into an all-or-nothing system.

Independent capabilities change the math. You don't need a two-year program to fix a problem you identified today. You need the right starting point and a platform that rewards incremental progress.

A working capability in weeks. A connected operation in months. Manufacturing execution built by the people who know your operation best, on your timeline.

The manufacturers moving fastest aren't the ones with the biggest budgets. They're the ones who stopped waiting for the perfect system and started solving the problems in front of them today.


# NIS2 Compliance for Manufacturers: Why IEC 62443 Is the Missing Standard

Mid-market manufacturers are squarely in scope of the NIS2 Directive, now being transposed and enforced across the EU.

Under [Article 34](https://eur-lex.europa.eu/eli/dir/2022/2555/oj){rel="&#x22;nofollow&#x22;"}, fines reach €10 million or 2% of global turnover for essential entities, and €7 million or 1.4% for important entities, whichever is higher. [Article 20](https://eur-lex.europa.eu/eli/dir/2022/2555/oj){rel="&#x22;nofollow&#x22;"} adds personal liability for senior management.

So manufacturers open [Article 21](https://eur-lex.europa.eu/eli/dir/2022/2555/oj){rel="&#x22;nofollow&#x22;"}, find ten categories of measures in legal language with no implementation detail, and stall on the only question that matters: &#x2A;where do we actually start?*

This article is about the standard that answers it. &#x2A;*NIS2 tells you what to do. IEC 62443 tells you how.**

## NIS2 is deliberately vague, and that is the problem

[NIS2](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive){rel="&#x22;nofollow&#x22;"} is outcome-based. It tells you what to achieve, not how to achieve it. That is a feature, not a bug. The same rules cover sectors as different as healthcare, energy, water, transport, and manufacturing, each with its own technical reality.

But the gap is real. Article 21 requires you to manage cyber risk "appropriately and proportionately." It does not define what appropriate access control looks like on a plant floor. It does not tell you how to segment an OT network from IT. It does not specify what an incident response plan should contain for an industrial control system.

That gap is where most compliance projects stall. You cannot engineer compliance from a legal document. Lawyers write directives. Engineers need technical standards. Until someone names the standard to point at, every meeting ends with "let's get another quote."

DNV, one of the world's largest accredited certification bodies, frames it the same way. The directive describes what needs to be achieved without prescribing how to achieve it, and for critical infrastructure in the operational technology space, the IEC 62443 set of standards helps asset owners implement the right controls to secure their operations.

## IEC 62443 is the bridge

[IEC 62443](https://www.iec.ch/blog/understanding-iec-62443){rel="&#x22;nofollow&#x22;"} is a family of international standards for the cybersecurity of industrial automation and control systems. It was built for OT environments, not retrofitted from IT security. The [IEC](https://www.iec.ch/){rel="&#x22;nofollow&#x22;"} and [ISA](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards){rel="&#x22;nofollow&#x22;"} have developed it over more than a decade with industrial operators, vendors, and regulators.

For NIS2 purposes, three parts of the family matter most.

**[IEC 62443-2-1](https://webstore.iec.ch/en/publication/62883){rel="&#x22;nofollow&#x22;"}** defines the requirements for a cybersecurity management system at the asset owner: policies, roles, risk assessment, training, incident response. This is the organisational layer. It maps directly to the governance and risk management requirements in NIS2 Article 21.

**[IEC 62443-3-3](https://webstore.iec.ch/publication/7033){rel="&#x22;nofollow&#x22;"}** specifies the technical system requirements: identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. These are the seven Foundational Requirements (FR1 to FR7) that every industrial control system needs to implement. Each requirement has a Security Level (SL1 to SL4). [SL2 is the practical floor most mid-market manufacturers aim for](https://www.isasecure.org/hubfs/The-Case-for-ISA-IEC-62443-Security-Level-2-as-a-Minimum-FINAL.pdf){rel="&#x22;nofollow&#x22;"}: high enough to defend against casual or opportunistic attackers, achievable without nation-state-grade controls.

**[IEC 62443-4-1 and 4-2](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards){rel="&#x22;nofollow&#x22;"}** cover the secure development lifecycle for product suppliers and the technical security requirements for components. If you build PLCs, HMIs, sensors, or industrial software, your customers will increasingly demand these in purchase orders. They are also what the [EU Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act){rel="&#x22;nofollow&#x22;"} effectively requires.

The mapping between NIS2's ten Article 21 categories and 62443's controls is direct and well documented. Access control under NIS2 maps to FR1 and FR2 in 62443-3-3. Incident handling maps to FR6 and the management system requirements in 2-1. Supply chain security maps to 4-1 certification of your suppliers.

This convergence is visible across European guidance. ENISA's NIS2 implementation guidance references IEC 62443 alongside ISO 27001, NIST CSF, BSI Grundschutz, and ANSSI guidelines as relevant standards for industrial environments. National regulators have followed. France's ANSSI updated its industrial cybersecurity guidance in 2025 to explicitly strengthen alignment with IEC 62443, using a four-class system that draws on 62443's concepts of zones, conduits, and security levels. Germany's BSI, the Netherlands' NCSC, and other national authorities reference the same family. When an auditor asks how you are implementing NIS2, "we are aligned to 62443-3-3 at SL2" is an answer they will recognise.

Be honest about the cost. A full certification effort is a multi-month engagement with an accredited [ISASecure](https://www.isasecure.org/){rel="&#x22;nofollow&#x22;"} certification body, and costs scale with system complexity. Accredited bodies do not publish public pricing, so plan to get quotes early. Most mid-market manufacturers do not need to certify. They need to *align*. That is a much shorter path, and it is where the real compliance value lives.

## Why mid-market manufacturers stall

If 62443 is the answer, why is not every manufacturer using it? Two honest reasons.

**The standard is hard to navigate, and OT expertise is scarce.** The 62443 family runs to more than a dozen documents in formal standards language. The people who understand both PLCs and identity management, both ladder logic and SAML, are rare and expensive. Most plant IT teams were built to keep the ERP running, not to harden an industrial control system against a determined attacker.

**The gap between current reality and an auditable environment feels too large to start.** Look at the plant floor. Engineers share logins. Scripts run on unmanaged laptops. No audit trail of who changed what. The distance to "62443-aligned" looks impossible, so the project never gets a kickoff date.

Neither is unsolvable. They are just rarely named honestly in vendor marketing.

## The industrial software layer most assessments overlook

When you scope your 62443 work, you will define what the standard calls the System under Consideration: the boundary of what is being secured. The usual candidates make the list immediately. SCADA, historians, PLCs, HMIs, the engineering workstations.

What often gets missed is the layer of custom industrial applications running alongside that core stack. Dashboards built by a plant engineer to surface OEE data. Edge integrations pulling sensor readings into the cloud. Data transformation flows connecting an old line to a new MES. This software runs production-critical workloads, and it almost always lives outside any formal access control or audit regime.

In a typical setup, that software has shared logins, no role-based access, no version control on changes, no audit trail of who deployed what, and ad-hoc deployment processes that vary by site. Against 62443-3-3 at SL2, particularly FR1 (identification and authentication), FR2 (use control), and FR6 (timely response to events through audit logging), this layer is one of the largest gaps on the assessment.

This is the gap [FlowFuse](https://flowfuse.com) closes. FlowFuse is a managed industrial application platform that adds the controls 62443 expects to environments where engineers are already building production applications:

- Enterprise SSO and role-based access control
- Full audit logging of changes and deployments
- Version control with rollback
- Fleet management across sites
- Governed deployment pipelines

It is one piece of the 62443 scope, not the whole thing. But it is the piece most assessments flag and most teams do not have a clean answer for.

## Where to start this quarter

If NIS2 is on your roadmap and you have been waiting for a starting point, here is a sequence that works:

1. **Define your System under Consideration.** Use IEC 62443-2-1 to scope what is in and what is out. Include remote access, IIoT sensors, and any custom industrial applications running on the plant floor.
2. **Inventory your OT software stack.** Not just the PLCs and HMIs. Every dashboard, every data integration, every edge script. If you cannot list it, you cannot secure it.
3. **Map gaps against 62443-3-3 SL2.** Foundational Requirements 1, 2, and 6 are usually where mid-market manufacturers find the most exposure.
4. **Prioritise by risk and effort.** Fix shared logins and missing audit trails before you tackle network segmentation. The low-hanging fruit is the controls auditors will check first.

You do not need to certify. You need to show, with evidence, that your controls map to a recognised standard. 62443 is the standard auditors recognise.

## What is next

NIS2 is not the end of this. The [EU Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act){rel="&#x22;nofollow&#x22;"} brings product-side obligations into force on 11 December 2027 for any manufacturer who builds something with digital elements. The first vulnerability reporting requirements kick in earlier, on 11 September 2026. The compliance path is the same standard family: 62443-4-1 for secure development lifecycle, 4-2 for component requirements.

The manufacturers who start now will be ready. The ones who wait will be answering auditor questions under deadline pressure.

For now: stop waiting for NIS2 to tell you how. It will not. 62443 will.


# OPC UA Protocol Security: How It's Actually Exploited, and How to Fix It

Threat actors don't break OPC UA's cryptography. They walk through the security it left switched off. The attacks that work in the field are disabled trust lists, anonymous logins left on, dead ciphers that were never removed, and servers sitting on the open internet. This post breaks down how attackers actually exploit OPC UA, vector by vector.

That's the irony. Unlike most industrial protocols, OPC UA ships with real security: authentication, signing, and encryption built into the spec. It's what finally let your Siemens PLC, your Allen-Bradley controller, and your SCADA system speak the same language. But "built in" and "turned on" are different things, and attackers live in that gap.

## What OPC UA is, and why its security is different

OPC UA (OPC Unified Architecture) is the platform-independent protocol that succeeded classic OPC, letting PLCs, SCADA systems, and MES/ERP software from different vendors exchange live process data over a single, standardized interface. It runs over TCP or HTTPS, supports pub/sub as well as client-server communication, and, unlike Modbus, most EtherNet/IP variants, or classic OPC DA, it was designed with security as part of the protocol itself rather than bolted on afterward.

That's what makes OPC UA different from most industrial protocols still running on plant floors: it ships with application authentication (X.509 certificates), user authentication, message signing, and encryption, all defined in the OPC UA specification rather than left to integrators to build themselves. In theory, that should make OPC UA one of the more secure links in the OT stack.

In practice, that security is opt-in at almost every layer, and a lot of real deployments opt out. The rest of this post walks through exactly where that happens, and why the gap between OPC UA's built-in protections and what's actually running in the field is where every real-world attack has landed.

## Why attackers target OPC UA

The OPC server sits at a dangerous spot in the stack. It talks to PLCs, HMIs, and robotic arms, then exposes everything through one interface. For an attacker, that's the appeal: compromise the server and you don't get one device, you get the read-and-write path to the physical process.

That changes the attacker's goal. In IT, the aim is usually to take over the machine. In OT, the more alarming prospect is the physical one: because the OPC server issues the commands that run the plant, blinding the operator or freezing the server can create a safety problem, not just a data breach.

The scale is real. [Claroty's Team82](https://claroty.com/team82/research/opc-ua-deep-dive-a-complete-guide-to-the-opc-ua-attack-surface){rel="&#x22;nofollow&#x22;"} has disclosed more than two dozen OPC UA vulnerabilities since 2020, and its exploit framework has helped find close to 50 across clients, servers, and gateways.

## The exposure problem

Before any clever exploit, there's the basic question of who can reach the server. [Bitsight's TRACE research team](https://www.bitsight.com/blog/opc-ua-server-internet-device-exposures-in-2025){rel="&#x22;nofollow&#x22;"}, in a year-long scan through June 2025, found 14,220 internet-exposed OPC UA devices across 99 countries. Over half (51.74%) allowed unauthenticated access. Among the devices that reported their supported security modes, 80.26% supported an unencrypted "None" mode that transmits data in plaintext. Most anonymously accessible servers also had auditing disabled, so an attacker connects, reads the plant, and leaves no trail.

None of this is a flaw in OPC UA itself. The protocol offers strong authentication and encryption; these are deployment and configuration choices made by asset owners.

Anonymous access, as Bitsight senior security research scientist Vasco Pinto frames it, is what makes the exposure dangerous:

> This configuration represents a significant security risk, as it allows anyone to access server information and potentially read operational data without authentication.

[Bitsight TRACE](https://www.bitsight.com/blog/opc-ua-server-internet-device-exposures-in-2025){rel="&#x22;nofollow&#x22;"}

Major OT vendors, including Siemens, Schneider Electric, and Rockwell Automation, all explicitly advise against putting these servers on the open internet. Thousands remain there anyway.

The lesson from OT researchers is blunt: attackers often don't need an exploit. Unauthenticated, internet-facing servers are the entry point, and Shodan does the recon for free.

## Anonymous and weak authentication

If anonymous login is enabled, the server simply doesn't authenticate the user, and combined with internet exposure, there's no attack to speak of. The attacker just connects.

There's a trap here too. OPC UA separates *application* authentication (does the server trust this client's certificate?) from *user* authentication (who is the user?). Anonymous user access is far less risky when application authentication is enforced, but dangerous when it isn't. Many deployments disable the wrong layer and assume they're still covered.

## Broken certificate validation

This one's the worst, because the servers *look* secure. They advertise certificate-based authentication. They just don't enforce it.

[CISPA researchers Alessandro Erba, Anne Müller, and Nils Ole Tippenhauer](https://arxiv.org/abs/2104.06051){rel="&#x22;nofollow&#x22;"} systematically tested 48 OPC UA products and libraries. They found 38 of the 48 carried one or more security issues, and 7 didn't support the protocol's security features at all. The failures cluster around certificate and trust list handling: missing trust list support, trust lists disabled by default, and insecure trust list configuration. The researchers were careful to locate the problem in implementations and configuration rather than the protocol's design, though they argued the standard contributes by permitting these insecure options in the first place.

What does that buy an attacker? A machine-in-the-middle position. A third party inserts itself between two legitimate entities, intercepting and tampering with data while neither side notices, blinding maintenance staff to the real state of the plant. The operator's screen says everything is normal. It isn't. The researchers proved it: their attack framework, which implements Rogue Server, Rogue Client, and Middleperson modes against real implementations, could steal exchanged credentials, eavesdrop on process data, and manipulate the physical process through sensor and actuator values.

## Weak legacy crypto left switched on

OPC UA didn't build on TLS. It implemented its own cryptographic transport layer, which is exactly why Secura's Tom Tervoort, the researcher behind Zerologon, went after it [at DEF CON 33 in 2025](https://www.darkreading.com/vulnerabilities-threats/utilities-factories-encryption-holes-industrial-protocol){rel="&#x22;nofollow&#x22;"}:

> That makes it an interesting research target for me, especially because they're not relying on an existing standard protocol like TLS. They implemented their own cryptographic protocol.

Tom Tervoort, Secura

His work produced three CVEs, all credited to him in the vendor advisories, and by his own account at the talk the underlying issues affected at least seven products. [CVE-2024-42513](https://files.opcfoundation.org/SecurityBulletins/OPC%20Foundation%20Security%20Bulletin%20CVE-2024-42513.pdf){rel="&#x22;nofollow&#x22;"} lets an unauthorized attacker bypass application authentication in the OPC UA .NET Standard Stack when HTTPS endpoints are enabled with a security policy other than None, which the OPC Foundation classifies as CWE-305 and rates medium severity. [CVE-2024-42512](https://files.opcfoundation.org/SecurityBulletins/OPC%20Foundation%20Security%20Bulletin%20CVE-2024-42512.pdf){rel="&#x22;nofollow&#x22;"} targets the deprecated Basic128Rsa15 policy, which uses RSA with PKCS#1 v1.5 padding. The OPC Foundation classifies it as an observable timing discrepancy (CWE-208) with confidentiality impact and rates it medium severity, noting that Basic128Rsa15 is disabled by default, so most users are unaffected. CODESYS, assessing the same weakness in its own server as [CVE-2025-1468](https://certvde.com/en/advisories/VDE-2025-022/){rel="&#x22;nofollow&#x22;"}, describes the consequence more bluntly: an unauthenticated attacker exploiting the Bleichenbacher padding oracle (a decades-old attack that recovers RSA-encrypted secrets by watching how a server responds to malformed padding) could compromise the server certificate's private key, then bypass application authentication or decrypt traffic. The common thread is old, known-weak crypto that should have been retired but lingers in non-default configurations.

## Denial of service against the process

Not every attack reads or steals. Some just stop the plant. Flooding or crashing the OPC server kills the SCADA workstation's real-time view and command path.

This is where OPC UA research began. In 2018, [Kaspersky ICS CERT](https://ics-cert.kaspersky.com/publications/reports/2018/05/10/opc-ua-security-analysis/){rel="&#x22;nofollow&#x22;"} reported 17 zero-day vulnerabilities in the OPC Foundation's products, spanning denial of service and remote code execution, plus several flaws in commercial applications built on the stack. All were reported and fixed by the end of March 2018. The OPC Foundation's own response reviewed the findings and pointed out that eight of the 17 sat in an ANSI-C *sample server application* shipped as example code on GitHub rather than in the production stack, and that many third-party flaws came from developers misusing the stack's API. The researchers also pinned down the realistic threat model in interviews: exploitation usually needs local network access, and they said they had never seen a configuration allowing direct internet attacks. The broader lesson holds regardless: because a single flaw in a shared OPC UA library or sample can propagate into every product built on it, one bug scales across the supply chain.

## Client and gateway exploitation

Servers aren't the only target. The client trusts the server, and that trust is exploitable. [Team82 demonstrated client-side remote code execution](https://claroty.com/team82/research/opc-ua-deep-dive-series-part-8-gaining-client-side-remote-code-execution){rel="&#x22;nofollow&#x22;"} by exploiting the client's trust in data it receives from the server. Stand up a rogue server and you can reach back into the clients connecting to it.

Integration servers, the gateways stitching multiple OPC UA systems together, are richer still, because vulnerabilities chain. [In the Softing Secure Integration Server](https://claroty.com/team82/research/opc-ua-deep-dive-series-part-9-chaining-vulnerabilities-to-exploit-softing-opc-ua-integration-server){rel="&#x22;nofollow&#x22;"}, researchers chained four new bugs with a fifth to reach full remote code execution. No single flaw was catastrophic; strung together, they owned the box.

## The pattern

The vulnerabilities threat actors exploit in OPC UA are rarely clever zero days. They're disabled trust lists, anonymous logins, stale ciphers, exposed servers, and trusted clients fed bad data. The protocol gives you the tools to close every one. The question is whether they're switched on.

That's an architecture problem, and it's where we're headed next. In the follow-up, *How to Establish a Defensible OPC UA Security Architecture*, we'll turn these attack vectors into a concrete blueprint for building OPC UA deployments that hold up.


# Announcing Node-RED Con 2026: Call for Papers Now Open

Node-RED Con is back. The community conference returns on **Tuesday,
November 3, 2026**, free, online, and open to everyone. FlowFuse is proud
to sponsor this year's event alongside the OpenJS Foundation.

This year's theme is **Node-RED at the Edge of Intelligence**.

## The Call for Papers is open

The conference agenda is built entirely from community submissions. The
organizing team is looking for talks across three formats:

- **Full Talks & Demos (25–30 mins):** Technical talks, case studies, and
  practical demonstrations aligned with this year's theme. Submissions are
  particularly encouraged in these areas: real-world Node-RED deployments in
  production, AI integration (LLMs, agents, MCP), edge computing architectures,
  industrial use cases (PLCs, SCADA, OPC-UA, MQTT), and using AI tools to build
  and manage flows.
- **Lightning Talks (8–10 mins):** Fun, cool, or inspiring projects built with
  Node-RED, no matter how unconventional. IoT/IIoT and AI projects are
  encouraged, but any project you're proud of is welcome.
- **Panelists:** Experts with strong opinions and experience in industrial
  automation, AI in industrial environments, IoT security, or the future of
  low-code development.

[Submit your talk](https://nrcon.nodered.org/){rel="&#x22;nofollow&#x22;"} &#x2A;*CFP closes Friday, July 31, 2026.**

## Why speak

Node-RED Con 2025 welcomed 1,700+ registered and 1,100+ attendees from 35+
countries. Sessions averaged 350+ live viewers, with the most-watched talks
drawing over 600 concurrent attendees. All sessions are recorded and published:
the [Node-RED Con 2025 playlist](https://www.youtube.com/playlist?list=PLyNBB9VCLmo2yvFdVZOv41NUEzuw-CAZX){rel="&#x22;nofollow&#x22;"}
has accumulated 3,100+ views and is still growing.

## Stay in the loop

Want to be notified when registration opens? Sign up below.


# Turning an Application Idea into an Architecture

Every industrial application starts with an idea.

*"We need OEE dashboards."*

*"We need a Unified Namespace."*

*"We need an asset registry."*

The challenge isn't the idea. It's turning it into a clear architecture. Instead of starting with technologies, start with the responsibilities the application must fulfil. Once you can identify those, the architecture naturally follows.

This article introduces a simple four-step framework for turning application ideas into repeatable industrial architectures.

## How This Framework Works

![Four-step framework for turning an application idea into an architecture](https://flowfuse.com/blog/2026/06/images/four-moves-framework.png)*Turn any application idea into an architecture in four moves*

A FlowFuse application uses a small number of standard building blocks. Don't memorise them. Learn to recognise them. Think of it as learning to see the structure behind an application idea.

Every example in this guide follows the same four moves:

1. **Say what it does.** Start with the outcome. Describe the problem you're solving, not the technology you're using.
2. **Pick the building block.** Identify the FlowFuse building block, or combination of blocks, that delivers that outcome.
3. **Decide where the data goes.** Determine how data moves through the application and where it should live.
4. **Read off the sentence.** Combine the pieces into a single architectural statement.

That final sentence matters more than it might seem. If you can describe the architecture in one clear sentence, you've already made most of the important design decisions.

We'll apply these four moves three times: first to a hardware application, then to a software application, and finally to one that combines both.

## Example 1: A Hardware Idea

Let's start with a requirement many manufacturers are working towards today.

### The Idea

A company wants to build a Unified Namespace so that dashboards, analytics tools, and other applications can consume machine data consistently.

At this stage, forget MQTT, databases, and deployment. Focus on what needs to happen.

### 1. Say What It Does

The application reads data from local equipment and publishes it in a consistent structure for other systems to consume.

That's the outcome.

### 2. Pick the Building Block

Look at the hardware building blocks available, and recognise which one matches the requirement.

| Hardware Building Block | What it is                                                                    |
| ----------------------- | ----------------------------------------------------------------------------- |
| **Packaged App**        | A finished application that runs on a device with little or no configuration. |
| **Configurable App**    | The same application, but with site-specific settings.                        |
| **Edge Building Block** | Reusable functionality that you assemble into larger edge solutions.          |

This application talks directly to machines, PLCs, and sensors, so we're dealing with a hardware component.

It also needs adapting to the equipment at each site rather than deploying unchanged everywhere. That rules out a Packaged App and points us towards an **Edge Building Block**.

We now know the first piece of our architecture.

### 3. Decide Where the Data Goes

Now ask what happens to the data.

The application reads information from machines and makes it available to other systems: dashboards, analytics platforms, historians, reporting tools, or other applications.

Because multiple consumers need the same information in real time, a &#x2A;*Broker (MQTT)** is the natural destination. Rather than send data directly to each application, the Edge Building Block publishes it once and lets other systems subscribe to what they need.

![Architecture diagram of a Hardware Edge Building Block publishing equipment data to a Broker](https://flowfuse.com/blog/2026/06/images/example-1-diagram.png)*The Edge Building Block reads machine data and publishes it once, so any system can subscribe*

We've now identified both the application and its primary data destination.

### 4. Read Off the Sentence

Combine the pieces.

> A Hardware Edge Building Block reads local equipment data and publishes it to a Broker.

That's the architecture.

Notice what we skipped. We never discussed protocols, flows, dashboards, databases, or deployment details. We started with a requirement, picked the building block, decided where the data goes, and arrived at a clear architectural description, captured in a single sentence.

## Example 2: A Software Idea

The process doesn't change when hardware disappears from the picture. This time the four moves should already feel familiar, so we'll work through them as one continuous walk rather than four labelled steps.

### The Idea

A company wants a central asset registry where teams can view, search, and maintain information about equipment across multiple sites.

Operators, maintenance teams, and engineers all need the same information, and everyone should see changes immediately.

### Working Through the Moves

Said plainly, the application maintains a shared list of assets that users can view, search, and update. That's the outcome, not the implementation.

This time nothing touches machines, PLCs, or sensors. The application exists entirely for people. Users open screens, search records, update information, and view results. That points us towards a software building block.

| Software Building Block   | What it is                                                                               |
| ------------------------- | ---------------------------------------------------------------------------------------- |
| **Packaged App**          | A self-contained application that performs a specific function without a user interface. |
| **Data-Driven App**       | A user-facing application whose content is driven by data.                               |
| **Shared Building Block** | Reusable functionality that you incorporate into other applications.                     |

The requirement revolves around people viewing and managing data through an interface, which makes it a **Data-Driven App**.

Now the data. Assets are records. An asset belongs to a site. It may have an owner, a status, maintenance history, and other attributes. Users search these records, update them, and relate them to one another. This is structured business data, which makes a **Relational Database** the natural choice. The Data-Driven App reads and updates the information stored there.

![Architecture diagram of a Software Data-Driven App reading and updating asset records in a Relational Database](https://flowfuse.com/blog/2026/06/images/example-2-diagram.png)*Asset records live in the Relational Database; the Data-Driven App is the interface users work through*

### Read Off the Sentence

Combine the pieces.

> A Software Data-Driven App manages asset information stored in a Relational Database.

That's the architecture.

Same four moves, same single-sentence result. We started with a business requirement, picked the application type, and decided where the data belongs, without touching implementation. Only the pieces changed.

## Example 3: Combining Hardware and Software (OEE)

The first two examples were deliberately simple: one hardware application, one software application. Most real-world industrial applications combine both. By now the moves should feel like second nature, so we'll again work through them as one continuous walk.

### The Idea

A manufacturer wants operators and supervisors to see live OEE for every production line. They also want historical data so they can analyse trends, compare performance, and spot opportunities for improvement.

This requirement spans two worlds. Machines generate the data. People consume the results.

Make it concrete. Say Line 3 is a packaging line, and the manufacturer wants the supervisor's screen to show that it's running at 78% OEE right now, with a downtime event logged at 14:32. To get there, the line's PLC has to publish its running state and part counts, something in the cloud has to turn those into an OEE figure, and the day's readings have to land somewhere you can chart them tomorrow. Hold that picture while we work through it.

### Working Through the Moves

Said plainly, the solution needs to collect production data from equipment, calculate OEE metrics, present those metrics to users, and store historical data for analysis. That's already more than one responsibility, which tells us we're combining building blocks, not picking a single one.

The machine side is the pattern from Example 1: production data needs collecting from equipment and making available to other systems. That's a **Hardware Edge Building Block**.

The user side is the pattern from Example 2: operators need dashboards showing current performance and historical trends. That's a **Software Data-Driven App**.

Now the data. The hardware component publishes machine state and production events. On Line 3, that's the running/stopped flag and the part count ticking up. Multiple consumers may need that information, so the first destination is a **Broker**. The software application subscribes to the broker, consumes the machine data, and calculates OEE, turning Line 3's raw counts into that 78% figure on the supervisor's screen.

The requirement also calls for historical analysis. OEE values, production counts, and downtime events like the 14:32 stop are all time-based measurements, which makes a **Time-Series Database** the natural place to store them.

![Architecture diagram of an Edge Building Block, Broker, Data-Driven App, and Time-Series Database working together for OEE](https://flowfuse.com/blog/2026/06/images/example-3-diagram.png)*Two familiar patterns connected: the edge piece publishes, the cloud app calculates and displays, the database remembers*

### Read Off the Sentence

Combine the pieces.

> A Hardware Edge Building Block publishes machine data to a Broker, which a Software Data-Driven App consumes to calculate and display OEE, storing historical metrics in a Time-Series Database.

That's the architecture.

We didn't design OEE from scratch. We recognised two patterns we'd already seen and connected them. The challenge wasn't inventing a new architecture. It was recognising which building blocks the job needed and how they fit together.

## Conclusion

At the start of this article, an OEE system, a Unified Namespace, and an asset registry looked like completely different applications. By now they should look familiar, not because the business problems are the same, but because the process for designing them is.

Each started with a requirement, broke down into a set of responsibilities, mapped onto FlowFuse building blocks, and resolved into a single architectural sentence.

That's the real purpose of this framework: to help you see the structure behind an application before implementation begins. Once you can do that, you stop asking "What should we build?" and start asking "Which patterns are already here?"

Next time a requirement lands on your desk, run the four moves before you open a diagram. The answer is usually much simpler than it first appears.


# Why Downtime Spreadsheets Fail and How to Automate Detection and Escalation

In most factories, downtime still lives in a spreadsheet. Someone writes down when a machine stopped, when it got noticed, and when it ran again. It looks like control. The longer I look at how plants actually run, the more I read it as something else: a record of how late everyone found out.

The problem is the person in the middle. A machine stops, someone has to notice, then open the file and type the row. Each step adds delay, and downtime doesn't wait for the paperwork. By the time the row is written, the loss is already counted.

But here's the part I keep coming back to: the machine already knows it stopped. We don't need a person to notice and write it down; we need the event itself to raise its hand. That's what an event-driven workflow does, and this post shows how to build one in FlowFuse that handles all three jobs on its own: detecting a stop the instant it happens, escalating alerts based on how long it lasts, and writing accurate, timestamped records without anyone touching a spreadsheet. (If event-driven architecture is new to you, [read this article](https://flowfuse.com/blog/2026/02/what-is-event-driven-architecture-in-manufacturing/) first.)

## How It Works: Detect, Escalate, Record

The process begins the instant a machine stops, not when a person notices. A sensor or PLC detects the halt and generates an event, timestamped to the second. That event is passed to a rules layer, which holds the core logic of the system, evaluating the duration of the stoppage against predefined thresholds to decide what happens next.

If the stoppage is brief, under two minutes, say, it's logged as a routine changeover and nothing further happens. Cross that threshold, and the event escalates to the line supervisor. Still unresolved after the next interval, and maintenance gets the same alert. Past that point, it climbs further up the management chain. Each escalation fires automatically, based purely on whether the previous step was closed out in time, with every handoff timestamped as it happens. No one has to remember to log anything.

```mermaid
flowchart TD
    A[Catch the stop signal<br/><i>PLC via OPC UA / Modbus</i>] --> B[Track time down<br/><i>Timer nodes mark windows</i>]
    B --> C{Branch by severity<br/><i>Switch node routes</i>}
    C -->|Under 2 min| D[Logged as changeover]
    C -->|Past 2 min| E[Notify supervisor]
    C -->|Past 10 min| F[Escalate maintenance]
    F --> G[Still down<br/><i>Climb management chain</i>]
    D --> H[(Database: timestamped log)]
    E --> I[Close the record<br/><i>Running message writes start, escalations, end</i>]
    G --> I
    I --> H
    classDef indigo fill:none,stroke:#3B82F6,stroke-width:1.5px,color:#1D4ED8;
    classDef indigoDashed fill:none,stroke:#3B82F6,stroke-width:1.5px,color:#1D4ED8,stroke-dasharray:4 3;
    class A,B,C,E,F,G,I indigo;
    class D,H indigoDashed;
```

Here's what that looks like built in [FlowFuse](https://flowfuse.com):

- **Catch the stop signal:** Most PLCs expose machine state through [OPC UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/) or [Modbus](https://flowfuse.com/node-red/protocol/modbus/), and FlowFuse has nodes for both. Point one at the right tag, and the moment the state flips to stopped, it lands in your flow as a timestamped message.
- **Track how long it's been down:** A couple of [timer nodes](https://flowfuse.com/blog/2025/12/node-red-timer/) mark the passage of time: past two minutes, past ten, whatever windows fit your line.
- **Branch by severity:** A switch node routes the message: short stops go straight to a [database](https://flowfuse.com/blog/2025/08/getting-started-with-flowfuse-tables/); longer ones also notify the supervisor over [email](https://flowfuse.com/node-red/notification/email/) or [Telegram](https://flowfuse.com/node-red/notification/telegram/); and if it's still unresolved at the next threshold, maintenance gets the same message, escalating further up if needed.
- **Close the record:** When the "running" message comes through, a final node writes the resolution time back into that record: start, every escalation, and end, all filled in by the flow itself.

Set this up once per line in FlowFuse, and it keeps running on its own. The spreadsheet still exists, but now it's the output, not the task.

## What You Recover Once It's Running

The stakes here aren't abstract. Unplanned downtime typically runs [[[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[25]{.mord}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[000]{.mord}[p]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[h]{.mord.mathnormal}[o]{.mord.mathnormal}[u]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[or]{.mord.mathnormal style="margin-right:0.0278em;"}[mi]{.mord.mathnormal}[d]{.mord.mathnormal}[]{.mspace style="margin-right:0.2222em;"}[−]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[s]{.mord.mathnormal}[i]{.mord.mathnormal}[z]{.mord.mathnormal style="margin-right:0.044em;"}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[pl]{.mord.mathnormal style="margin-right:0.0197em;"}[an]{.mord.mathnormal}[t]{.mord.mathnormal}[s]{.mord.mathnormal}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[c]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[imbin]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[p]{.mord.mathnormal}[a]{.mord.mathnormal}[s]{.mord.mathnormal}[t]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex}500,000 per hour for large operations](https://manufacturingleadgeneration.com/manufacturing-downtime-statistics/){rel="&#x22;nofollow&#x22;"}, and [Siemens' research](https://assets.new.siemens.com/siemens/assets/api/uuid:1b43afb5-2d07-47f7-9eb7-893fe7d0bc59/TCOD-2024_original.pdf){rel="&#x22;nofollow&#x22;"} found that while the number of downtime incidents per month has fallen in recent years, average restart time has nearly doubled, from 49 minutes to 81 minutes. That's the gap this workflow targets: not how often machines stop, but how long it takes for the right person to find out and act.

A manual log can't see that gap at all. If a stop lasts 81 minutes, the spreadsheet just shows "down for 81 minutes," with no way to tell whether 5 of those minutes were detection, 30 were waiting for someone to notice and write it down, and 46 were the actual repair. With event-driven timestamps, each becomes its own measurable interval: stop detected at 9:14:32, supervisor notified at 9:16:32, maintenance escalated at 9:24:32, resolved at 9:31:08. Three different problems with three different owners and three different fixes, instead of one number you can't act on. And since downtime is one of the core inputs to your [OEE calculation](https://flowfuse.com/blog/2026/05/fixing-oee-measurement-in-manufacturing/), inaccurate downtime data doesn't just stay in this spreadsheet; it quietly distorts the availability number your whole plant uses to judge performance.

That gap has a direct dollar value, and it's worth being precise about which part. Faster escalation doesn't make the repair shorter, a seized motor takes just as long to fix whether the supervisor hears about it in one minute or thirty. What it shrinks is the waiting: the detection and notification minutes that happen *before* anyone starts working. For a mid-sized plant at [[]{.katex-mathml}[[[]{.strut style="height:1em;vertical-align:-0.25em;"}[25]{.mord}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[000/]{.mord}[h]{.mord.mathnormal}[o]{.mord.mathnormal}[u]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[e]{.mord.mathnormal}[a]{.mord.mathnormal}[c]{.mord.mathnormal}[h]{.mord.mathnormal}[o]{.mord.mathnormal}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[ose]{.mord.mathnormal}[min]{.mord.mathnormal}[u]{.mord.mathnormal}[t]{.mord.mathnormal}[es]{.mord.mathnormal}[i]{.mord.mathnormal}[s]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[or]{.mord.mathnormal style="margin-right:0.0278em;"}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[ug]{.mord.mathnormal style="margin-right:0.0359em;"}[h]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[y]{.mord.mathnormal style="margin-right:0.0359em;"}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 415. If automatic escalation removes 10 minutes of pure waiting from a stoppage, that's about [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[4]{.mord}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[000]{.mord}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[eco]{.mord.mathnormal}[v]{.mord.mathnormal style="margin-right:0.0359em;"}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[o]{.mord.mathnormal}[n]{.mord.mathnormal}[t]{.mord.mathnormal}[ha]{.mord.mathnormal}[t]{.mord.mathnormal}[in]{.mord.mathnormal}[c]{.mord.mathnormal}[i]{.mord.mathnormal}[d]{.mord.mathnormal}[e]{.mord.mathnormal}[n]{.mord.mathnormal}[t]{.mord.mathnormal}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[n]{.mord.mathnormal}[o]{.mord.mathnormal}[t]{.mord.mathnormal}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[m]{.mord.mathnormal}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[i]{.mord.mathnormal}[x]{.mord.mathnormal}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[e]{.mord.mathnormal}[ma]{.mord.mathnormal}[c]{.mord.mathnormal}[hin]{.mord.mathnormal}[e]{.mord.mathnormal}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[a]{.mord.mathnormal}[s]{.mord.mathnormal}[t]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[,]{.mpunct}[]{.mspace style="margin-right:0.1667em;"}[b]{.mord.mathnormal}[u]{.mord.mathnormal}[t]{.mord.mathnormal}[f]{.mord.mathnormal style="margin-right:0.1076em;"}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[mn]{.mord.mathnormal}[o]{.mord.mathnormal}[tl]{.mord.mathnormal style="margin-right:0.0197em;"}[e]{.mord.mathnormal}[tt]{.mord.mathnormal}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[i]{.mord.mathnormal}[t]{.mord.mathnormal}[s]{.mord.mathnormal}[i]{.mord.mathnormal}[t]{.mord.mathnormal}[i]{.mord.mathnormal}[d]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[e]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[hi]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[e]{.mord.mathnormal}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[e]{.mord.mathnormal}[a]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[tw]{.mord.mathnormal style="margin-right:0.0269em;"}[or]{.mord.mathnormal style="margin-right:0.0278em;"}[k]{.mord.mathnormal style="margin-right:0.0315em;"}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[i]{.mord.mathnormal}[t]{.mord.mathnormal}[s]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[a]{.mord.mathnormal}[y]{.mord.mathnormal style="margin-right:0.0359em;"}[t]{.mord.mathnormal}[o]{.mord.mathnormal}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[i]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[h]{.mord.mathnormal}[tp]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[so]{.mord.mathnormal}[n]{.mord.mathnormal}[.]{.mord}[A]{.mord.mathnormal}[pl]{.mord.mathnormal style="margin-right:0.0197em;"}[an]{.mord.mathnormal}[tw]{.mord.mathnormal style="margin-right:0.0269em;"}[i]{.mord.mathnormal}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[10]{.mord}[u]{.mord.mathnormal}[n]{.mord.mathnormal}[pl]{.mord.mathnormal style="margin-right:0.0197em;"}[ann]{.mord.mathnormal}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[s]{.mord.mathnormal}[t]{.mord.mathnormal}[o]{.mord.mathnormal}[p]{.mord.mathnormal}[s]{.mord.mathnormal}[am]{.mord.mathnormal}[o]{.mord.mathnormal}[n]{.mord.mathnormal}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[t]{.mord.mathnormal}[ha]{.mord.mathnormal}[t]{.mord.mathnormal}[co]{.mord.mathnormal}[n]{.mord.mathnormal}[s]{.mord.mathnormal}[i]{.mord.mathnormal}[s]{.mord.mathnormal}[t]{.mord.mathnormal}[e]{.mord.mathnormal}[n]{.mord.mathnormal}[tl]{.mord.mathnormal style="margin-right:0.0197em;"}[y]{.mord.mathnormal style="margin-right:0.0359em;"}[c]{.mord.mathnormal}[l]{.mord.mathnormal style="margin-right:0.0197em;"}[oses]{.mord.mathnormal}[a]{.mord.mathnormal}[10]{.mord}[]{.mspace style="margin-right:0.2222em;"}[−]{.mbin}[]{.mspace style="margin-right:0.2222em;"}]{.base}[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[min]{.mord.mathnormal}[u]{.mord.mathnormal}[t]{.mord.mathnormal}[e]{.mord.mathnormal}[w]{.mord.mathnormal style="margin-right:0.0269em;"}[ai]{.mord.mathnormal}[t]{.mord.mathnormal}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[a]{.mord.mathnormal}[p]{.mord.mathnormal}[i]{.mord.mathnormal}[sr]{.mord.mathnormal style="margin-right:0.0278em;"}[eco]{.mord.mathnormal}[v]{.mord.mathnormal style="margin-right:0.0359em;"}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[in]{.mord.mathnormal}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[o]{.mord.mathnormal}[n]{.mord.mathnormal}[t]{.mord.mathnormal}[h]{.mord.mathnormal}[eor]{.mord.mathnormal style="margin-right:0.0278em;"}[d]{.mord.mathnormal}[er]{.mord.mathnormal style="margin-right:0.0278em;"}[o]{.mord.mathnormal}[f]{.mord.mathnormal style="margin-right:0.1076em;"}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 40,000 a month. The exact figure depends on how much of your downtime is waiting versus repair, which is the point: until you measure the two separately, you're guessing.

I want to be precise here: this isn't a fix for unreliable equipment. Machines will still break, and the repair still takes as long as it takes. What it fixes is the waiting, the minutes between a stop and someone acting on it, which a spreadsheet can never shrink because it only gets written after those minutes are already gone.

Set up once per line, the workflow catches every stop the instant it happens, escalates on a fixed schedule from supervisor to maintenance to up the chain with no manual steps, splits a vague "down for 81 minutes" into separate detection, waiting, and repair intervals you can act on, and recovers the waiting minutes that for most plants add up to real money per incident. The spreadsheet still exists. Now it's the output, not the task, accurate, self-maintaining, and running on every shift without anyone having to remember a thing.


# FlowFuse 2.31: Agentic Development Now in Open Beta, FlowFuse Expert Builds Your Industrial App on Edge Devices

FlowFuse 2.31 lets FlowFuse Expert build your industrial application for you, now in open beta. Describe what you need, and Expert assembles it on your workspace.

## Let FlowFuse Expert build your industrial application

*FlowFuse Expert is our integrated AI assistant, in the website, the platform, and the immersive Node-RED editor.*

Describe what you want to build, an OEE dashboard, an MES handover screen, a UNS topic mapping, and FlowFuse Expert assembles the flow on your workspace for you. With 2.31 this moves out of soft launch into an open beta: switched on for your team on FlowFuse Cloud, no request needed. On Self-Hosted Enterprise, [contact us](https://flowfuse.com/contact-us/) to get it set up; self-hosted setup is not automatic, it requires a provisioning token and configuring the bridge.

It now works on Remote Instances as well as Hosted Instances, so you get the same build-it-for-me experience across both. Agentic flow building requires the nr-assistant plugin at v0.16.0 or newer, and FlowFuse Expert will let you know when an update is available in your instance's immersive editor.

## Certified Nodes for industrial connectivity and AI

FlowFuse now offers certified nodes: vetted, FlowFuse-supported nodes you can add to your instances. At launch you can get:

- **RTSP**: bring live video streams into your flows, like camera feeds for monitoring, inspection, or feeding frames into a vision or AI pipeline.
- **OPC UA**: connect to your industrial equipment, the standard for talking to PLCs, SCADA systems, and machines on the plant floor.
- **AI nodes**: call leading AI models straight from your flows, with more providers following soon:
  - Anthropic
  - OpenAI
  - Gemini
  - Ollama, for models you run yourself
  :brThese first LLM nodes handle single-shot, text-in/text-out calls; see the [LLM nodes documentation](https://flowfuse.com/node-red/flowfuse/ai/llm-nodes/) for details. Multimodal input, conversation history, and tool calling are planned for follow-up iterations. They join the FlowFuse AI Nodes package we [shipped in 2.23](https://flowfuse.com/changelog/2025/10/onnx-nodes/), which already includes the ONNX Inference, Image Classification, Object Detection, and Image Depth Estimation nodes for running vision and custom models on-device, with no external API calls.

Certified Nodes are available to FlowFuse Cloud customers as of this release, with Self-Hosted Enterprise support arriving in the next release (2.32). [Get in touch with sales](https://flowfuse.com/contact-us/?subject=Certified%20Nodes) or your customer success manager, and we'll enable the ones your team needs.

## What else is new?

- **Control over where AI runs:** FlowFuse Cloud enables AI by default and you can toggle it per team. For Self-Hosted Enterprise, it is opt-in configurable for the platform via the `ai.enabled` configuration option. Once enabled, the same per team control is possible.
- **Custom CA certificates** are now documented for environments that need them.
- **Smaller fixes**: secure (`wss://`) connections to your MQTT broker now work from the editor, and custom packages with uppercase names no longer break pipeline deploys.

## A quick note from our team off-site in Greece

We spent part of this cycle together in Greece for a full-company off-site, and it shaped what you see (and do not yet see) in 2.31.

![The FlowFuse team in Greece](https://flowfuse.com/blog/2026/06/images/offsite-team.jpg)

Getting everyone in one place let us reset our roadmaps and how we work, the kind of introspection that is hard to do day-to-day and fully remote. It is also why 2.31 is lighter on big features: a lot of this month went into foundational groundwork for what is coming next. We will share more soon.

---

For detailed breakdowns of each feature with additional visuals, visit our [changelog](https://flowfuse.com/changelog/). For the complete list of everything included in FlowFuse 2.31, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases){rel="&#x22;nofollow&#x22;"}.

If something in this release improves your workflow, or if there is still friction we can remove, please [share feedback or report issues regarding this release](mailto\:contact@flowfuse.com?subject=Feedback%20on%202.31) with us.


# MQTT vs Sparkplug B: Which One (or Both) Do You Need?

MQTT is everywhere in industrial setups. It has been the default for moving sensor data and machine states around for a long time now, mostly because it's lightweight and it just works on almost anything.

The catch is that it doesn't really tell you anything about the data itself. Say a broker gets a message on `plant1/line4/temp` with a value of `72`. Is that Celsius? Fahrenheit? Is the device still running, or did it go offline a few hours ago and that's just the last number it sent? MQTT won't tell you. It moves the bytes and the rest is up to you, which means everyone ends up handling it their own way.

That's the problem Sparkplug B tries to solve. It adds the structure that plain MQTT leaves out, so your data actually makes sense to something like a SCADA system without you having to write custom code for every device.

So do you need one, the other, or both? That's what this post is about.

## MQTT vs Sparkplug B at a glance

|                      | Plain MQTT                                  | Sparkplug B                                                                          |
| -------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------ |
| What it is           | A lightweight transport for moving messages | A specification layered on top of MQTT                                               |
| Topic structure      | You define your own                         | Fixed, standardized namespace                                                        |
| Payload format       | Anything you want, usually JSON             | Binary Protocol Buffers, defined schema                                              |
| Device state         | Not built in; roll your own heartbeat       | Birth and death certificates out of the box                                          |
| Bandwidth            | Heavier, especially with JSON               | Compact; report-by-exception cuts traffic sharply                                    |
| Delivery guarantee   | Pick your QoS: 0, 1, or 2                   | QoS 0 for all data and lifecycle messages ("fire and forget"); host STATE uses QoS 1 |
| Readable on the wire | Yes, if you use JSON                        | No, needs tooling to decode                                                          |
| Best fit             | Small or custom setups, data you can't lose | Many devices, multiple vendors, SCADA and analytics                                  |

The rest of this post unpacks why each row lands where it does.

## A pattern that repeats

There's a story that plays out on a lot of teams, and in my experience it goes roughly the same way every time.

A team starts with plain MQTT because it's the obvious choice. A handful of PLCs and sensors, JSON payloads, a broker like Mosquitto in the middle, and a dashboard reading off it. It works. Then the system grows, more lines, a second site, new people, and as it grows it starts to strain in three specific places. Those three places are worth walking through, because they're the same three gaps almost everyone hits, and they're exactly what Sparkplug B was designed to close.

## Where plain MQTT starts to hurt

It's worth hearing this from the person who built it. [Arlen Nipper](https://element8.co.za/Resources/arlen-nipper-co-inventor-of-mqtt-shares-his-incredible-journey-and-his-vision-for-iiot/){rel="&#x22;nofollow&#x22;"} co-invented MQTT and later wrote the Sparkplug specification, and he's blunt about the trade-off at the heart of the protocol:

> Both the good and the bad thing about MQTT is, you can publish anything you want on any topic.

That freedom is why MQTT spread, and it's also where the strain comes from once you scale. It tends to show up in three specific places.

The first strain is payload bloat. JSON is easy to read, which is why people reach for it, but it isn't efficient. A single temperature reading written as `{"sensorId":32,"sensorValue":24.5}` is around 36 bytes when the actual data is a handful. That feels like nothing until you're pushing thousands of tags a second, and then it adds up fast.

The second is structure, or the lack of it. MQTT doesn't define any topic layout, so every integration team invents its own conventions. One group publishes temperature to `line2/temp`, another to `plant/line5/sensors/temperature/value`, and a contractor wires up something nobody can explain later. [Walker Reynolds](https://www.eclipse.org/community/eclipse_newsletter/2021/february/1.php){rel="&#x22;nofollow&#x22;"}, the systems integrator who popularized the Unified Namespace idea, summed up the trade-off:

> Yes, MQTT is flexible, you can basically publish any payload to any topic, but this can create a mess in the topic namespace.

Keeping it all consistent across multiple plants and vendors turns into a constant chore. This is the `plant1/line4/temp` problem from the intro, just multiplied by every team that ever touched the system. Nothing is wrong, exactly, and it all keeps running, but at some point nobody can open the broker and understand the whole thing anymore. (If you're working through how to impose order on a sprawling MQTT setup, [getting the most out of MQTT for industrial IoT](https://flowfuse.com/blog/2024/11/getting-the-most-out-of-mqtt-for-industrial-iot/) goes deeper on this.)

The third strain is the one that quietly causes the most trouble: state. If a device drops offline, it isn't always obvious. Plain MQTT will happily show you the last value a sensor published, steady as anything, long after the sensor itself has gone dark. Teams end up bolting on their own heartbeat logic just to answer the question "is this device actually alive?" There is a built-in MQTT feature that helps, the Last Will and Testament, where a client registers a message that the broker sends automatically if the connection drops, but you have to set it up yourself on every device, and plenty of setups never get around to it.

For small projects and proofs of concept, none of this matters and plain MQTT is completely fine. The cracks only show when you scale, twenty-plus lines or multiple sites, which is right about when teams start looking at Sparkplug B.

## What Sparkplug B changes

Sparkplug B is a specification that sits on top of MQTT, [governed by the Eclipse Foundation](https://sparkplug.eclipse.org/specification/version/3.0/documents/sparkplug-specification-3.0.0.pdf){rel="&#x22;nofollow&#x22;"}, and built specifically for industrial use. It doesn't replace MQTT, it adds the conventions MQTT deliberately leaves out: a fixed topic structure, a defined binary payload format using Google Protocol Buffers, and built-in device state. Look at what each one does for the three problems above.

For the structure problem, Sparkplug defines the topic layout so no team gets to invent its own. Every topic starts with `spBv1.0` to mark the version and encoding, then a group ID that bundles your edge nodes, usually by plant or site, followed by the message type, the edge node ID, and the device ID. The rigidity is the point. Onboarding a new line gets faster simply because everyone already speaks the same language.

For the bloat problem, the binary Protobuf format is far more compact than JSON. Protobuf payloads typically run 60 to 75% smaller than the equivalent JSON for the same data, since it drops the field names, repeated keys, and punctuation that JSON carries and encodes numbers as compact binary instead of text. Sparkplug also lets you batch many tag updates into a single message instead of one message per tag, which cuts broker overhead and network chatter, and it only sends when a value changes rather than polling. That report-by-exception approach, according to the [Eclipse Sparkplug project](https://projects.eclipse.org/projects/iot.sparkplug){rel="&#x22;nofollow&#x22;"}, has been shown to cut network bandwidth by 80 to 95%, though only when the full state management is actually implemented. On constrained links like cellular or satellite, where bandwidth costs real money, that combination adds up quickly. (If you want to see what those binary savings look like in practice, here's a hands-on walkthrough of [optimizing industrial data with Protocol Buffers](https://flowfuse.com/blog/2025/11/optimize-industrial-data-protocol-buffers/).)

For the state problem, Sparkplug uses birth and death certificates. A device publishes a birth certificate when it comes online, listing everything it offers, and a death certificate when it disconnects. So instead of writing custom scripts to guess whether a device is alive, you get that state visible in the SCADA system out of the box. One detail most write-ups blur is worth getting right: the delivery of that death certificate on an unexpected disconnect is handled by MQTT's own Last Will mechanism, not by Sparkplug. Sparkplug defines the meaning and structure; MQTT does the delivering.

The real payoff isn't any single number, it's operational simplicity. Less time spent troubleshooting whether a device is alive or decoding someone else's topic scheme, and more time on the actual process.

## The QoS catch

Sparkplug B carries a trade-off that rarely makes it into the comparison posts, and to my mind it's a serious one.

The [Sparkplug B spec mandates QoS 0](https://github.com/eclipse-sparkplug/sparkplug/blob/master/docs/normative_statements.md){rel="&#x22;nofollow&#x22;"} for all data and lifecycle messages, the NBIRTH, DBIRTH, NDATA, DDATA, NDEATH, and DDEATH messages that carry your actual telemetry and device state. The one exception is the Primary Host Application's STATE message, which uses QoS 1 so host availability is signalled reliably. But for the data you care about, QoS 0 means "fire and forget." The publisher sends a message and moves on, with no delivery guarantee. In theory that's maximum speed. In practice, if the network hiccups or the broker restarts, that data is gone. For a real-time dashboard, fine. For a regulated environment where every reading has to be accounted for, that's a genuine risk. Plain MQTT, by contrast, lets you pick your quality of service: QoS 0, QoS 1 for "at least once," or QoS 2 for "exactly once." If you can't afford to lose data, you choose a higher level and pay for it in some performance.

The other costs are smaller but real. The binary payload that saves you bandwidth is also harder to debug, since you can't just read it off the wire without the right tooling. And teams used to sending plain JSON have a learning curve to climb: topic conventions, birth and death messages, protobuf schemas. For a handful of sensors, that overhead isn't worth it. Plain MQTT is simpler and does the job.

## How to choose between MQTT and Sparkplug B

If you want a way to work through the decision rather than a verdict, run your situation past these in order.

1. **Map your scale and who touches the system.** Count devices, sites, teams, and vendors. A single site with a handful of sensors you fully control points to plain MQTT; many devices across multiple teams or vendors points toward Sparkplug B.
2. **Decide whether you can tolerate losing a message.** Sparkplug B mandates QoS 0, fire and forget, for all data and lifecycle messages, with no delivery guarantee. If your data is regulated or safety-critical and every reading must be accounted for, use plain MQTT with a higher QoS level.
3. **Audit your topic naming.** If teams are each inventing their own topic conventions and nobody can read the broker at a glance anymore, that disorder is the signal that Sparkplug B's fixed namespace is worth adopting.
4. **Check your bandwidth and network conditions.** On constrained or costly links such as cellular or satellite, Sparkplug B's compact binary payloads and report-by-exception cut traffic meaningfully. On a fast local network the difference matters less.
5. **Look at what consumes the data downstream.** If a SCADA system, historian, or analytics layer must understand the data without custom integration for every source, Sparkplug B's self-describing payloads pay off.
6. **Consider running both.** Match each protocol to the data it carries: Sparkplug B for the bulk of telemetry, plain MQTT with higher QoS for the critical data that cannot be lost.

## MQTT, Sparkplug B, or both

Run those steps and a shape usually emerges. Plain MQTT fits when you control both ends, want flexibility, or genuinely cannot lose a message and need a higher QoS than Sparkplug allows for data: small deployments, prototypes, regulated data with strict traceability. Sparkplug B earns its complexity when many devices and vendors feed something downstream that has to understand the data on its own, and the odd dropped reading isn't a catastrophe: real-time dashboards, OEE, non-critical analytics.

And often the honest answer is both. The pattern I've seen at larger manufacturers is to run Sparkplug B for the bulk of their telemetry and fall back to plain MQTT with higher QoS, or another protocol entirely, for the critical data that absolutely cannot be lost. They aren't really competitors. They're the same foundation with different amounts of structure and different guarantees, and the smart move is matching each to the data it's carrying.

Whichever way you land, the next step is wiring it up. If you're building on FlowFuse, here are practical guides for [using MQTT in FlowFuse](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/) and for [using MQTT Sparkplug B with FlowFuse](https://flowfuse.com/blog/2024/08/using-mqtt-sparkplugb-with-node-red/).


# Node-RED 5 Is Here: What It Means for Industrial Teams

Node-RED 5.0 is out, the biggest change to the editor since the project began. Nick O'Leary, our CTO and Node-RED's co-creator, [announced it today on the Node-RED forum](https://discourse.nodered.org/t/node-red-5-now-available/101239){rel="&#x22;nofollow&#x22;"}.

## What's new

Node-RED 5 is the first release built around the editor itself. Previous major versions focused on the runtime and what Node-RED could connect to. This one reworks the place people spend their whole day.

![The redesigned Node-RED 5 editor showing the new sidebars and Explorer panel.](https://flowfuse.com/blog/2026/06/images/node-red-5.png)&#x2A;The Node-RED 5 editor, redesigned around the place teams spend their whole day.*

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

The **redesigned sidebars** now behave the same on both sides of the editor. Controls are grouped together instead of buried in a menu, and you can split one vertically to keep two panels open at once. A new **Explorer panel** gives you a structured view of your flows, making large projects with dozens of tabs far easier to navigate. And a **built-in dark theme** now ships in core, with no custom packages needed, alongside an accessibility review of the default theme.

![The Node-RED 5 editor in its built-in dark theme.](https://flowfuse.com/blog/2026/06/images/nr-dark-theme.png)&#x2A;The built-in dark theme now ships in core, with no custom package to install.*

Underneath the visual changes are functional and security improvements across debugging, authentication, and TLS, the parts that matter most once Node-RED is running in production. If previous releases expanded what it could do, this one sharpens how it feels to use. For the full list, read the [release blog](https://nodered.org/blog/2026/06/09/version-5-0-released){rel="&#x22;nofollow&#x22;"}.

## What it means for industrial teams

The editor is where your team spends its day, so changes here add up fast across a working week.

Most of what's new pulls in the same direction: less time fighting the tool, more time on the flow. The Explorer panel gives you a structured view of the whole project, so a flow set that spans dozens of tabs across several developers stops being a scavenger hunt. Picking up an unfamiliar flow, or onboarding someone new to it, takes seconds. The redesigned sidebars cut friction the other way: controls sit in the same place on both sides, and splitting one vertically keeps your debug output and node config open at once, so there are fewer clicks between the thing you're building and the thing telling you whether it works.

For teams running long sessions on a plant floor or in a control room, the built-in dark theme, now in core with no custom package to install and maintain, and the accessibility review of the default theme mean a readable, lower-strain interface out of the box.

## FlowFuse Management and AI-Powered Flow Building, Now with Node-RED 5

Node-RED is an editor and runtime. Operating it across teams, sites, and production environments is a different challenge entirely.

FlowFuse provides the platform capabilities industrial teams need to run Node-RED at scale: team collaboration, role-based access control, version control and deployment pipelines, SSO, audit logs, TLS-enabled instances, self-hosted and air-gapped deployments, and SOC 2 compliance.

The Node-RED 5 stack is available on FlowFuse Cloud today, allowing teams to take advantage of the redesigned editor, Explorer panel, built-in dark theme, and the latest platform improvements as soon as they upgrade their instances.

Alongside Node-RED 5, FlowFuse continues to improve how teams build applications. With the [FlowFuse 2.31 release](https://flowfuse.com/blog/2026/06/flowfuse-release-2-31/#let-flowfuse-expert-build-your-industrial-application), FlowFuse Expert introduced agentic application building in open beta. Describe your application requirements in plain language, and FlowFuse Expert generates a working starting flow directly in your workspace for both Hosted and Remote Instances.

![FlowFuse Expert generating a starting flow in a Node-RED 5 workspace from a plain-language prompt.](https://flowfuse.com/blog/2026/06/images/flowfuse-expert-node-red-5.png)&#x2A;FlowFuse Expert builds a working starting flow from a plain-language prompt, now on Node-RED 5.*

Teams can take advantage of Node-RED 5's redesigned editor while using FlowFuse to manage, secure, deploy, and scale their applications across production environments.

## Upgrading your instances

Before you start, check one thing for edge hardware: Node-RED 5 needs Node.js 22.9 or later and drops 32-bit ARM, so hardware that can't run a 64-bit OS, such as the Raspberry Pi 3B and earlier, won't run it.

> **Note:** Changing an instance's Node-RED version requires a restart. Your flows won't run while this happens.

To upgrade a FlowFuse Hosted Instance:

1. Open the instance settings.
2. Click the **Change Node-RED Version** button, then select the Node-RED 5 stack from the dropdown.

![The FlowFuse instance settings showing the Node-RED 5 stack selected from the version dropdown.](https://flowfuse.com/blog/2026/06/images/node-red-5-stack-settings.png)&#x2A;Select the Node-RED 5 stack in the instance settings, then apply the change.*

3. Click **Change Node-RED Version**.

That's it. Once the instance restarts, you'll be running Node-RED 5 and can start using the redesigned editor, Explorer panel, built-in dark theme, and the latest platform improvements immediately.

To avoid having to manually update your instances in the future, enable automatic stack updates. For production deployments, FlowFuse's [Scheduled Maintenance](https://flowfuse.com/changelog/2025/12/scheduled-maintenance/) feature lets you control when updates and restarts are applied, ensuring changes are rolled out during planned maintenance windows.


# OPC UA Security: How to Establish a Defensible OPC UA Security Architecture

In [Part 1](https://flowfuse.com/blog/2026/05/opc-ua-security-attack-vectors/), we watched how threat actors actually exploit OPC UA. None of it was broken cryptography. It was disabled trust lists, anonymous logins, dead ciphers nobody removed, and servers Shodan finds on the open internet. The protocol shipped with the tools to stop every one. The attacks worked because the tools were switched off.

This is the part where we switch them on, not as a checklist, but as an architecture where each decision closes a specific vector from Part 1. The order matters, because the cheapest fixes close the widest holes.

## The model that decides everything else

Part 1 named the trap that sinks more deployments than any zero-day: OPC UA splits *application* authentication (does the server trust this client's certificate?) from *user* authentication (who is this operator, and what may they do?). Teams harden one, leave the other open, and believe they're covered.

The reason this confuses people is that OPC UA secures the **messages themselves**, not just the transport beneath them. A transport-only scheme like TLS protects the pipe between two hosts; OPC UA signs and encrypts each message independently of the transport, so a receiver detects a tampered process value even on a hostile network and even if the transport is something other than TLS. Application authentication and message security are layers in their own right, sitting above whatever carries the bytes.

Two facts fall out of this, and both map straight to Part 1's attacks:

- **Every application instance has its own certificate**, not every host, every *running process*. A Node-RED client, a SCADA server, and a historian on the same box each carry their own.
- **Authentication is mutual.** Both sides present a certificate, both sides decide whether to trust. There is no "the server has a cert, the client just connects" shortcut like HTTPS. The machine-in-the-middle attacks CISPA demonstrated work *precisely* when that mutual check is advertised but not enforced.

Hold onto the second point. Almost every control below is a way of making that mutual check real instead of decorative.

![Application authentication and user authentication are two separate checks on the same OPC UA session.](https://flowfuse.com/blog/2026/06/images/opcua-application-vs-user-authentication.png)&#x2A;OPC UA authenticates the software and the operator as two separate checks, not one.*

## Stop accepting inbound connections at all

Part 1 opened with the worst number: 14,220 internet-exposed servers, more than half allowing unauthenticated access. The instinct is to bolt authentication onto an exposed server. The better move is to stop the server from accepting inbound connections in the first place.

OPC UA has a protocol feature built for exactly this, and most "best practices" posts never mention it: **Reverse Connect**. Normally a client opens the TCP connection to a server. Reverse Connect inverts that, the *server* dials out to the client and sends a `ReverseHello` message (OPC UA Part 6), and the client establishes the secure channel over that server-initiated socket. The handshake and all mutual authentication proceed exactly as before; only the direction of the initial TCP connection flips.

![Traditional connect requires an open inbound port; Reverse Connect has the server dial out so the firewall stays closed.](https://flowfuse.com/blog/2026/06/images/opcua-reverse-connect-vs-traditional.png)&#x2A;Reverse Connect inverts the initial TCP connection so the firewall stays closed. Only the socket origin flips, the client still drives the OPC UA session.*

Why this matters architecturally: the server sits in the production zone behind a firewall with **no inbound ports open**. From the firewall's perspective the traffic is outbound, the one direction it already permits. A SCADA client or edge gateway in the DMZ listens on a single port; each downstream server connects out to it. You get bidirectional OPC UA communication while the production-network firewall stays completely closed to the outside.

This is the structural fix that makes Part 1's exposure problem disappear rather than merely guarding it. Layer it inside normal defense in depth, the zone-and-conduit segmentation IEC 62443 calls for:

- **Segment the network.** Control network separate from enterprise, firewalls between zones. A typical layout: `SignAndEncrypt` from the enterprise zone (historians, MES, ERP), through a DMZ of edge gateways and protocol bridges, down to a plant floor where PLCs and HMIs sit on isolated VLANs.
- **Put a security gateway in the DMZ.** A gateway can terminate Reverse Connect on both sides and act as the single, aggregating access point to the plant, the only door, and one you control.
- **Keep the single-port design as leverage, not a license.** OPC UA's standard TCP 4840 keeps firewall rules clean. Clean rules are what let you *not* expose the server, not an excuse to.

Vendors agree on the bottom line. Siemens, Schneider, and Rockwell all explicitly advise against putting these servers on the open internet. Reverse Connect is how you comply without losing IT/OT data flow.

![A segmented network with Enterprise, DMZ, and Plant Floor zones separated by firewalls, with SignAndEncrypt links between them.](https://flowfuse.com/blog/2026/06/images/opcua-defense-in-depth-network-zones.png)&#x2A;OPC UA security sits inside a segmented, defense-in-depth network.*

## Make the trust list actually enforce

This was Part 1's ugliest vector, because the servers *look* secure, they advertise certificate authentication, they just don't enforce it. CISPA tested 48 products and found the failures clustered in trust list handling: missing support, disabled by default, insecure configuration. Here is how the trust check works, and the two settings that quietly defeat it.

When a peer presents a certificate, a correct implementation validates it against three local stores:

- **Trusted store**, certificates (or a CA root) you've explicitly chosen to trust.
- **Issuer store**, intermediate and root CA certificates plus their Certificate Revocation Lists (CRLs), used to walk and verify the chain.
- **Rejected store**, where unknown certificates land on first contact, *pending an administrator's decision*. Nothing here is trusted.

The intended workflow is deliberate friction: an unknown peer's certificate drops into the rejected store, an administrator inspects it, and only then moves it to trusted. That manual approval *is* the security. Two things destroy it:

![Flowchart: a presented certificate is checked for trust, its chain validated, and accepted or refused, with admin approval promoting rejected certificates for the next connection.](https://flowfuse.com/blog/2026/06/images/opcua-certificate-trust-validation-flow.png)&#x2A;Trust nothing by default: certificates enter the trusted store only by explicit approval.*

1. **"Automatically accept all certificates."** Almost every server has this toggle, Siemens TIA Portal, node tooling, test harnesses. It's there to get you past the handshake during commissioning, and it is the single most common reason a "secure" connection is actually wide open. A server set to auto-accept has, in effect, the disabled trust list from Part 1. This default is common enough that even purpose-built Node-RED OPC UA clients often ship with server certificates auto-accepted out of the box, convenient for testing, dangerous in production. Turn it off before production. Every time.
2. **Trusting a commercial public CA's root.** If you drop a public CA into your trusted store, that CA, not you, decides which applications your systems trust. For OPC UA you want a **company-specific CA** whose root you control, or explicit per-application trust. Never a public one.

The concrete mechanic trips up everyone the first time, so it's worth being literal. To let a Node-RED OPC UA client talk to a Siemens S7 server over `SignAndEncrypt`, you copy the client's certificate (in node-based tooling it's typically `PKI/own/certs/client_certificate.pem`) into the *server's* trusted folder, and copy the server's certificate into the *client's* trusted store. Both ends, both directions, because authentication is mutual. Miss one side and you get the "connection could not be established" error that fills the Node-RED forums, almost always because one party doesn't yet trust the other.

The governing rule: &#x2A;*trust nothing by default.** A certificate enters the trusted store only through explicit, human approval. That is the control CISPA kept finding switched off.

## Force SignAndEncrypt, and rip the deprecated ciphers out

Part 1's Secura research and the CVEs behind it all traced to one root cause: known-weak crypto left switched on in non-default configurations. You close this by removing the option, not by hoping nobody selects it.

**Set the security mode deliberately.** Endpoints advertise a *mode* and a *policy*. The mode is one of three:

- `None`, no signing, no encryption, everything in plaintext. This is the "None" mode 80% of Part 1's exposed servers still offered. Disable it, or bind it to localhost-only diagnostics.
- `Sign`, every message signed but not encrypted. Integrity and authenticity without confidentiality. Use only where you've consciously decided the data is non-sensitive but you still must detect a forged value.
- `SignAndEncrypt`, signed *and* encrypted: integrity, authenticity, and confidentiality together. The answer for anything carrying process data or accepting commands.

**Then remove the dead policies.** `Basic128Rsa15` and `Basic256` are deprecated, the OPC Foundation retired them in spec 1.04 because they lean on SHA-1 and RSA key lengths that no longer meet NIST or BSI guidance, and IEC 62443 and the NIST CSF explicitly flag them. `Basic128Rsa15` is the exact policy behind Part 1's CVE-2024-42512 and CODESYS's CVE-2025-1468 Bleichenbacher oracle. If a server *only* offers these, that's a firmware-update conversation, not a config tweak.

For anything new, `Basic256Sha256` is the floor; the modern policies `Aes128_Sha256_RsaOaep` (faster) and `Aes256_Sha256_RsaPss` (strongest available) are better. The trade-off is backward compatibility, older devices won't speak the newer suites, so the realistic migration is `Basic256Sha256` as the enforced minimum while you push the fleet forward and decommission the deprecated suites as you go. The point is that an attacker can't downgrade to a broken cipher you've physically removed.

## Separate who-the-software-is from who-the-operator-is

Application authentication, handled above, proves *which software* connected. It says nothing about *who* is driving the session. Part 1's anonymous-access vector only fully closes when you enforce both layers, and as Part 1 noted, anonymous *user* access is far less dangerous when *application* authentication is genuinely enforced, and far more dangerous when it isn't.

User authentication options, weakest to strongest:

- **Anonymous**, acceptable only for read-only, non-sensitive dashboards. Never write access, never diagnostics.
- **Username / password**, fine, but only over a `SignAndEncrypt` endpoint, or you've just shipped credentials in plaintext.
- **User X.509 certificate**, strongest, and the natural fit for machine-to-machine.

Then constrain what an authenticated identity can do. Implement &#x2A;*role-based access control from day one.** Running every application with administrator rights is the oversized blast radius Part 1 warned about, one compromise and the attacker owns the read-and-write path to the process. Assign read, write, and browse separately, per role, least privilege. If a server can't enforce granular access itself, put a gateway in front that can.

## Manage certificates like infrastructure, not a one-time chore

The trust mechanics above assume certificates that are valid, unique, and revocable. At one connection, manual exchange is fine. At a hundred it collapses, and that collapse is what produces the 20-year self-signed certs and shared keys Part 1 punished.

Every instance holds an X.509 v3 Application Instance Certificate (IEC 62541 Part 2): application URI as a globally unique ID, public key, issuer identity, validity window, issuer signature. The private key stays secret on the instance, leak it and that certificate must be revoked and replaced, the precise consequence CODESYS described for the Bleichenbacher oracle.

Non-negotiables regardless of scale:

- **One certificate per instance.** Share a certificate and revoking it after one compromise takes down every instance that shared it.
- **2048-bit RSA minimum**, 4096-bit for long-lived (5+ year) certificates.
- **SAN must match the application URI exactly**, or validation fails in maddening, hard-to-diagnose ways.
- **Track expiry like any operational asset.** Field certs carry absurd multi-decade lifetimes precisely because nobody wants to renew. That's deferral, not security. Reminder 60 days out.
- **Handle CRLs.** A trust store without working revocation can't respond to a compromise.
- **Protect the private-key store**, read/write to an administrator or the application only.

**Automate before it hurts.** A &#x2A;*Global Discovery Server (GDS)** with certificate management acts as your CA and directory, issuing, renewing, and revoking across the fleet over standard PKI protocols (CMP, EST) so you're not vendor-locked. It works two ways:

- **Pull management**, the application (usually a client) calls the GDS to request and refresh its own certificate and trust list. It owns keeping itself current.
- **Push management**, the GDS pushes new certificates and trust lists *to* the application (usually a server), which exposes the methods for it. Push requires an encrypted channel and a client holding the `SecurityAdmin` role, and the GDS will only deliver an update over a channel at least as strong as the certificate being updated, it won't push a 4096-bit cert down a 2048-bit channel.

![A Global Discovery Server issuing certificates two ways: applications pull their own, or the GDS pushes certificates and trust lists to servers.](https://flowfuse.com/blog/2026/06/images/opcua-gds-push-pull-certificate-management.png)&#x2A;A GDS automates certificate issuance, renewal, and revocation across the fleet.*

One field tip even with a GDS: keep a local rejected-certificate store on each application, so you can still see and reason about what tried to connect.

If you're building this on FlowFuse, the OPC UA connectivity is available as one of the Certified Nodes introduced in [FlowFuse 2.31](https://flowfuse.com/blog/2026/06/flowfuse-release-2-31/), vetted and FlowFuse-supported rather than pulled unmaintained from the community registry, which is the supply-chain point above made concrete. As with any OPC UA client, confirm it's set to reject untrusted server certificates before you go to production rather than auto-accepting them.

## Keep the audit trail on, and watched

Part 1's quietest, most damning detail: most anonymously reachable servers also had auditing *disabled*, so an attacker connected, read the plant, and left no trace. A silent denial-of-service and a client-side compromise both get worse when nothing is watching.

OPC UA emits rich audit events for security-relevant operations. Turn them on, then make sure something *collects and watches* them, events nobody reads are theatre. This is what turns an undetected man-in-the-middle into an alert and a silent DoS into an incident with a timeline.

## Patch the stack, and especially the gateways

Part 1 closed on a supply-chain truth: one flaw in a shared OPC UA library or sample propagates into every product built on it, and integration servers are rich targets because vulnerabilities *chain*, Team82 strung five bugs together to own a Softing gateway.

So architecture doesn't end at configuration. Track CVEs for your specific stack and gateways. Subscribe to the OPC Foundation security bulletins and your vendors' advisories. Patch the integration servers stitching systems together with the same urgency as the servers themselves, owning one reaches everything behind it. And because the client trusts the server, a client fed bad data by a rogue server is its own vector (Part 1's client-side RCE): client-side updates matter as much as server-side.

## Test what you think you built

The step everyone skips. Verify configuration matches policy:

- Connect *without* a valid certificate, does the server actually reject it, or is auto-accept still on?
- Read and write *without* authorization, does RBAC actually deny it?
- Point a security testing tool at your endpoints and confirm the advertised modes match the enforced ones.

A trust store you've never tested is a hypothesis, not a control, and Part 1 is a catalogue of deployments where the hypothesis was wrong.

## The blueprint, in one breath

Every vector in Part 1 had the same root cause: a tool OPC UA handed you that nobody switched on. The architecture is switching them on, in the order of biggest hole for least effort:

1. **Reverse Connect + segmentation**, the server stops accepting inbound connections; the firewall stays closed.
2. **Enforcing trust list, auto-accept off, company CA**, the mutual check becomes real instead of decorative.
3. **SignAndEncrypt, deprecated ciphers removed**, no cipher to downgrade to.
4. **User auth + RBAC on top of application auth**, both layers, least privilege.
5. **One cert per instance, GDS-managed lifecycle**, valid, unique, revocable, at scale.
6. **Auditing on and watched.**
7. **Stack and gateways patched.**
8. **Tested against the policy, not the assumption.**

OPC UA shipped with the strongest security model in industrial protocols. Part 1 showed what it looks like switched off. This is what it looks like switched on, and where FlowFuse fits is making it the default rather than the project: data pulled off exposed, internet-facing servers into a managed, segmented architecture where Reverse Connect, enforced trust, and least-privilege access are how the system is built, not a hardening pass you hope someone remembers to run.


# Historical Data Logging with OPC UA and InfluxDB

Industrial equipment produces data constantly: temperatures, pressures, motor speeds, tank levels, all changing by the second. Real-time values tell you what's happening now, but the history is where the value lives, spotting a degrading pump, proving a batch stayed within spec, tracing the conditions behind a fault. OPC UA gets that data out of your equipment in a vendor-neutral way, and InfluxDB stores it as timestamped history built to query at scale. In this article, you'll connect the two in FlowFuse to turn live readings into a durable record you can query, chart, and analyze.

> **Note:** If you'd rather not leave FlowFuse and want a good time-series database built in, [FlowFuse Tables](https://flowfuse.com/docs/user/ff-tables/) is the answer.

![The finished flow on the FlowFuse canvas: inject → Read (OPC UA) → function → influxdb out](https://flowfuse.com/blog/2026/06/images/opcua-to-influxdb-flow.png)&#x2A;The complete pipeline: an inject node triggers a read, a function node shapes the reading, and the influxdb out node stores it.*

## What you'll need

Before building the flow, make sure you have:

- **A FlowFuse remote instance on an edge device.** OPC UA servers and PLCs sit on the local network, so run this flow on an edge device close to the equipment. Install the [Device Agent](https://flowfuse.com/docs/device-agent/install/overview/) and register it as a remote instance.
- **An OPC UA server to read from.** Your data source: a PLC, gateway, or device exposing tags over OPC UA. No hardware? The free Prosys OPC UA Simulation Server works for testing.
- **A running InfluxDB instance.** Cloud or self-hosted. Create an organization, a bucket, and an API token with write access.
- **Endpoint details for both.** The OPC UA endpoint URL (like `opc.tcp://192.168.1.10:4840`) plus any credentials, and your InfluxDB URL, org, bucket, and token.

For the OPC UA connection, this guide uses the **FlowFuse Edge Certified Nodes package**, part of the **FlowFuse Edge** offering and vetted, maintained, and tested by the FlowFuse team. [Contact sales](https://flowfuse.com/contact-us/) to enable it for your team. Community nodes work too, but they don't get the same vetting, maintenance, or testing, so reliability varies.

With those ready, the next step is installing the nodes that connect FlowFuse to OPC UA and InfluxDB.

## Installing the nodes

You'll install two packages: the InfluxDB nodes and the FlowFuse Edge Certified OPC UA nodes.

1. Open the editor on your remote instance.
2. From the menu (top right), select **Manage palette**, then switch to the **Install** tab.
3. Search for &#x2A;*`node-red-contrib-influxdb`** and click **Install**. These nodes write to and query InfluxDB.
4. Switch the catalog using the top dropdown to **FlowFuse Edge Certified Nodes**. Once sales enables FlowFuse Edge Certified Nodes for your team, this catalog shows up here; restart any existing instance so it picks up the updated catalogue.
5. Search for &#x2A;*`@flowfuse-certified-nodes/opcua`** and click **Install**. See the [OPC UA node documentation](https://flowfuse.com/node-red/flowfuse/edge/opcua/) for the full node set and configuration options.

![Manage palette Install tab showing the OPC UA certified package in search results](https://flowfuse.com/blog/2026/06/images/opcua-manage-pallete.png)&#x2A;Install the OPC UA certified package from the FlowFuse Edge Certified Nodes catalog.*

Both packages now appear in the palette on the left: an OPC UA group for reading your equipment, and an InfluxDB group for storing the data. Now you're ready to connect to your server and pull live values.

## Connecting to your OPC UA server

With the nodes installed, you'll build the read side of the flow: define the connection, then read your tag values on a schedule.

### Define the connection

1. Drag a **Read** node onto the canvas.
2. Double-click it to open its settings, then click the "+" next to the **Endpoint** field to add a new endpoint configuration.
3. Enter your endpoint URL, for example `opc.tcp://192.168.1.10:4840`.
4. Set the **Security Policy** and **Security Mode** to match your server. For a local test server such as the Prosys simulator with security disabled, set both to `None`. On production equipment, choose the certificate-based policy and mode your server requires, and point the node at your certificate and private-key files.
5. If your server needs credentials, enable the login option on the endpoint and enter the username and password. Otherwise leave it anonymous.
6. Click **Add**, then **Done**.

![The OPC UA endpoint configuration dialog with URL, Security Policy, and Security Mode fields](https://flowfuse.com/blog/2026/06/images/opcua-config.png)&#x2A;Point the endpoint at your server's URL and match its Security Policy and Mode.*

> **Note:** This guide uses a simulator server for convenience. On production equipment, always enable a certificate-based Security Policy and Mode rather than `None`, so the connection between FlowFuse and your OPC UA server stays encrypted and authenticated.

> **Note:** Store connection details, endpoint URLs, credentials, InfluxDB tokens, org and bucket names in environment variables rather than hardcoding them in your nodes. This keeps secrets out of your flows and lets you move the same flow between instances without editing each node. See [Using Environment Variables](https://flowfuse.com/docs/user/envvar/) for how to set them.

### Read the values on a schedule

The Read node takes the Node ID of the tag from the incoming message, so feed it a message carrying the tag you want and it returns the value. First you need that Node ID, something like `ns=3;s=Temperature`.

1. In the **Read** node, click the tree button next to the **NodeId** field. Enter the Node ID you want to drill into (a root node such as the Objects folder is the usual starting point), and the node renders your server's address space as an expandable tree. Drill down, click the tag you want, and its Node ID fills in automatically.
2. Add an **inject** node and set it to repeat at a fixed interval, say every 5 seconds, so each pulse triggers a fresh read. Wire it into the Read node.
3. Connect a **debug** node to the Read node's output, then deploy.

![Opcua read node config](https://flowfuse.com/blog/2026/06/images/opcua-read-node.png)*Opcua read node config*

Each time a message arrives, the Read node returns more than just the number. The value lands in `msg.payload`, and the message also carries `msg.dataType` (such as `Double` or `Boolean`), `msg.statusCode` (`Good` on success, or an error like `BadUnknownNode`), `msg.sourceTimestamp` and `msg.serverTimestamp` as ISO strings, and `msg.nodeId` echoing back what was read. Watch that `statusCode`, it's how you tell a real `0` reading from a tag that failed to read at all.

To read several tags at once, pass an array of Node IDs in `msg.topic` or `msg.nodeId` and the node returns an array of values in `msg.payload`, more efficient than running a separate read per tag.

> **ℹ Tip:** If you ever need the *flow itself* to discover Node IDs while it's running, say, to enumerate tags on a server whose address space changes, there's a dedicated **Browse** node for that. It's overkill for a fixed set of tags like this one, so we'll skip it here.

Deploy and watch the debug output. You should see a value arriving on each interval. The value itself is in `msg.payload`, while the timestamp and quality ride along on separate properties (`msg.sourceTimestamp`, `msg.statusCode`, and so on), so `msg.payload` is just the bare reading, like `42.5`. That's the shape the next step builds on.

![The debug sidebar showing a reading with msg.payload, msg.statusCode, and msg.sourceTimestamp expanded](https://flowfuse.com/blog/2026/06/images/read-output.png)&#x2A;Each read returns the value in msg.payload, with timestamp and quality on separate properties.*

## Writing Data to InfluxDB

The OPC UA Read node and InfluxDB Out node use different message formats, so add a **Function** node between them to format the data before writing it to InfluxDB.

1. Drop a **Function** node after the Read node and open it.
2. Configure it to build the payload InfluxDB expects. `msg.payload` contains the OPC UA value, and `msg.sourceTimestamp` contains the timestamp from the OPC UA server:

```javascript
const value = msg.payload;

msg.measurement = "equipment_readings";
msg.timestamp = msg.sourceTimestamp;

msg.payload = [
    {
        temperature: value
    },
    {
        sensor: "tank-1",
        location: "plant-floor"
    }
];

return msg;
```

The first object contains the field values, while the second contains tags used for filtering and grouping data during queries.

3. Wire the Function node to an **InfluxDB Out** node.
4. Open the InfluxDB Out node and click the "+" icon next to **Server** to configure the connection. Enter your InfluxDB URL and select the appropriate version (1.x or 2.0).
5. For InfluxDB 2.0, provide your **Token**, **Organization**, and **Bucket**. For InfluxDB 1.x, enter the database name and any required credentials.
6. If you did not set `msg.measurement` in the Function node, specify the measurement name (for example, `equipment_readings`) in the InfluxDB Out node configuration.
7. Deploy the flow.

![The influxdb node configuration with URL and version fields](https://flowfuse.com/blog/2026/06/images/influxdb-config.png)&#x2A;Configure the server connection with your InfluxDB URL and version.*

![The influxdb out node configuration with token, org, and bucket fields](https://flowfuse.com/blog/2026/06/images/influxdb-write-node-config.png)&#x2A;Set the token, organization, and bucket so readings are written to the correct destination.*

Your readings are now flowing into InfluxDB. On each interval, the Read node retrieves the OPC UA value, the Function node formats it, and the InfluxDB Out node writes the timestamped data point to your bucket.

## Verifying your data

Confirm the history is actually landing before you rely on it.

1. Open the InfluxDB UI and go to the **Data Explorer**.
2. Select your bucket, your `equipment_readings` measurement, and the `temperature` field.
3. Set the time range to the last few minutes and run the query.

![InfluxDB Data Explorer showing the temperature filling in](https://flowfuse.com/blog/2026/06/images/influxdb-explorer.png)*InfluxDB Data Explorer showing the temperature filling in*

You'll see your readings listed in a table, one row per read interval. If new rows keep appearing as time passes, your pipeline is working end to end: equipment to OPC UA to FlowFuse to InfluxDB.

Storing data is only half the story. The InfluxDB In node lets you query readings back from InfluxDB, whether you need the latest values, historical trends, or aggregated metrics. You can then feed the results directly into a [FlowFuse Dashboard](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"} to build charts, tables, and real-time monitoring views of your OPC UA data.

## Where to go from here

You now have a durable, queryable record of your equipment's behavior. From here you can read more tags, tag each reading with its machine or line so you can slice the data later, and build dashboards on top of InfluxDB to chart trends and spot the slow drift that real-time values hide.

The real payoff comes when you stop reacting to problems and start seeing them coming. A pump that's drawing a little more current each week, a tank that's taking longer to fill, a temperature that's creeping past its usual range, all of it now sits in a history you can query, instead of vanishing the moment it happens.


# Fixing PLC Communication Latency: Where the Milliseconds Really Go

If you run control over a PLC link, a fast loop, an interlock, a setpoint that has to land on time, the fix usually isn't a faster runtime or a different protocol. It's a handful of settings made once at setup and never revisited, each one quietly costing milliseconds the loop can't spare.

Latency on a PLC link comes from how the data is handled, not the runtime, the network, or the PLC's CPU. Fix those settings, in order, and the timing comes back on its own.

This post follows the time: where a PLC link loses its milliseconds, and how to get each one back.

## First, check if it's even the transport

Following the time means starting at the bottom. Before you change anything, find out which layer is slow. You can spend a day tuning poll rates when the real problem is the protocol shaking underneath you, or the other way around.

The simplest check is a SISO test: single input, single output. Run a tiny exchange straight on the controller, with no PLC logic in the loop, just a line or two of code, and watch it on a scope. If even that bare exchange jumps around from one pass to the next, the problem is the transport itself, not anything you built on top. If the bare exchange holds steady but your real flow doesn't, the time is going somewhere in your data handling. That one test tells you which half of this article to read first.

## The data doesn't change at one speed, and your poll rate shouldn't either

When the test points at your data handling, the first place to look is also where most of the lost time hides. It usually starts with a thirty-second choice: pick a scan rate, use it for every tag, move on. It works on day one, so it stays that way. But one rate is the wrong answer for almost every real system, and a quick calculation shows why.

Take a shared bus with twenty devices, all polled at 500 ms, where each read takes 50 ms. That's not 500 ms per device, it's a queue: twenty reads at 50 ms each is a full second to get through one cycle. By the time you read device twenty, its value is already a second old, and the next cycle hasn't started. You read a slow temperature sensor ten times before its value could have moved, and a fault bit that goes high for 800 ms can fall between two passes and never get seen. One rate ends up too fast for some tags and too slow for others.

The reason it's the wrong model is that the data isn't all one kind. A temperature drifts over minutes. A runtime counter ticks once an hour. An alarm bit can flip in under a second. A setpoint only changes when an operator touches it. Polling all four at the same rate fits none of them, and it wastes the controller's time on the ones that didn't need it.

The fix is to set the rate to how fast the data actually changes:

- **Fast, 100 to 500 ms:** fault and alarm bits, interlocks, values that drive closed-loop control. A missed change here has real consequences.
- **Normal, 1 to 5 seconds:** running values like flow, pressure, temperature, current draw. They change all the time, but not in an instant. A two-second poll catches the trend without flooding the bus.
- **Slow, 30 seconds to a few minutes:** counters, runtime hours, setpoints. They change by operator action, or build up slowly enough that fast polling is pure waste.
- **Once, then cache:** nameplate data, firmware versions, calibration values. Read them at startup and never poll again.

To sort any tag, ask whether a delay changes a control decision or only the timestamp on a record. If it changes a decision, it goes on the fast tier. If it only changes a timestamp, it's telemetry and belongs slower. Then ask how many tags really need the fast path, because it's almost always far fewer than the number on it now. Most points in most systems are reads, and most of those reads are not urgent.

## A timeout is a measurement, not a guess

Once the rates are sorted, the next thing that turns a slow moment into a stall is the timeout, and people usually set it by guessing a round number.

Both directions hurt. Too tight, and the request fails the moment the device is busy. That fires a retry, which adds more traffic to an already busy link, which makes the next request more likely to fail too. Too loose, and the master sits stuck on a dead request far longer than it should, holding up everything behind it. Either way, you've made latency.

The way to set it is to measure the floor and add margin. The floor has three parts: time to send the request, the device's own processing time, and time to send the response back. Take a slow serial device. Eight milliseconds to send, seventy-five for the device to process, twenty-five for the response: about 108 ms before anything has gone wrong. A 100 ms timeout fails that read every time. A 150 ms timeout usually passes but fails under load, which is the worst case because it's hard to catch. A 250 ms timeout gives you real room. Find your floor, multiply by 1.5 to 2, and don't treat the margin as wasted time. It's the difference between a link that holds under load and one that drops frames when the device gets busy. The datasheet gives you a starting number. A protocol analyzer gives you the real one.

## The controller's scan time is borrowed, so spend it deliberately

Rates and timeouts are two settings, but step back and there's a simple idea underneath both. The PLC's first job is running the process, not talking to you. It works through a [fixed scan](https://flowfuse.com/blog/2025/12/what-is-plc/#how-a-plc-works-the-scan-cycle), and communication is squeezed in around the logic that actually drives the machine. Every request you send borrows time from that work. Set your rates and timeouts well and you're spending that borrowed time with care. Three habits waste it.

- **Polling more than you need.** This is the poll rate problem from the controller's side. A big set of points read at a fast rate burns budget on data that didn't need the rate, leaving less room for the data that does. Tiering isn't only about the bus. It gives the scan its time back.
- **Ignoring the connection limit.** Many devices accept only a few connections at once, sometimes as few as one to four. Point too many clients at one device, or fire too many requests at once, and the extras wait in line or get turned away. Over TCP that shows up as connections backing off on a timer that climbs through 250, 500, then 1000 ms. It looks like random network latency, but it's the device turning work away because it ran out of sockets. Know the limit and stay under it.
- **Stacking everything on one protocol.** Most PLCs run each protocol through its own driver and process, with its own share of resources. Put fast control data and high-volume telemetry on the same protocol and they fight over the same driver, so the fast path picks up the load from the slow path. It also helps to know which way each connection opens, whether the controller reaches out or something reaches in, because that changes how the work gets scheduled and what it costs.

## Match the protocol to the data, not the other way around

Even with a driver to itself, none of the protocols a runtime reaches a PLC or device through at this level, the northbound, supervisory layer, are real-time by design. That's true of Modbus TCP, OPC UA, MQTT, and EtherNet/IP's explicit messaging alike. They were built to move data reliably between a supervisory system and a controller, not to guarantee it lands inside a fixed time window. So there's no protocol to crown the winner here, only ones better or worse suited to the job in front of you.

Start with what each one is built for:

- **MQTT** is pub/sub transport, built to move lots of telemetry, wrong for steady sub-loop response.
- **OPC UA** is strong for structured, modeled data and a poor fit for sub-100 ms control.
- **WebSocket** is light and often the quickest of the general-purpose options, but it makes no promise on turn time.
- **Modbus TCP** can hold steady low-millisecond reads in good conditions, but never as a hard promise.
- **EtherNet/IP's explicit messaging** carries structured requests over standard Ethernet and can be tuned to hold a steady turn time, but it's making the same kind of effort the others are, not a different one.

None of these guarantees delivery inside a fixed time window by default. They're non-deterministic at this layer.

The real determinism in a PLC system lives one level down, inside the controller's own I/O scan and the fieldbus underneath it, things like EtherCAT or PROFINET IRT, where timing is enforced by the hardware and the scan cycle itself, cycle after cycle, regardless of what's happening above it. A supervisory runtime doesn't poll that layer and doesn't reach it; it talks to the controller through one of the four protocols above. Treating EtherNet/IP, or any of them, as carrying that hardware-level determinism up to the supervisory layer is where a "pick protocol X and you're guaranteed real-time" claim goes wrong.

So the answer isn't a ranking, it's a method. Pick a protocol the device actually supports and that's well implemented on both ends. Apply the techniques already in this article, tiered poll rates, measured timeouts, a respected scan budget, sampling and timestamping at the source, before touching the protocol at all. Only consider switching protocols if the timing still won't hold after that. Keep the fast path lean either way: carry only the points needed to make the decision, and fetch everything else after the fact from a database or a slower read. Most slow links come from reaching for a protocol swap before doing the work above it.

## The steadiest timing is built at the source, not fixed downstream

Tiering, timeouts, and the work above all cut wasted time. But the steadiest timing comes from a change in where the work happens: do it in the PLC, at the source, instead of trying to fix it downstream over the network.

Start with sampling. If you need a fixed gap between readings, the network can't give it to you. MQTT won't, WebSocket won't, none of them will. Everything past the point where the signal is read is transport, and transport doesn't promise a fixed gap. So build the guarantee in at the source: have the controller sample at a fixed rate as it reads the signal, and stamp each reading with the time it was taken. Once a sample carries its own timestamp, it doesn't matter that the transport delivers it at an uneven pace, because the timing of the measurement is already saved. Trying to fix this by controlling when data lands over the wire is solving it in the wrong place.

That same move fixes the polling load. Instead of reading without pause, let the controller hold telemetry in a buffer and pull the buffer at the slower rate the data actually needs. The controller stops handling requests that never had to happen, and because each reading was already timestamped at the source, the slower, uneven pull never touches the timing of the data.

Then move the buffer in batches, not a trickle. Build an array, say a window of samples, each with a timestamp and value, and write the whole batch to a time-series database at once. These databases are built for batch writes, so this is far lighter on both the database and the controller than a stream of single writes. One thing to watch when you batch: build each request from registers that sit together. Stack points that are scattered across the register map into one request, and you force the device to read the dead space between them, or split the read into many small ones behind the scenes. Either way the cycle slows. Group points that are next to each other, and let the gaps fall on request edges.

And make sure the receiving end is built for the rate too. Reliability isn't only an upstream worry. A time-series database can take data at high speed, but feed it single writes at that speed and the cost climbs far above batched writes. Whatever takes the data, database, broker, or app, should be set up for the rate it's actually getting.

## The runtime isn't your variable

By the time poll rates, timeouts, protocol selection, and data handling are properly tuned, the runtime becomes just one fixed cost in the path, and a predictable one.

In the case of FlowFuse, which is built on Node-RED, the runtime runs on Node.js rather than on compiled embedded code. That introduces a small amount of overhead on each pass through a flow: typically a few milliseconds, and consistently so. It doesn't drift over time, and it doesn't increase when a device on the line becomes busy. A well-designed flow can maintain low-millisecond response times all day.

That fixed overhead is also a useful diagnostic tool. A constant delay of a few milliseconds cannot cause timing variations of tens of milliseconds. So if you're seeing swings that large, the root cause is somewhere else. In most cases, it comes down to one of the four issues covered in this article: an overloaded poll rate, a timeout chosen by guesswork, an ignored connection limit, or a protocol being asked to deliver timing guarantees it was never designed to provide.

There is one exception worth calling out. Node-RED runs as a single process with a shared event loop, so a CPU-intensive transformation or a slow database write anywhere within that instance can temporarily block everything else, including the fast path, whenever it executes. Moving that work to a different tab in the editor doesn't help, because all tabs within the same instance share the same event loop.

This isn't a case of the runtime being slow; it's a case of unrelated workloads competing for the same process. The solution is the same principle used throughout this article: give the fast path its own lane by moving heavy workloads into a separate instance.

## Final thought

A slow PLC link is the configuration assuming the data is simpler than it is. One rate for data that moves at four different speeds. A timeout that's never been measured. A scan budget spent without counting. A protocol asked to promise what it was never designed to promise.

None of that is a tool problem. It's a mismatch between what the system expects and what the data actually needs. Close that gap, by how fast each tag changes, by what the wire actually measures, by what each protocol was actually built for, and the timing follows on its own.


# Processing RTSP Camera Feeds at the Edge

RTSP is the protocol used by most IP cameras to deliver video streams over a network. While these streams are easy to view in an NVR or camera application, they're much harder to integrate into dashboards, automation, or AI workflows.

The **RTSP Video Feed** certified node published by FlowFuse solves that problem by converting a live RTSP stream into individual image frames that can be processed directly within your flows. Once a frame is available as a message, you can display it on a dashboard, send it to AI models for analysis, trigger actions based on its content, or store it locally.

In this tutorial, you'll connect to an RTSP camera and display the live feed on a dashboard. You'll also see how the captured frames can be passed to local AI models or recorded straight to disk.

## Prerequisites

Before you begin, ensure the FlowFuse Device Agent is installed and running on an edge device that can access the camera. This device will be managed through FlowFuse and serves as the environment where you'll install the required nodes and build the flow. If you haven't configured a device yet, complete the [Device Agent Quickstart](https://flowfuse.com/docs/device-agent/quickstart/) before continuing.

The RTSP Video Feed node is part of the **FlowFuse Edge Certified Nodes**, which are part of the **FlowFuse Edge** offering and aren't enabled by default. This applies to FlowFuse Cloud customers too, so the catalogue won't appear in your Palette Manager until it's switched on for your team. [Talk to our sales team](https://flowfuse.com/contact-us/) to get access before you start.

## How the node works

The **RTSP Video Feed** node does one job well: it connects to a camera and pulls still frames out of the stream as PNG images. It uses `ffmpeg` under the hood to handle the video decoding and frame extraction.

You give it an RTSP URL, credentials if the camera needs them, and a capture rate. It can then run in one of two modes: emit each frame as a message with the PNG in `msg.payload`, ready to wire into anything that takes an image, or write a numbered sequence of PNGs straight to disk for plain on-site recording. We'll use the message mode for most of this tutorial, since we want the frames in the flow, and cover disk recording at the end.

The capture rate and image resolution have a direct impact on performance. While `ffmpeg` handles the video decoding, higher frame rates and resolutions result in more images being generated, transferred, and processed by downstream nodes, increasing CPU, memory, and I/O usage. For best results, configure the node to capture only as many frames as your application requires.

## Build it: A Live Line View

Let's turn a camera into something an operator can actually monitor, without ever opening the NVR.

### Installing the node

> The catalogue must be enabled for your team before you can install the node (see the note above). Once it is, enabling the certified nodes package updates the catalogue, but existing devices and hosted instances won't see the new nodes until they restart. Restart any device or hosted instance you plan to install the node on so it picks up the updated catalogue.

1. In the FlowFuse editor, open the Palette Manager from the top-right menu.
2. Switch to the Install tab and find the "FlowFuse Edge Certified Nodes".
3. Locate the `@flowfuse-certified-nodes/rtsp` and click install. `ffmpeg` is pulled in automatically, so there's nothing else to set up.

![FlowFuse Palette Manager open on the Install tab, with the FlowFuse Edge Certified Nodes catalogue selected and the RTSP node's Install button highlighted](https://flowfuse.com/blog/2026/06/images/rtsp-edge-catalog.png)&#x2A;Installing the RTSP Video Feed node from the FlowFuse Edge Certified Nodes catalogue in the Palette Manager.*

Once it's installed, you'll find the **RTSP Feed** node in the left palette sidebar, ready to drag onto your canvas.

### Configuring the node

1. Drag the **RTSP Feed** node onto your canvas and double-click to open its settings.
2. In the RTSP URL field, enter your camera's stream address, for example `rtsp://192.168.1.50:554/ballmill-a2`.
3. If the camera requires a login, fill in Username and Password. These are stored as credentials and are never written into the flow file.
4. Set FPS to 10. Ten frames a second is smooth enough to watch a line in near real time. If your use case doesn't need that, lower it to ease the load: 1 is plenty for periodic monitoring. You can always raise it later.

> **FPS drives the load.** In message mode, every captured frame becomes a message in your flow, so a high FPS means more, larger messages to move and process; keep it no higher than your use case needs. In disk-writing mode no messages are emitted, so the rate instead governs how fast frames pile up on disk.

5. Leave Output image as `msg.payload` enabled so each frame is emitted as a message.

> You'll also see a **File path** field. In this mode, the node keeps a single working image in that location, or falls back to the operating system's temporary directory if the field is left blank. You can safely ignore it for now, as it only becomes important in disk-writing mode, covered in [Recording frames to disk](https://flowfuse.com/#recording-frames-to-disk). In that mode, frames are written to the specified path and are not automatically deleted.

![The RTSP Feed node settings panel showing the RTSP URL, optional Username and Password credential fields, the FPS selector set to 10, and the Output image as msg.payload option enabled](https://flowfuse.com/blog/2026/06/images/rtsp-config.png)*The RTSP Feed node settings panel showing the RTSP URL, optional Username and Password credential fields, the FPS selector set to 10, and the Output image as msg.payload option enabled*

6. Click Done, name the node **RTSP Feed**, wire a debug node to the output, and deploy.

Once the node connects, it shows a green Running status underneath it on the canvas. Capturing begins the moment the flow is deployed, and within a second PNG buffers start arriving in the debug sidebar, confirming the camera is connected and frames are flowing.

![Debug sidebar showing a stream of PNG buffer messages arriving from the RTSP Feed, one per captured frame](https://flowfuse.com/blog/2026/06/images/rtsp-debug-output.png)&#x2A;A buffer per frame in the debug sidebar. The feed is connected and the frames are now inside the flow.*

### Putting the feed on a dashboard

A buffer in the debug sidebar confirms the feed works, but it's no use to an operator. Let's get the frame onto a screen anyone can open in a browser.

This assumes you have FlowFuse Dashboard 2.0 installed. If you don't, follow the [Getting Started guide](https://dashboard.flowfuse.com/getting-started.html#installation){rel="&#x22;nofollow&#x22;"} to add it and set up your first page, then come back.

FlowFuse Dashboard has no built-in widget that takes a raw image buffer, so we turn each PNG into a base64 data URI and render it with a standard image tag. The conversion is handled by the **base64** node, which you'll need to install: add `node-red-node-base64` from the Palette Manager.

1. Add a **base64** node after the **RTSP Feed** node. With its default action, it converts the incoming PNG buffer into a base64 string.
2. Add a **Change** node after it. The RTSP Video Feed node outputs the image as a Base64-encoded string. To display it in a dashboard image widget, prepend the required Data URI prefix using the following JSONata expression:
   ```text
   "data:image/png;base64," & payload
   ```
3. Add a **ui-template** node and assign it to a dashboard group and page. Set its Type to *Widget* and drop in a single image element bound to the payload:
   ```html
   <template>
     <img
       :src="msg?.payload"
       v-if="msg?.payload"
       style="max-width: 100%; display: block; margin: 0 auto;"
       alt="Live frame from the A2 ball mill camera"
     />
   </template>
   ```
4. Deploy and open your dashboard. If you're working on the edge device, browse to `http://<flowfuse-agent-ip>:<port>/dashboard/`, using the IP and port your instance runs on. The view refreshes with every new frame.

That's a live line view anyone can pull up in a browser, with no NVR login and no separate video client.

:video{ariaLabel="FlowFuse Dashboard 2.0 page showing a live frame from the mill camera, with the grinding mill, feed conveyor and flotation line visible" autoPlay="true" height="434" loop="true" muted="true" playsInline="true" preload="none" width="800"}*FlowFuse Dashboard 2.0 page showing a live frame from the mill camera, with the grinding mill, feed conveyor and flotation line visible*

> **Watch the message size.** FlowFuse Dashboard sends data over a socket connection capped at about 1 MB per message by default, and a full-resolution frame can exceed that. When it does, the message is silently dropped and the image just doesn't appear. If that happens, lower the camera resolution, keep the FPS low, or raise [`maxHttpBufferSize`](https://dashboard.flowfuse.com/user/settings.html#maxhttpbuffersize){rel="&#x22;nofollow&#x22;"} in your instance settings.

## From a view to a decision

A live view is a real win, but notice what you have now: the camera's output is a PNG buffer moving through your flow, one message per frame. Once a frame is just another message, you can do more than display it. You can ask what's in it.

That's what the [**FlowFuse AI** nodes](https://flowfuse.com/node-red/flowfuse/ai/) are for. They run vision models locally, inside your flow, with nothing sent to an outside service. The **Object Detection** node takes a PNG buffer as its input, which is exactly what the camera node outputs, so you wire the camera straight into it, no conversion step in between. From there the flow stops watching and starts acting: counting material on the conveyor, flagging a person near the flotation cells, or catching a stopped belt before the line backs up. Each detection comes back as structured data, a label, a confidence score, and a position, which you handle like any other signal in FlowFuse.

## Recording frames to disk

One last mode worth knowing. Sometimes you don't need frames in the flow at all, just a local record of what the camera saw. Turn off &#x2A;*Output image as `msg.payload`** and the node stops emitting messages. Instead `ffmpeg` writes a continuous numbered sequence of PNGs (`rtsp-<node-id>-<counter>.png`) straight to disk.

Where they land is set by the **File path** field. Point it at a directory you control and the frames are written there. Leave it empty and the node falls back to the OS temp directory, typically `/tmp`. On many modern Linux distributions `/tmp` is a RAM-backed disk, though not on all, so frames there consume memory rather than disk and are cleared on reboot. Either way it's fine for a quick test but not for anything you need to keep.

## Wrapping up

Camera feeds don't have to sit in a silo while the rest of the floor gets connected. With the **RTSP Video Feed** node, a stream becomes still frames; with a dashboard, those frames become a live view; and with the **FlowFuse AI** nodes, they become decisions, all at the edge, with nothing leaving the plant.

[Abrasive Technology already puts this pattern to work](https://flowfuse.com/customer-stories/leveraging-node-red-and-flowfuse-to-automate-precision-manufacturing/), piping video feeds straight into a Node-RED dashboard to monitor its precision manufacturing lines.


# How Arch Systems Connected 100+ Factory Databases with FlowFuse

[Arch Systems](https://archsys.io/){rel="&#x22;nofollow&#x22;"} builds an AI copilot for manufacturers, and to power it the company connects more than 100 factory databases into a single analytics platform. Each one lives in a different production environment. Each one speaks to a different MES. Across them sits a tangle of diverse APIs and databases that rarely share conventions. Connecting any single database was never hard. Connecting the hundredth without rebuilding the work from scratch is the problem worth solving.

That copilot reads dashboards, synthesizes production data, and hands operators and engineers prescriptive guidance in real time, no infrastructure overhaul required. But a copilot is only as good as the data feeding it. In a factory, that data sits in the least cooperative layer of the stack: the gap between the shop floor and enterprise IT, where MES systems, databases, and APIs rarely agree on anything.

Here is the part that matters. Arch didn't just connect the data. They made the choice to connect it once and repeat the result reliably. That choice is the story.

## The cost lives in the repetition, not the connection

Connecting one factory system to one platform is a solved problem. Most competent teams clear it. The cost shows up on the second integration. Then the tenth. Then the hundredth.

Hand-built integrations don't compose. Every new customer becomes a separate project. A fix you apply in one environment never reaches the others, so the maintenance surface grows with every deployment, and configuration errors creep in, environments that should be identical pulling apart until something breaks in production. Past 100 databases across multiple environments, that approach collapses. The integration layer stops being plumbing. It becomes the ceiling on how fast the business can grow.

For a company whose entire job is onboarding manufacturers, that ceiling sets the roadmap. So Arch refused to accept it.

## Standardize the unit of work

Arch stopped treating each integration as a project. They started treating it as a template.

Working in FlowFuse's low-code environment, the team built standardized, reusable subflows that automate job creation in Arch React. The subflow is the unit of work: a packaged, parameterized piece of logic that does one job the same way on every deployment. Onboarding a new customer shifted from building an integration to deploying a known-good template and adjusting the edges. Do the engineering once. Configure everything after that.

Beneath that layer, MQTT brokers connect straight to the MES systems and open a reliable path for live production data. The flows take the stream, filter it, and generate tasks automatically from the processed production data. The architecture responds to production events immediately, which is what turns raw shop-floor activity into real-time insight.

Arch did this on top of the MES systems already running on the floor, not by replacing them. FlowFuse sits as a low-code layer above them, connecting to existing factory systems rather than forcing a rebuild. It runs as part of Arch's broader technology stack, working alongside the company's own platform capabilities and its other partner technologies rather than standing alone.

## DevOps: one place to change everything

Standardized subflows make each integration cheap to build. FlowFuse's DevOps model makes each integration cheap to maintain. For anyone running a system at this scale, the second property is the one that decides whether the first one survives.

FlowFuse manages every instance running your flows from a single platform, and its deployment pipelines propagate changes across development and production environments. Arch edits in one place and pushes the change to every production instance automatically. No instance-by-instance patching. No divergence between deployments that are supposed to match. Fewer configuration errors, because the system runs on one source of truth instead of dozens of hand-managed copies.

Two distinct properties, one outcome. One keeps the cost of building low. The other keeps the cost of maintaining low. Together they break the link between Arch's growth and its operational load. Arch adds customers without adding the same weight to the team keeping everything running.

## Results

- **More than 100 databases connected through automated subflows.** Every integration runs on the same FlowFuse-orchestrated pattern rather than a hand-built connection, which is why the hundredth database came online on the same proven path as the first.
- **New-customer rollout cut to a fraction of the time.** Reusable subflows replaced manual configuration, cutting the time to bring a new customer online to a fraction of what it once took and removing the per-customer engineering that had limited how fast Arch could grow.
- **Reliable real-time processing across diverse systems.** MQTT pipelines paired with FlowFuse-managed environments keep live production data consistent and dependable, regardless of how different each customer's MES happens to be.
- **A single edit reaches every environment at once.** Single-point editing and centralized deployment pipelines propagate updates across all production instances simultaneously, with no divergence between environments and no instance-by-instance patching, so the cost of maintenance no longer rises with each new deployment.

Taken together, these results separate Arch's growth from its operational load. The standardized subflows keep each integration inexpensive to build, the centralized DevOps model keeps it inexpensive to maintain, and the combination lets Arch add customers without adding the same weight to the team that keeps everything running. As Arch describes it, the ability to edit once and deploy everywhere added real efficiency to how the team manages integrations.

## What comes next

Arch keeps expanding the platform: more data sources, more third-party integrations, more manufacturing customers. Because the foundation is templated and centrally managed, each addition starts from proven ground instead of an empty canvas.

The first 100 databases were never the result that mattered. The architecture is. The next 100 cost a fraction of what the first ones did, and the same standardize-once, deploy-everywhere pattern holds for any manufacturer coordinating dozens of plants and lines, [automotive included](https://flowfuse.com/industries/automotive/).

*Read the full story on the [FlowFuse customer page](https://flowfuse.com/customer-stories/scaling-manufacturing-automation-with-flowfuse/).*


# Build a Machine Downtime Tracking Application

Production lines in manufacturing and automotive facilities experience planned and unplanned downtime every day. Tracking when a machine stops, how long it stays down, and why it happened helps production and maintenance teams identify recurring issues and improve operations.

Many factories still record downtime on paper or in spreadsheets. Others rely on PLC alarms without keeping a centralized history that teams can review and analyze later.

In this tutorial, you'll build a machine downtime tracking application using FlowFuse. The application records machine stop and start events, calculates downtime duration, lets operators assign downtime reasons, and displays a live dashboard with unresolved events and key metrics. Following the steps below, you can have this application built and deployed in about 10-15 minutes.

![Screenshot: completed dashboard with KPI cards and stoppages table](https://flowfuse.com/blog/2026/07/images/downtime-logger.png)&#x2A;The finished dashboard: KPI cards on top, unresolved stoppages below.*

You can interact with the live demo here: :live-demo-link{href="https://cheerful-western-sandpiper-1404.flowfuse.cloud/dashboard/downtime-events" label="Try the Machine Downtime Tracking Demo"}.

By the end, you'll have a foundation you can extend into OEE, production reporting, maintenance dashboards, or MES integrations.

## What You'll Need

Before you start building, get these ready:

- **A FlowFuse account.** Sign up for FlowFuse Cloud, or use a self-hosted instance.
- **A FlowFuse instance up and running.** If you don't have one yet, create a new instance from your FlowFuse Platform.
- **FlowFuse Dashboard installed.** This tutorial uses `@flowfuse/node-red-dashboard` nodes (`ui-button`, `ui-table`, `ui-chart`) to build the operator interface. Install it from the Palette Manager if it isn't already in your instance.
- **The Humanizer node installed.** This is what turns raw downtime into readable text like "12 minutes." It comes from the `node-red-contrib-moment` package, install it from the Palette Manager.

You won't need a PLC or any real hardware for this tutorial. We'll simulate machine stop and start events with inject nodes, and the same flow logic applies later when you connect real signals.

## How the Application Works

Before we build anything, let's first walk through what it should do and how the flow will look:

1. **Machine stops.** A signal comes in and a new downtime record opens for that machine.
2. **Machine starts again.** The record closes on its own, and the duration gets calculated.
3. **Operator logs a reason.** From the dashboard, closing it manually too if it wasn't already.
4. **The table shows what's unresolved.** Anything open, or anything closed without a reason, stays visible with the clock still running next to it.
5. **The KPI cards keep score.** Machines down now, missing reasons, average downtime, and the most common reason.

Once you see these five pieces working together, the rest of the tutorial is just wiring them up.

## Setting Up the Database Table

Everything in this application reads from and writes to a single table, so that's where we start.

> Note: [FlowFuse Tables](https://flowfuse.com/docs/user/ff-tables/) is currently in beta and available to Enterprise tier teams on FlowFuse Cloud, as well as Enterprise licensed self hosted teams running on Kubernetes. If you're on a different tier, you can follow along using any external database instead, Postgres, MySQL, or whatever you already have, with the standard database nodes from the palette. The SQL and flow logic in this tutorial will work the same either way.

1. Add a Query node to your canvas. This lets you run SQL queries directly against your FlowFuse managed database.
2. Set its query to create the table:

```sql
CREATE TABLE IF NOT EXISTS downtime_events (
    id SERIAL PRIMARY KEY,
    machine_id TEXT NOT NULL,
    status TEXT NOT NULL DEFAULT 'Open',
    reason TEXT,
    comments TEXT,
    start_time TIMESTAMPTZ NOT NULL,
    end_time TIMESTAMPTZ,
    duration_seconds INTEGER,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
```

3. Wire an inject node into the Query node. This is what triggers the query to run.
4. Add a debug node after the Query node. This lets you confirm the table was created successfully.
5. Click the inject node once, then check the debug sidebar. You should see a confirmation that the query ran.

Each row in this table represents one stoppage. Status tracks whether it's open or closed, reason and comments stay empty until an operator fills them in, and duration\_seconds gets calculated the moment a stoppage closes.

With the table in place, the application has somewhere to write to. Next, we'll set up the event that opens a record the moment a machine stops.

## Capturing Stop and Start Events

With the table ready, the next step is getting machine events into it, using MQTT.

Note: this tutorial uses the FlowFuse [built in broker](https://flowfuse.com/docs/user/teambroker/), available to Pro and Enterprise tier teams on FlowFuse Cloud. If you're on a different tier, contact us to get access, or use your own broker with the standard MQTT nodes instead, they work the same way here.

The event names used here, `downtime_started` and `downtime_ended`, are just an example. Your source may use different tags or a boolean instead of a string. What matters is the pattern, one signal opens a record and one closes it, so adjust to match your actual data.

1. Add an ff-mqtt-in node to the canvas, name it "Machine Events In", and set the topic to `factory/plant2/line1/+/events`, with QoS 0. Once you deploy this node, it will automatically pick up the connection and credentials for your team's broker, no config node needed.

![Screenshot: ff-mqtt-in node configuration panel with topic and QoS set](https://flowfuse.com/blog/2026/07/images/machine-events.png)&#x2A;The Machine Events In node subscribed to the wildcard topic.*

2. Add a switch node checking payload.event, with two rules, downtime\_started and downtime\_ended.

![Screenshot: switch node with two rules routing on payload.event](https://flowfuse.com/blog/2026/07/images/switch-to-route-events.png)&#x2A;Routing incoming events by type before they reach the database.*

3. For downtime\_started, add a change node before the Query node with two rules: set `queryParameters.machine_id` to `payload.machine_id` (msg), and set `queryParameters.timestamp` to `payload.timestamp` (msg).

![Screenshot: change node rules mapping payload fields to queryParameters](https://flowfuse.com/blog/2026/07/images/prep-params.png)&#x2A;Both sides of each rule set to msg, this is the step most likely to get mistyped.*

4. Add the Query node itself:

```sql
INSERT INTO downtime_events (machine_id, start_time)
SELECT $machine_id, $timestamp
WHERE NOT EXISTS (
    SELECT 1 FROM downtime_events
    WHERE machine_id = $machine_id AND status = 'Open'
);
```

5. For downtime\_ended, add the same kind of change node, `queryParameters.machine_id` and `queryParameters.timestamp` mapped the same way, then a separate Query node:

```sql
UPDATE downtime_events
SET status = 'Closed',
    end_time = $timestamp,
    duration_seconds = EXTRACT(EPOCH FROM ($timestamp::timestamptz - start_time))
WHERE machine_id = $machine_id AND status = 'Open';
```

To test without hardware, import the following flow:

::render-flow{:height='300'}
```json
[{"id":"bfc643d98eb10bb6","type":"group","z":"454731c79b51b360","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["4b50bf631b33bc25","c5c148db3ebd75ec","6e840436690af375","94a7e426af3a534c"],"x":214,"y":959,"w":752,"h":122},{"id":"4b50bf631b33bc25","type":"ff-mqtt-out","z":"454731c79b51b360","g":"bfc643d98eb10bb6","name":"","topic":"","qos":"0","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","lwt":"58936bbe1460d6be","x":870,"y":1020,"wires":[]},{"id":"c5c148db3ebd75ec","type":"inject","z":"454731c79b51b360","g":"bfc643d98eb10bb6","name":"Simulate: Downtime Started","props":[{"p":"payload.machine_id","v":"Robot-01","vt":"str"},{"p":"payload.event","v":"downtime_started","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":380,"y":1000,"wires":[["94a7e426af3a534c"]]},{"id":"6e840436690af375","type":"inject","z":"454731c79b51b360","g":"bfc643d98eb10bb6","name":"Simulate: Downtime Ended","props":[{"p":"payload.machine_id","v":"Robot-01","vt":"str"},{"p":"payload.event","v":"downtime_ended","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":370,"y":1040,"wires":[["94a7e426af3a534c"]]},{"id":"94a7e426af3a534c","type":"function","z":"454731c79b51b360","g":"bfc643d98eb10bb6","name":"Build Event Payload","func":"const p = msg.payload || {};\n\nconst machine_id = p.machine_id || \"unknown\";\nconst event = p.event || \"unknown_event\";\n\nmsg.topic = `factory/plant2/line1/${machine_id}/events`;\n\nmsg.payload = {\n    machine_id,\n    event,\n    timestamp: new Date().toISOString()\n};\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":660,"y":1020,"wires":[["4b50bf631b33bc25"]]},{"id":"58936bbe1460d6be","type":"ff-mqtt-conf","birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closeRetain":"false","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willRetain":"false","willPayload":"","willMsg":{}},{"id":"8c6c2d9875462a7f","type":"global-config","env":[],"modules":{"@flowfuse/nr-mqtt-nodes":"0.3.0"}}]
```
::

This gives you two buttons, one that simulates a machine stopping, one that simulates it starting again, wired through a function node that builds the topic and payload, then out over MQTT just like a real device would.

Deploy, click Simulate: Downtime Started, then check your table, a new open record should appear. Click Simulate: Downtime Ended and it should close with a duration.

Next, the dashboard table and the reason form operators use to close and explain a stoppage.

## Building the Dashboard Table and Reason Form

With events flowing into the database, the next step is showing them to the operator, and giving them a way to log why a machine stopped. Before starting, add a ui-page named "Downtime Events" and a ui-group named "Stoppages" on that page, this is where the table will live.

1. Go back to your event flow from the last section, after both Query nodes, downtime\_started and downtime\_ended, add a link out node. Give it a name like "event processed" so it's easy to find later.
2. In this new part of the flow, add a link in node and connect it to that same link out node. This is what lets the dashboard react any time a record opens or closes, without wiring long lines across the canvas.
3. There's one gap to close before moving on. The table only refreshes when an event comes in, so if a machine stays down for an hour with no new signal, "Open For" will sit frozen instead of counting up. Add an inject node set to repeat every 30 seconds, with its own link out wired to the same link in from step 2. This keeps the table and KPI cards refreshing on their own, even when nothing else is happening.
4. After the link in node, add a Query node that pulls every stoppage that's either still running or missing a reason. This is a triage table, so it only ever shows what still needs attention, once a stoppage is closed and explained, it drops off:

```sql
SELECT *,
       EXTRACT(EPOCH FROM start_time) AS start_epoch,
       TO_CHAR(start_time, 'DD Mon YYYY, HH12:MI AM') AS start_time_display,
       COALESCE(TO_CHAR(end_time, 'DD Mon YYYY, HH12:MI AM'), '-') AS end_time_display,
       COALESCE(reason, 'Not logged') AS reason_display,
       CASE WHEN reason IS NULL THEN true ELSE false END AS needs_review
FROM downtime_events
WHERE status = 'Open' OR reason IS NULL
ORDER BY CASE WHEN status = 'Open' THEN 0 ELSE 1 END, start_time DESC;
```

This formats the timestamps into something readable, like `07 Jul 2026, 02:45 PM`, sorts open stoppages to the top, and falls back to a dash or "Not logged" instead of a blank cell wherever a value is missing.

5. Add a split node after it, to break the result set into individual rows so each one can be processed on its own.
6. Add a change node that computes how long each stoppage has been open, using JSONata. Set the rule to `payload.elapsed_seconds`, type JSONata:

```text
$floor($millis() / 1000 - $number(payload.start_epoch))
```

7. Add a humanizer node after that, set to read from elapsed\_seconds. This turns the raw number into something readable, like "12 minutes" instead of "720".
8. Add a function node named **Colorize Duration**. This wraps the humanized value in a colored badge, so a stoppage that's dragged on stands out without anyone having to read the number:

> Tip: You don't have to write this JavaScript yourself. Use [FlowFuse Expert](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/#function-code-generation) and describe the logic in plain English. It will generate the code for you.

```javascript
const seconds = msg.payload.elapsed_seconds || 0;
let color = "green";

if (seconds >= 1800) {
    color = "red";
} else if (seconds >= 300) {
    color = "orange";
}

msg.payload.duration_html = `<span style="background:${color}; color:white; padding:2px 8px; border-radius:4px;">${msg.payload.humanized}</span>`;

return msg;
```

Under five minutes shows green, under thirty shows orange, anything longer shows red. Adjust the thresholds to whatever counts as concerning on your floor.

9. Add a join node set to rebuild the rows back into a single array, so the table gets the full list at once instead of one row at a time.
10. Add a ui-table node, assign it to the Stoppages group you created earlier, and wire it to the join node. Set up the following columns:

- **Machine**, key `machine_id`, type Text
- **Start Time**, key `start_time_display`, type Text
- **End Time**, key `end_time_display`, type Text
- **Open For**, key `duration_html`, type HTML
- a button column labeled something like "Close & Log Reason"

The HTML type on Open For is what renders the colored badge instead of showing raw tags. The query also computes `reason_display` and `needs_review`, these aren't shown as columns here, but stay available in the row data if you want to add them to the table later.

![Screenshot: ui-table node column configuration panel](https://flowfuse.com/blog/2026/07/images/ui-table-stoppages.png)&#x2A;Column setup for the Stoppages table, including the HTML type on Open For.*

11. Wire the table's button output to a ui-template node. Leave its group field empty and set its page to the same "Downtime Events" page, since this needs to render as a popup dialog over the whole page, not sit inside the table's group. This is where the reason form lives, a small custom dialog with a dropdown for reason and a text field for optional comments, built with a bit of Vue, since there's no default form node for this exact popup-on-row-click pattern:

> Tip: You don't have to write the Vue code yourself. Use [FlowFuse Expert](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/#css-and-html-generation-for-flowfuse-dashboard) and describe the interface in plain English. It will generate the ui-template code for you.

```html
<template>
  <v-dialog v-model="show" max-width="420">
    <v-card prepend-icon="mdi-alert-circle-outline" title="Record Downtime Reason">
      <v-card-subtitle>{{ machine_id }}, Stoppage #{{ id_value }}</v-card-subtitle>
      <v-card-text>
        <v-select v-model="reason" :items="reasonOptions" label="Reason*" required></v-select>
        <v-textarea v-model="comments" label="Comments (optional)" rows="2"></v-textarea>
      </v-card-text>
      <v-divider></v-divider>
      <v-card-actions>
        <v-spacer></v-spacer>
        <v-btn text="Close" variant="plain" @click="handleClose"></v-btn>
        <v-btn color="primary" text="Save" variant="tonal" :loading="submitting" :disabled="!reason || !id_value || submitting" @click="confirmSubmit"></v-btn>
      </v-card-actions>
    </v-card>
  </v-dialog>
</template>

<script>
export default {
  data() {
    return {
      show: false,
      id_value: null,
      machine_id: '',
      reason: null,
      comments: '',
      submitting: false,
      reasonOptions: [
        'Mechanical Failure',
        'Electrical Fault',
        'Material Shortage',
        'Changeover',
        'Operator Break',
        'Quality Issue',
        'Other'
      ]
    }
  },
  mounted() {
    this.socketHandler = (msg) => {
      if (msg?.payload?.id) {
        this.id_value = msg.payload.id;
        this.machine_id = msg.payload.machine_id;
        this.reason = null;
        this.comments = '';
        this.submitting = false;
        this.show = true;
      }
    };
    this.$socket.on('msg-input:' + this.id, this.socketHandler);
  },
  beforeUnmount() {
    this.$socket.off('msg-input:' + this.id, this.socketHandler);
  },
  methods: {
    handleClose() {
      if (this.reason || this.comments) {
        if (!confirm('Discard the reason you entered?')) return;
      }
      this.show = false;
    },
    confirmSubmit() {
      if (!confirm(`Close this stoppage on ${this.machine_id} with reason "${this.reason}"?`)) return;
      this.submitReason();
    },
    submitReason() {
      if (!this.id_value || this.submitting) return;
      this.submitting = true;
      this.send({
        payload: {
          id: this.id_value,
          reason: this.reason,
          comments: this.comments
        }
      });
      this.show = false;
    }
  }
}
</script>
```

This includes a confirmation step before closing or discarding, and disables Save while a submission is in progress, so an operator can't lose data or submit the same close twice.

12. Wire the template's output to a change node that maps the submitted fields into query parameters. Set four rules: first set `queryParameters` to `{}` (JSON), then set `queryParameters.id` to `payload.id` (msg), `queryParameters.reason` to `payload.reason` (msg), and `queryParameters.comments` to `payload.comments` (msg).

![Screenshot: change node rules mapping the submitted id, reason, and comments into queryParameters](https://flowfuse.com/blog/2026/07/images/prep-params-2.png)&#x2A;Resetting queryParameters first, then mapping each submitted field from the reason form.*

13. Add a final Query node to close the record and save the reason:

```sql
UPDATE downtime_events
SET reason = $reason,
    comments = $comments,
    status = 'Closed',
    end_time = NOW(),
    duration_seconds = EXTRACT(EPOCH FROM (NOW() - start_time))
WHERE id = $id;
```

14. Add a link out node after this last query too, wired to the same link in you used in step 2. This way closing a record manually refreshes the table just like an automatic close would.

Deploy, and open your dashboard. You should see the table populate with any open stoppages from the last section. Click "Close & Log Reason" on one, pick a reason, confirm, and it should disappear from the unresolved list right away.

![Screenshot: dashboard table with the reason form dialog open](https://flowfuse.com/blog/2026/07/images/ui-table-with-popup.png)&#x2A;The reason form popping up after clicking Close & Log Reason on a stoppage.*

Next, the KPI cards that summarize all of this into a few numbers at a glance.

## Adding the KPI Cards

With the table and reason form working, the last piece is a quick summary an operator or supervisor can glance at without reading every row. Add three more ui-groups on the same "Downtime Events" page, one for each card, so they can sit side by side across the top of the dashboard.

1. In the same part of the flow as your table's link in, add a Query node that calculates four numbers at once:

```sql
SELECT
  (SELECT COUNT(*) FROM downtime_events WHERE status = 'Open')::int AS open_count,
  (SELECT COUNT(*) FROM downtime_events WHERE status = 'Closed' AND reason IS NULL)::int AS missing_reason_count,
  (SELECT COALESCE(ROUND(AVG(duration_seconds) / 60.0, 1), 0)::float8
     FROM downtime_events
     WHERE status = 'Closed' AND start_time::date = CURRENT_DATE) AS avg_downtime,
  (SELECT COALESCE(
     (SELECT reason
      FROM downtime_events
      WHERE status = 'Closed' AND start_time::date = CURRENT_DATE AND reason IS NOT NULL
      GROUP BY reason
      ORDER BY COUNT(*) DESC
      LIMIT 1),
     'None yet'
  )) AS top_reason;
```

These four numbers cover different things on purpose, machines down right now, stoppages already closed but still missing a reason, average downtime in minutes today, and today's most common reason.

2. Wire this Query node to the same link in you already have from the event flow, so the cards refresh the moment a record opens or closes, same as the table.
3. Add four ui-text nodes, each assigned to its own group from the groups you just created:

- **Machines Down** → `payload[0].open_count`
- **Missing Reason** → `payload[0].missing_reason_count`
- **Avg (min)** → `payload[0].avg_downtime`
- **Top Reason** → `payload[0].top_reason`

4. Set each group's width so the four sit side by side across the dashboard page.

Deploy and check your dashboard. As you open, close, and log reasons on stoppages, all four numbers should update right along with the table.

![Screenshot: completed dashboard with KPI cards and stoppages table](https://flowfuse.com/blog/2026/07/images/complete-dashbaord-downtime-logger.png)&#x2A;The finished dashboard: KPI cards on top, unresolved stoppages below.*

That completes the application. You now have a working pipeline: a stoppage gets recorded the moment it happens, stays visible until someone accounts for it, and rolls up into numbers that mean something to a supervisor walking the floor. From here, this same table is the foundation for OEE calculations, shift reports, or feeding a maintenance dashboard, the hard part, capturing clean downtime data, is already done. For where a downtime view sits alongside production, OEE, and quality screens, see our [manufacturing dashboard examples](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/).


# Tracking Instrument Calibration with a Digital Dashboard

Most plants know their calibration status at two moments: when someone updates the spreadsheet, and when an auditor asks. The records already hold enough to do better than that: a last calibration date, an interval, and a next due date for every instrument.

Most registers also have a status field next to those dates, and reading it seems like the obvious move. But whatever writes that field can fall behind. Then the dashboard reports a compliant plant while due dates quietly pass. This build works out every figure from the due date instead, and counts how often the stored status disagrees with it.

For background on calibration records, including what they should contain, how calibration intervals are determined, and why overdue instruments matter, see [What Is Instrument Calibration (Equipment Calibration)?](https://flowfuse.com/blog/2026/07/what-is-instrument-calibration/).

A screen in the quality office is only half the job, though. The moment that matters is when someone picks up a torque wrench, and that person isn't looking at a dashboard. So the same check also runs behind a camera at the station: scan the label, get a verdict.

![Calibration status dashboard showing KPI cards for total equipment, valid, due soon, overdue, upcoming, and compliance percentage](https://flowfuse.com/blog/2026/07/images/calibration-management-dashboard.png) &#x2A;The finished dashboard: filters in the app bar, KPI row, and asset detail table on one page.*

In this article, we'll build a calibration application in FlowFuse. It will show plant-level compliance figures, let you filter by department and time window, give an asset-level view of what's due and when, and offer a camera-based tool check for the shop floor.

> **Note:** This tutorial reads from a `calibration_assets` table in FlowFuse Tables, filled with sample instruments. Everything here works the same against a real calibration register, a CMMS, or an ERP endpoint. Only the query nodes change.

You can interact with the live demo here: :live-demo-link{href="https://clever-garden-warbler-2554.flowfuse.cloud/dashboard/home" label="Try the Calibration Status Dashboard Demo"}.

## What You'll Need

Before you start building, get these ready:

- **A FlowFuse account.** [Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} for FlowFuse Cloud, or use a self-hosted instance.
- **A FlowFuse instance up and running.** If you don't have one yet, create a new instance from your FlowFuse Platform.
- **FlowFuse Dashboard installed.** This tutorial uses `@flowfuse/node-red-dashboard` nodes (`ui-template`, `ui-event`, `ui-button`, `ui-markdown`, `ui-notification`, `ui-page`, `ui-group`, `ui-theme`) to build both pages. Install it from the Palette Manager if it isn't already in your instance.
- **A webcam node and an OCR node.** The Tool Check page uses `@sumit_shinde_84/node-red-dashboard-2-ui-webcam` to capture the label and `@sumit_shinde_84/node-red-contrib-simple-ocr` to read it. Install both from the Palette Manager.
- **A device with a camera** for the Tool Check page, since the scanner works through the browser.

> **Note:** [FlowFuse Tables](https://flowfuse.com/docs/user/ff-tables/) is available to Enterprise tier teams on FlowFuse Cloud, and to Enterprise licensed self-hosted teams running on Kubernetes. If you're on a different tier, use any external database instead, such as Postgres or MySQL, with the standard database nodes from the palette. The SQL here is standard PostgreSQL, and the widgets only care about the shape of the rows, not where they came from.

## How the Application Works

Before we build anything, let's walk through what the application does. There are two pages, and one idea holding them together.

1. **Home.** A quality engineer picks a department and how far ahead to look. Six figures across the top show how much equipment there is, and how much of it is valid, due soon, overdue, coming up in the chosen window, and compliant overall. Below that is a list of instruments due inside that window, most urgent first, each with its status, due date, and days remaining. The cards describe the whole register for the chosen department. Only the **Upcoming** figure and the table below respond to the time window.
2. **Tool Check.** An operator holds a calibration label up to the camera and presses **SCAN**. The app reads the tool ID off the label, looks it up, and shows an answer in the middle of the screen: **OK to use**, **Do not use**, **Not in register**, or **Label not readable**. No numbers to interpret and no dashboard to search through.

The due date is the single source of truth for the whole application. Every KPI figure, every status chip in the table, and the scanner's verdict all come from comparing that date to the current time. That is what stops the office screen and the station gate from ever telling two different stories about the same tool.

## Importing the Simulated Flow

Instead of pointing the application at a live calibration register, we'll generate one.

1. Import the following flow into FlowFuse and click **Deploy**.
2. Click the trigger on **Create Table**, then the trigger on **Generate & Insert Automotive Calibration Dataset**. **Drop Table** is there for when you want to start over from scratch.

::render-flow{:height='300'}
```json
[{"id":"8a0785431b6b7a69","type":"group","z":"673ee3520831d89e","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["45bd6920b3f0f449","842c753f842b71e6","996c79e5aab802e7","d127e13f8fd0dd03","625821abbf04b74c","7b0b7067116ee8a1","8cc39dc849a910fa","e572d03e9887ce33","82643d26e04f2f09","365ee7bcc61d7f58"],"x":54,"y":79,"w":892,"h":242},{"id":"45bd6920b3f0f449","type":"debug","z":"673ee3520831d89e","g":"8a0785431b6b7a69","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":850,"y":280,"wires":[]},{"id":"842c753f842b71e6","type":"tables-query","z":"673ee3520831d89e","g":"8a0785431b6b7a69","name":"Create Table","query":"CREATE TABLE IF NOT EXISTS calibration_assets (\n    tool_id TEXT PRIMARY KEY,\n    equipment_name TEXT NOT NULL,\n    location TEXT NOT NULL,\n    department TEXT NOT NULL,\n    serial_number TEXT NOT NULL,\n    calibration_interval_months INTEGER NOT NULL,\n    last_calibration_ts TIMESTAMP NOT NULL,\n    next_due_ts TIMESTAMP NOT NULL,\n    status TEXT NOT NULL,\n    calibration_lab TEXT,\n    certificate_no TEXT,\n    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP\n);","split":false,"rowsPerMsg":1,"x":330,"y":180,"wires":[["d127e13f8fd0dd03"]]},{"id":"996c79e5aab802e7","type":"inject","z":"673ee3520831d89e","g":"8a0785431b6b7a69","name":"Trigger","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":150,"y":180,"wires":[["842c753f842b71e6"]]},{"id":"d127e13f8fd0dd03","type":"debug","z":"673ee3520831d89e","g":"8a0785431b6b7a69","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":850,"y":180,"wires":[]},{"id":"625821abbf04b74c","type":"function","z":"673ee3520831d89e","g":"8a0785431b6b7a69","name":"Generate & Insert Automotive Calibration Dataset","func":"// Generate realistic automotive calibration dataset\nconst departments = [\n  { name: 'Assembly', locations: ['Engine Line 1', 'Engine Line 2', 'Transmission Line', 'Final Assembly A', 'Final Assembly B'] },\n  { name: 'Body Shop', locations: ['BIW Cell 1', 'BIW Cell 2', 'Weld Cell 3', 'Robot Cell 5'] },\n  { name: 'Paint Shop', locations: ['Pretreatment', 'E-Coat', 'Paint Booth 1', 'Paint Booth 2'] },\n  { name: 'Powertrain', locations: ['Engine Test Cell', 'Dynamometer Area', 'Cylinder Head Line'] },\n  { name: 'Quality', locations: ['Inspection Lab', 'Metrology Lab', 'Chassis Inspection', 'Audit Room'] },\n  { name: 'Tool Room', locations: ['Tool Crib', 'Tool Room', 'Gauge Store'] },\n  { name: 'Maintenance', locations: ['Hydraulic Shop', 'Electrical Shop', 'Utilities Area'] },\n  { name: 'R&D', locations: ['NVH Lab', 'Prototype Shop', 'Validation Lab'] }\n];\n\nconst equipment = [\n  'Torque Wrench 1/2', 'Torque Wrench 3/8', 'Digital Torque Tester',\n  'Micrometer 0-25 mm', 'Micrometer 25-50 mm', 'Vernier Caliper 150 mm',\n  'Height Gauge 300 mm', 'Dial Gauge', 'Bore Gauge',\n  'Thread Plug Gauge M10', 'Thread Plug Gauge M12', 'Thread Ring Gauge M12',\n  'Pressure Gauge 0-10 bar', 'Pressure Gauge 0-25 bar', 'Digital Pressure Transducer',\n  'Thermocouple Calibrator', 'Temperature Indicator', 'Infrared Thermometer',\n  'Sound Level Meter', 'Sound Level Calibrator',\n  'CMM Probe', 'CMM Reference Sphere', 'Surface Roughness Tester',\n  'Digital Multimeter', 'Insulation Tester', 'Clamp Meter',\n  'Flow Meter', 'Mass Flow Controller', 'Load Cell 500 kg',\n  'Load Cell 2 Ton', 'Force Gauge 1000 N', 'Force Gauge 5000 N',\n  'Thickness Gauge', 'Coating Thickness Gauge', 'Paint Viscosity Cup'\n];\n\nconst labs = [\n  'ABC Calibration Lab',\n  'Metro Metrology',\n  'Precision Labs',\n  'National Metrology Services',\n  'Industrial Calibration Centre'\n];\n\nfunction rand(arr) {\n  return arr[Math.floor(Math.random() * arr.length)];\n}\n\nfunction randomTimestamp(startDate, endDate) {\n  const start = startDate.getTime();\n  const end = endDate.getTime();\n  const d = new Date(start + Math.random() * (end - start));\n\n  // Working hours 07:00-17:00\n  d.setHours(7 + Math.floor(Math.random() * 10));\n  d.setMinutes(Math.floor(Math.random() * 60));\n  d.setSeconds(Math.floor(Math.random() * 60));\n  d.setMilliseconds(0);\n\n  return d.toISOString().slice(0, 19).replace('T', ' ');\n}\n\nfunction addMonths(ts, months) {\n  const d = new Date(ts.replace(' ', 'T'));\n  d.setMonth(d.getMonth() + months);\n  return d.toISOString().slice(0, 19).replace('T', ' ');\n}\n\nconst today = new Date('2026-07-28T10:00:00');\n\nlet values = [];\n\nfor (let i = 1; i <= 120; i++) {\n\n  const dept = rand(departments);\n  const location = rand(dept.locations);\n  const equip = rand(equipment);\n  const interval = rand([3, 6, 6, 6, 12, 12]);\n\n  // Status distribution\n  const r = Math.random();\n  let status;\n  if (r < 0.10) status = 'Overdue';\n  else if (r < 0.30) status = 'DueSoon';\n  else status = 'Valid';\n\n  let lastCal;\n  let nextDue;\n\n  if (status === 'Valid') {\n    lastCal = randomTimestamp(new Date('2026-01-01'), new Date('2026-06-30'));\n    nextDue = addMonths(lastCal, interval);\n\n  } else if (status === 'DueSoon') {\n\n    lastCal = randomTimestamp(new Date('2026-01-01'), new Date('2026-05-31'));\n\n    const d = new Date(today);\n    d.setDate(d.getDate() + Math.floor(Math.random() * 14));\n    d.setHours(8 + Math.floor(Math.random() * 8));\n    d.setMinutes(Math.floor(Math.random() * 60));\n    d.setSeconds(0);\n\n    nextDue = d.toISOString().slice(0, 19).replace('T', ' ');\n\n  } else {\n\n    lastCal = randomTimestamp(new Date('2025-01-01'), new Date('2025-12-31'));\n\n    const d = new Date(today);\n    d.setDate(d.getDate() - (1 + Math.floor(Math.random() * 45)));\n    d.setHours(8 + Math.floor(Math.random() * 8));\n    d.setMinutes(Math.floor(Math.random() * 60));\n    d.setSeconds(0);\n\n    nextDue = d.toISOString().slice(0, 19).replace('T', ' ');\n  }\n\n  const toolId = 'TL-' + String(i).padStart(4, '0');\n  const serial = 'SN' + (100000 + i);\n  const cert = 'CAL-2026-' + String(1000 + i);\n  const lab = rand(labs);\n\n  values.push(\n    `('${toolId}','${equip}','${location}','${dept.name}','${serial}',${interval},'${lastCal}','${nextDue}','${status}','${lab}','${cert}')`\n  );\n}\n\nmsg.query = `\nINSERT INTO calibration_assets\n(tool_id, equipment_name, location, department, serial_number,\n calibration_interval_months, last_calibration_ts, next_due_ts,\n status, calibration_lab, certificate_no)\nVALUES\n${values.join(',\\n')};\n`;\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":430,"y":280,"wires":[["8cc39dc849a910fa"]]},{"id":"7b0b7067116ee8a1","type":"inject","z":"673ee3520831d89e","g":"8a0785431b6b7a69","name":"Trigger","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":150,"y":280,"wires":[["625821abbf04b74c"]]},{"id":"8cc39dc849a910fa","type":"tables-query","z":"673ee3520831d89e","g":"8a0785431b6b7a69","name":"Query","query":"","split":false,"rowsPerMsg":1,"x":710,"y":280,"wires":[["45bd6920b3f0f449"]]},{"id":"e572d03e9887ce33","type":"tables-query","z":"673ee3520831d89e","g":"8a0785431b6b7a69","name":"Drop Table","query":"DROP TABLE IF EXISTS calibration_assets;\n","split":false,"rowsPerMsg":1,"x":330,"y":120,"wires":[["365ee7bcc61d7f58"]]},{"id":"82643d26e04f2f09","type":"inject","z":"673ee3520831d89e","g":"8a0785431b6b7a69","name":"Trigger","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":150,"y":120,"wires":[["e572d03e9887ce33"]]},{"id":"365ee7bcc61d7f58","type":"debug","z":"673ee3520831d89e","g":"8a0785431b6b7a69","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":850,"y":120,"wires":[]},{"id":"993b160c135046a2","type":"global-config","env":[],"modules":{"@flowfuse/nr-tables-nodes":"0.2.2"}}]
```
::

That gives you 120 instruments with IDs from `TL-0001` to `TL-0120`, spread across eight departments: roughly 70% valid, 20% due soon, and 10% overdue. The eight department names are the same ones the filter dropdown offers later.

Everything we build reads from these columns:

| Column                                                             | What the application does with it                                                                 |
| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| `tool_id`                                                          | Primary key, and the ID printed on the calibration label that the scanner matches against         |
| `next_due_ts`                                                      | Every status figure, chip, and scanner verdict comes from comparing this against the current time |
| `status`                                                           | The stored label. We deliberately don't trust it, and use it only to spot drift from the dates    |
| `department`                                                       | Drives the Department filter on the dashboard                                                     |
| `equipment_name`                                                   | Names the instrument in the table and in the scanner verdict                                      |
| `location`, `calibration_interval_months`, `last_calibration_ts`   | Table columns                                                                                     |
| `serial_number`, `calibration_lab`, `certificate_no`, `created_at` | Kept for reference; nothing in this build shows them                                              |

> **Note:** Your register will likely name these columns differently. Alias your columns in the `SELECT` list, as in `SELECT gauge_ref AS tool_id, cal_due_date AS next_due_ts, ...`, and every widget will still work. Only the due-date column is essential.

Before running the generator, set its reference date near the top of the function, `const today = new Date('2026-07-28T10:00:00')`, to roughly today's date. Otherwise everything will land relative to a date in the past.

## Setting Up the Dashboard Layout

The application has two pages and four groups. Most widgets sit inside a named group. The filter bar is scoped to the page instead, because it appears in the app bar rather than in the grid. See the [Dashboard layout docs](https://dashboard.flowfuse.com/getting-started){rel="&#x22;nofollow&#x22;"} if you're new to how pages, groups, and bases relate.

1. Create two **ui-page** nodes. The Dashboard automatically creates a base dashboard the first time you add a Dashboard node to the canvas.
   - **Home** (path: `/home`): the calibration status dashboard. Set the layout to **Grid**.
   - **Tool Check** (path: `/tool-check`): the scanner. Set the layout to **Notebook**.
2. On the **Home** page, create two **ui-group** nodes, both **12 columns** wide with **Show title** turned off:
   - **KPIs** (order 1)
   - **Asset Detail** (order 2)
3. On the **Tool Check** page, create two more **ui-group** nodes, also **12 columns** wide with titles off:
   - **Scanner** (order 1)
   - **Verdict** (order 2)
4. Open the **ui-base** node and set **Header Content** to **page**. This shows the app bar, which the filter widget needs.
5. Set up the ui-theme to suit your needs. The dashboard already comes with a default theme, which you can use for now.

## Building the Filter Bar

Two controls drive the page: which department, and how far ahead to look. Both sit in the app bar rather than the grid, so no row of the page is used up by a dropdown.

The department list is read from the register itself, not typed in by hand, so adding a department next year doesn't mean editing a flow. The time windows are fixed, because "next 30 days" is a choice this application makes rather than something the data tells you.

1. Add a `ui-event` node named "Page Load / Refresh Event" and select your "My Dashboard" ui-base. It fires whenever a page loads.
2. Add a `tables-query` node named "Load Departments":

> **Tip:** You don't have to write the SQL yourself either. Use [FlowFuse Expert](https://flowfuse.com/blog/2025/09/ai-assistant-flowfuse-tables/) and describe what you want the query to return in plain English, and it will generate the SQL for you.

```sql
SELECT DISTINCT department
FROM calibration_assets
WHERE department IS NOT NULL
  AND btrim(department) <> ''
ORDER BY department;
```

1. Import the **App Header Filters** `ui-template` below, set its type to &#x2A;*Widget (Page-Scoped)**, select the **Home** page, and turn off **Pass through messages from input to output**. The complete component is provided below, so there's no need to build it yourself. It shows two dropdowns in the header using Vue's [Teleport](https://flowfuse.com/blog/2024/08/customise-theming-in-your-dashboards/#adding-elements-in-the-header): **Department**, filled from the query above, and **Time Window**. It opens on *All* departments and *Next 90 days*, sends `{ department, timeWindow }` on every change, and sends the same on load so the dropdowns and the data always agree.

> **Tip:** Whenever you need a custom Dashboard widget, you don't have to write the Vue code yourself. Use [FlowFuse Expert](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/#css-and-html-generation-for-flowfuse-dashboard) and describe the widget in plain English, and it will generate the `ui-template` for you.

::render-flow{:height='300'}
```json
[{"id":"e263486a1e3ea8ea","type":"ui-template","z":"1c5b2364213044a7","g":"c619d111b9911c0b","group":"","page":"89515a0645eddeee","ui":"","name":"App Header Filters","order":1,"width":0,"height":0,"head":"","format":"<template>\n  <Teleport v-if=\"mounted\" to=\"#app-bar-actions\">\n    <div class=\"filter-bar\">\n\n      <!-- Department: options come from the register, not from this file -->\n      <v-select v-model=\"department\" :items=\"departments\" label=\"Department\" density=\"compact\" variant=\"solo-filled\"\n        hide-details style=\"width: 180px\" @update:model-value=\"sendFilters\"></v-select>\n\n      <!-- Time Window -->\n      <v-select v-model=\"timeWindow\" :items=\"timeWindows\" label=\"Time Window\" density=\"compact\" variant=\"solo-filled\"\n        hide-details style=\"width: 200px\" @update:model-value=\"sendFilters\"></v-select>\n\n    </div>\n  </Teleport>\n</template>\n\n<script>\n  export default {\n    data() {\n      return {\n        mounted: false,\n\n        // Filters reset to these on every page load. Nothing is remembered.\n        // 90 days is deliberate: at 30 the Upcoming card would just repeat\n        // Due soon, and the control would look like it does nothing.\n        department: 'All',\n        timeWindow: 'Next 90 days',\n\n        // Replaced by the list read from the register. Starts as just 'All'\n        // so the control is usable before the query comes back.\n        departments: ['All'],\n\n        // Fixed: these are windows the app defines, not data.\n        timeWindows: [\n          'Next 7 days',\n          'Next 30 days',\n          'Next 90 days',\n          'All future'\n        ]\n      }\n    },\n\n    watch: {\n      msg: {\n        handler(msg) { this.applyMsg(msg) },\n        deep: true\n      }\n    },\n\n    mounted() {\n      this.mounted = true;\n      this.applyMsg(this.msg);\n      this.$socket.on('msg-input:' + this.id, this.applyMsg);\n\n      // A refresh resets the dropdowns to their defaults, so push those\n      // defaults out once. Without this the queries keep reading the previous\n      // selection from context, and the numbers wouldn't match the dropdowns.\n      this.sendFilters();\n    },\n\n    unmounted() {\n      this.$socket.off('msg-input:' + this.id, this.applyMsg);\n    },\n\n    methods: {\n      // Receives the Load Departments rows exactly as the database returns\n      // them: [{ department: 'Assembly' }, { department: 'Quality' }, ...]\n      applyMsg(msg) {\n        const rows = msg && msg.payload;\n        if (!Array.isArray(rows)) return;\n\n        const names = rows\n          .map(r => (r && typeof r === 'object') ? r.department : r)\n          .filter(d => typeof d === 'string' && d.trim() !== '');\n\n        // 'All' is ours, not a row in the table.\n        if (names.length) {\n          this.departments = ['All', ...new Set(names)];\n        }\n      },\n\n      sendFilters() {\n        this.send({\n          payload: {\n            department: this.department,\n            timeWindow: this.timeWindow\n          }\n        });\n      }\n    }\n  }\n</script>\n\n<style>\n  .filter-bar {\n    display: flex;\n    align-items: center;\n    gap: 12px;\n    padding-right: 12px;\n  }\n\n  /* Make controls compact in the app bar */\n  .filter-bar .v-input {\n    margin-top: 0 !important;\n  }\n</style>","storeOutMessages":true,"passthru":false,"resendOnRefresh":true,"templateScope":"widget:page","className":"","x":810,"y":80,"wires":[["b9c34ba932fa101c"]]},{"id":"89515a0645eddeee","type":"ui-page","name":"Home","ui":"6481b1c613ec9a93","path":"/home","icon":"home","layout":"grid","theme":"faac104f34962f3e","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"6481b1c613ec9a93","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control","ui-number-input","ui-file-input","ui-button","ui-button-group","ui-dropdown","ui-radio-group","ui-slider","ui-switch","ui-text","ui-table","ui-gauge","ui-chart","ui-template","ui-markdown","ui-progress","ui-webcam"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":false},{"id":"faac104f34962f3e","type":"ui-theme","name":"Default Theme","colors":{"surface":"#ffffff","primary":"#1e4e8c","bgPage":"#eef1f5","groupBg":"#ffffff","groupOutline":"#d3dae3"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"6f4ad536fc64beb9","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.30.2"}}]
```
::

4. Add a `change` node named "Save Filters to Global Context" and set the persistent global `filters` to `msg.payload`.
5. Add a `link out` node named "Filters Changed". This is what makes the page respond right away. Changing a dropdown writes the new selection to context, but nothing would redraw until the next poll tick, so the operator would be looking at stale numbers for up to fifteen seconds. The link carries the change straight into the next flow, which re-runs its query and refreshes the page.
6. Wire the nodes: **Page Load / Refresh Event → Load Departments → App Header Filters → Save Filters to Global Context → Filters Changed**.

![Placeholder: the app bar showing the Department and Time Window dropdowns](https://flowfuse.com/blog/2026/07/images/header-dropdown.png) &#x2A;The Department and Time Window dropdowns shown in the app bar, with departments read from the register.*

## Working Out the KPI Figures from the Due Dates

This is where we stop using the register's `status` column. Every figure on the page comes from comparing `next_due_ts` against the current time, and one extra count reports how often the stored status disagrees with that comparison.

1. Add an `inject` node named "Poll Data (15 sec)", set it to repeat every **15** seconds and to fire once shortly after deploy, so the page has data before the first tick.
2. Add a `link in` node named "Filters Changed" and point it at the link out from the filter bar.
3. Add a `change` node named "Set Params". This maps the saved filters onto the `$department` and `$timeWindow` parameters the SQL reads. Set three rules, in order:
   - Set `queryParameters` to `{}` (JSON): starts clean so old values don't linger.
   - Set `queryParameters.department` to `filters.department` (global persistent).
   - Set `queryParameters.timeWindow` to `filters.timeWindow` (global persistent).

![Set Params change node with its three rules](https://flowfuse.com/blog/2026/07/images/set-params.png) &#x2A;The "Set Params" change node open in the edit panel, all three rules visible.*

1. Add a `tables-query` node named "KPI Query":

```sql
SELECT
    -- Sent back so the cards label themselves from the data on screen,
    -- not from whatever the dropdowns happen to show. COALESCE covers the
    -- first poll after deploy, before any browser has sent a selection.
    COALESCE($department::text, 'All')          AS filter_department,
    COALESCE($timeWindow::text, 'Next 90 days') AS filter_window,

    COUNT(*) AS total_assets,

    -- Buckets worked out from next_due_ts instead of the stored status column,
    -- which drifts whenever whatever writes it falls behind. These three
    -- don't overlap, and add up to total_assets. The 30-day threshold is a
    -- policy decision, not a view setting: it does not change with the dropdown.
    COUNT(*) FILTER (
        WHERE next_due_ts > NOW() + INTERVAL '30 days'
    ) AS valid_assets,

    COUNT(*) FILTER (
        WHERE next_due_ts >= NOW()
          AND next_due_ts <= NOW() + INTERVAL '30 days'
    ) AS due_soon_assets,

    COUNT(*) FILTER (
        WHERE next_due_ts < NOW()
    ) AS overdue_assets,

    -- The only figure the Time Window dropdown affects. It sends a label, so
    -- it maps to an interval here; ELSE also catches an unrecognised label.
    COUNT(*) FILTER (
        WHERE next_due_ts >= NOW()
          AND next_due_ts <= NOW() + (
              CASE COALESCE($timeWindow::text, 'Next 90 days')
                  WHEN 'Next 7 days'  THEN INTERVAL '7 days'
                  WHEN 'Next 30 days' THEN INTERVAL '30 days'
                  WHEN 'Next 90 days' THEN INTERVAL '90 days'
                  WHEN 'All future'   THEN INTERVAL '100 years'
                  ELSE INTERVAL '90 days'
              END
          )
    ) AS due_in_window,

    COUNT(*) FILTER (
        WHERE next_due_ts BETWEEN NOW()
                            AND NOW() + INTERVAL '7 days'
    ) AS due_next_7_days,

    -- Compliance means "inside its calibration interval", which includes
    -- tools due soon, since they have not expired yet.
    ROUND(
        COUNT(*) FILTER (WHERE next_due_ts >= NOW()) * 100.0
        / NULLIF(COUNT(*), 0),
        1
    ) AS valid_percentage,

    -- Counts records where the stored status and the live date disagree, so
    -- the drift shows up on the dashboard instead of staying hidden.
    COUNT(*) FILTER (
        WHERE (status = 'Overdue') <> (next_due_ts < NOW())
    ) AS stale_status_count

FROM calibration_assets
-- Driven by the Department dropdown; 'All' turns the filter off.
WHERE (COALESCE($department::text, 'All') = 'All'
       OR department = $department::text);
```

`stale_status_count` is the figure worth watching. It counts the rows where the stored status and the due date disagree, which is the number that justifies leaving the status column out of every other calculation.

5. Add a `link out` node named "Refresh Asset Table" and wire it from **Set Params**, so the table below runs on the same selection instead of working it out again.
6. Import the **KPI Cards** `ui-template` below and assign it to the **KPIs** group. The complete component is provided below, so there's no need to build it yourself. It shows a header with the active filter and a last-updated time, six cards for total equipment, valid, due soon, overdue, upcoming and compliance, and a three-line summary strip. When `stale_status_count` is above zero it also shows a warning banner naming the number of drifted records.

::render-flow{:height='300'}
```json
[{"id":"1e9b85cd8f2fdc3c","type":"ui-template","z":"1c5b2364213044a7","g":"3ed935d02285b78b","group":"05fdb0d422eb75af","page":"","ui":"","name":"KPI Cards","order":1,"width":0,"height":0,"head":"","format":"<template>\n    <v-container fluid class=\"pa-2\">\n\n        <!-- Header -->\n        <v-card class=\"pa-4 mb-3\" elevation=\"1\" rounded=\"lg\">\n            <v-row align=\"center\">\n                <v-col cols=\"12\" md=\"7\">\n                    <div class=\"text-h6 font-weight-bold\">ACME Automotive Plant</div>\n                    <div class=\"text-body-2 text-medium-emphasis\">\n                        Calibration &amp; Measurement Status Dashboard\n                    </div>\n                </v-col>\n\n                <v-col cols=\"12\" md=\"5\" class=\"text-md-right\">\n                    <v-chip v-if=\"filters.department\" color=\"primary\" variant=\"tonal\" size=\"small\" class=\"mr-2\">\n                        <v-icon start size=\"16\">mdi-filter-variant</v-icon>\n                        {{ filters.department }} &middot; {{ filters.window }}\n                    </v-chip>\n                    <v-chip v-if=\"updatedAt\" color=\"primary\" variant=\"tonal\" size=\"small\">\n                        <v-icon start size=\"16\">mdi-refresh</v-icon>\n                        Updated {{ updatedAtText }}\n                    </v-chip>\n                </v-col>\n            </v-row>\n        </v-card>\n\n        <!-- Loading state until the first query result arrives -->\n        <v-alert v-if=\"!loaded\" type=\"info\" variant=\"tonal\" density=\"compact\" class=\"mb-3\">\n            Waiting for calibration data...\n        </v-alert>\n\n        <!-- Data quality: the stored status column has drifted from the dates -->\n        <v-alert v-if=\"kpi.stale_status_count > 0\" type=\"warning\" variant=\"tonal\"\n            density=\"compact\" class=\"mb-3\">\n            {{ kpi.stale_status_count }} record(s) have a status field that disagrees with\n            their due date. Every count here is derived from the date.\n        </v-alert>\n\n        <!-- KPI Cards -->\n        <v-row dense>\n\n            <v-col cols=\"12\" sm=\"6\" md=\"2\">\n                <v-card class=\"pa-4 h-100 border-neutral\" elevation=\"1\" rounded=\"lg\">\n                    <div class=\"text-caption text-medium-emphasis\">TOTAL EQUIPMENT</div>\n                    <div class=\"text-h4 font-weight-bold mt-2\">{{ show(kpi.total_assets) }}</div>\n                    <div class=\"text-caption text-medium-emphasis mt-2\">\n                        {{ filters.department === 'All' ? 'All departments' : filters.department }}\n                    </div>\n                </v-card>\n            </v-col>\n\n            <v-col cols=\"12\" sm=\"6\" md=\"2\">\n                <v-card class=\"pa-4 h-100 border-success\" elevation=\"1\" rounded=\"lg\">\n                    <div class=\"text-caption text-medium-emphasis\">VALID</div>\n                    <div class=\"text-h4 font-weight-bold mt-2 text-success\">{{ show(kpi.valid_assets) }}</div>\n                    <div class=\"text-caption text-medium-emphasis mt-2\">Due beyond 30 days</div>\n                </v-card>\n            </v-col>\n\n            <v-col cols=\"12\" sm=\"6\" md=\"2\">\n                <v-card class=\"pa-4 h-100 border-warning\" elevation=\"1\" rounded=\"lg\">\n                    <div class=\"text-caption text-medium-emphasis\">DUE SOON</div>\n                    <div class=\"text-h4 font-weight-bold mt-2 text-warning\">{{ show(kpi.due_soon_assets) }}</div>\n                    <div class=\"text-caption text-medium-emphasis mt-2\">Next 30 days</div>\n                </v-card>\n            </v-col>\n\n            <v-col cols=\"12\" sm=\"6\" md=\"2\">\n                <v-card class=\"pa-4 h-100 border-danger\" elevation=\"1\" rounded=\"lg\">\n                    <div class=\"text-caption text-medium-emphasis\">OVERDUE</div>\n                    <div class=\"text-h4 font-weight-bold mt-2 text-error\">{{ show(kpi.overdue_assets) }}</div>\n                    <div class=\"text-caption text-medium-emphasis mt-2\">Immediate action</div>\n                </v-card>\n            </v-col>\n\n            <v-col cols=\"12\" sm=\"6\" md=\"2\">\n                <v-card class=\"pa-4 h-100 border-info\" elevation=\"1\" rounded=\"lg\">\n                    <div class=\"text-caption text-medium-emphasis\">UPCOMING</div>\n                    <div class=\"text-h4 font-weight-bold mt-2 text-info\">{{ show(kpi.due_in_window) }}</div>\n                    <div class=\"text-caption text-medium-emphasis mt-2\">{{ filters.window }}</div>\n                </v-card>\n            </v-col>\n\n            <v-col cols=\"12\" sm=\"6\" md=\"2\">\n                <v-card class=\"pa-4 h-100 border-neutral\" elevation=\"1\" rounded=\"lg\">\n                    <div class=\"text-caption text-medium-emphasis\">COMPLIANCE</div>\n                    <div class=\"text-h4 font-weight-bold mt-2\">{{ show(kpi.valid_percentage) }}%</div>\n                    <div class=\"text-caption text-medium-emphasis mt-2\">Plant health</div>\n                </v-card>\n            </v-col>\n\n        </v-row>\n\n        <!-- Status Strip -->\n        <v-card class=\"pa-3 mt-3\" elevation=\"1\" rounded=\"lg\">\n            <v-row dense align=\"center\">\n                <v-col cols=\"12\" md=\"4\">\n                    <div class=\"d-flex align-center\">\n                        <v-icon color=\"success\" class=\"mr-2\">mdi-check-circle</v-icon>\n                        <span class=\"text-body-2\">\n                            <strong>{{ show(kpi.valid_assets) }}</strong> tools verified for production\n                        </span>\n                    </div>\n                </v-col>\n\n                <v-col cols=\"12\" md=\"4\">\n                    <div class=\"d-flex align-center\">\n                        <v-icon color=\"warning\" class=\"mr-2\">mdi-alert</v-icon>\n                        <span class=\"text-body-2\">\n                            <strong>{{ show(kpi.due_next_7_days) }}</strong> tools require calibration within 7 days\n                        </span>\n                    </div>\n                </v-col>\n\n                <v-col cols=\"12\" md=\"4\">\n                    <div class=\"d-flex align-center\">\n                        <v-icon color=\"error\" class=\"mr-2\">mdi-close-circle</v-icon>\n                        <span class=\"text-body-2\">\n                            <strong>{{ show(kpi.overdue_assets) }}</strong> tools are overdue and blocked from use\n                        </span>\n                    </div>\n                </v-col>\n            </v-row>\n        </v-card>\n\n    </v-container>\n</template>\n\n<script>\n    export default {\n        data() {\n            return {\n                loaded: false,\n                updatedAt: null,\n\n                // Echoed back from the query so the cards always describe\n                // the data actually on screen, not the pending selection.\n                filters: {\n                    department: '',\n                    window: ''\n                },\n\n                kpi: {\n                    total_assets: null,\n                    valid_assets: null,\n                    due_soon_assets: null,\n                    overdue_assets: null,\n                    due_in_window: null,\n                    due_next_7_days: null,\n                    stale_status_count: null,\n                    valid_percentage: null\n                }\n            }\n        },\n\n        computed: {\n            updatedAtText() {\n                if (!this.updatedAt) return ''\n                return this.updatedAt.toLocaleTimeString([], {\n                    hour: '2-digit',\n                    minute: '2-digit',\n                    second: '2-digit'\n                })\n            }\n        },\n\n        // Catches the message that Dashboard replays on page load / refresh,\n        // which can arrive before the socket listener below is registered.\n        watch: {\n            msg: {\n                handler(msg) { this.applyMsg(msg) },\n                immediate: true,\n                deep: true\n            }\n        },\n\n        mounted() {\n            this.applyMsg(this.msg)\n            this.$socket.on('msg-input:' + this.id, this.applyMsg)\n        },\n\n        unmounted() {\n            this.$socket.off('msg-input:' + this.id, this.applyMsg)\n        },\n\n        methods: {\n            applyMsg(msg) {\n                const payload = msg && msg.payload\n                if (!payload) return\n\n                // The Query node returns an ARRAY of rows unless \"Split results\"\n                // is on with 1 row per message. Take the first row either way.\n                const row = Array.isArray(payload) ? payload[0] : payload\n                if (!row || typeof row !== 'object') return\n\n                if (row.filter_department) this.filters.department = row.filter_department\n                if (row.filter_window) this.filters.window = row.filter_window\n\n                const next = {}\n                for (const key of Object.keys(this.kpi)) {\n                    if (row[key] === undefined || row[key] === null) continue\n                    // COUNT() is BIGINT and ROUND() is NUMERIC - pg returns both\n                    // as strings, so coerce to Number for display and maths.\n                    const num = Number(row[key])\n                    next[key] = Number.isFinite(num) ? num : row[key]\n                }\n\n                this.kpi = { ...this.kpi, ...next }\n                this.loaded = true\n                this.updatedAt = new Date()\n            },\n\n            show(value) {\n                return (value === null || value === undefined) ? '-' : value\n            }\n        }\n    }\n</script>\n\n<style>\n    /* The ui-theme node only carries the four structural colours, so the\n       semantic ones are redefined here. This block is unscoped, so it\n       applies to every widget on the page. */\n    :root,\n    [class*=\"v-theme--\"] {\n        --v-theme-success: 21, 128, 61 !important;\n        --v-theme-warning: 180, 83, 9 !important;\n        --v-theme-error: 179, 38, 30 !important;\n        --v-theme-info: 30, 78, 140 !important;\n\n        /* Text and icons sitting on top of a filled chip or button. */\n        --v-theme-on-success: 255, 255, 255 !important;\n        --v-theme-on-warning: 255, 255, 255 !important;\n        --v-theme-on-error: 255, 255, 255 !important;\n        --v-theme-on-info: 255, 255, 255 !important;\n    }\n\n    .border-neutral {\n        border-top: 4px solid #8894a6;\n    }\n\n    .border-success {\n        border-top: 4px solid rgb(var(--v-theme-success));\n    }\n\n    .border-warning {\n        border-top: 4px solid rgb(var(--v-theme-warning));\n    }\n\n    .border-danger {\n        border-top: 4px solid rgb(var(--v-theme-error));\n    }\n\n    .border-info {\n        border-top: 4px solid rgb(var(--v-theme-info));\n    }\n</style>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":800,"y":240,"wires":[[]]},{"id":"05fdb0d422eb75af","type":"ui-group","name":"KPIs","page":"89515a0645eddeee","width":"12","height":1,"order":1,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"89515a0645eddeee","type":"ui-page","name":"Home","ui":"6481b1c613ec9a93","path":"/home","icon":"home","layout":"grid","theme":"faac104f34962f3e","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"6481b1c613ec9a93","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control","ui-number-input","ui-file-input","ui-button","ui-button-group","ui-dropdown","ui-radio-group","ui-slider","ui-switch","ui-text","ui-table","ui-gauge","ui-chart","ui-template","ui-markdown","ui-progress","ui-webcam"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":false},{"id":"faac104f34962f3e","type":"ui-theme","name":"Default Theme","colors":{"surface":"#ffffff","primary":"#1e4e8c","bgPage":"#eef1f5","groupBg":"#ffffff","groupOutline":"#d3dae3"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"057822a3ade579c5","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.30.2"}}]
```
::

7. Wire the nodes: **Poll Data (15 sec) → Set Params → KPI Query → KPI Cards**, and **Filters Changed → Set Params**.

Deploy and open `/home`. The six cards fill in, and on the seeded data the drift banner should appear right away, because the generator creates records whose stored status no longer matches their due date.

![the KPI row showing six cards and the summary strip](https://flowfuse.com/blog/2026/07/images/kpi-cards-calibration.png) &#x2A;Six figures worked out from the due dates, with the active filter and refresh time shown in the header.*

## Listing Every Instrument with Days Remaining

The cards tell a supervisor how much is overdue. This table tells them which tools, so someone can actually go and collect them. It's a worklist rather than a full register dump, which is why the time window scopes it down.

1. Add a `link in` node named "Refresh Asset Table" and point it at the link out from the KPI flow. Taking the filters from that message instead of reading context again is what keeps the table and the cards working from the same selection.
2. Add a `tables-query` node named "Asset Rows":

```sql
SELECT
    -- Sent back so the table can state its own scope in the header.
    COALESCE($timeWindow::text, 'Next 90 days') AS filter_window,

    tool_id,
    equipment_name,
    department,
    location,
    serial_number,

    -- Same 30-day policy threshold as the KPI buckets, so a tool never reads
    -- one status here and another elsewhere. The bare column name still
    -- refers to the table column.
    CASE
        WHEN next_due_ts < NOW() THEN 'Overdue'
        WHEN next_due_ts <= NOW() + INTERVAL '30 days' THEN 'DueSoon'
        ELSE 'Valid'
    END AS status,
    status AS stored_status,

    last_calibration_ts,
    next_due_ts,
    calibration_interval_months,
    calibration_lab,
    certificate_no,

    -- Negative for anything already past due, which the widget shows as
    -- "12d overdue" rather than "-12d".
    (next_due_ts::date - CURRENT_DATE) AS days_remaining

FROM calibration_assets

-- This is a worklist, not the whole register: the window scopes it to what
-- needs attention. Overdue tools have a past due date, so the upper bound
-- already includes them; no separate clause needed.
WHERE (COALESCE($department::text, 'All') = 'All'
       OR department = $department::text)
  AND next_due_ts <= NOW() + (
      CASE COALESCE($timeWindow::text, 'Next 90 days')
          WHEN 'Next 7 days'  THEN INTERVAL '7 days'
          WHEN 'Next 30 days' THEN INTERVAL '30 days'
          WHEN 'Next 90 days' THEN INTERVAL '90 days'
          WHEN 'All future'   THEN INTERVAL '100 years'
          ELSE INTERVAL '90 days'
      END
  )

ORDER BY next_due_ts ASC
LIMIT 500;
```

Sorting by due date ascending puts the worst offenders at the top, which is the only order that makes a calibration list useful. `stored_status` is included but not used by the widget, so it's there when you want to see exactly which records have drifted rather than just how many.

3. Import the **Asset Table** `ui-template` below and assign it to the **Asset Detail** group. The complete component is provided below, so there's no need to build it yourself. It shows a Vuetify data table with a status chip per row, formatted dates, and days remaining shown as "12d overdue" or "due today". Its header names the active window, so it's clear the list is scoped rather than the full register. Above the table sit a search box and a status toggle with live counts for Overdue, Due soon and Valid, filtering the rows already on the page without hitting the database again. The Department column hides itself when every row belongs to the same department, since a single-department view makes it a fixed value.

::render-flow{:height='300'}
```json
[{"id":"9bb12e97685f0e01","type":"ui-template","z":"1c5b2364213044a7","g":"e7cdada1bef716e5","group":"13c06e7c625a1885","page":"","ui":"","name":"Asset Table","order":1,"width":0,"height":0,"head":"","format":"<template>\n    <v-card class=\"pa-4\" elevation=\"1\" rounded=\"lg\">\n\n        <!-- Toolbar -->\n        <v-row dense align=\"center\" class=\"mb-2\">\n            <v-col cols=\"12\" md=\"5\">\n                <div class=\"text-subtitle-1 font-weight-bold\">\n                    Asset Detail<span v-if=\"windowLabel\"> &middot; {{ windowLabel }}</span>\n                </div>\n                <div class=\"text-caption text-medium-emphasis\">\n                    {{ filteredRows.length }} of {{ rows.length }} due in this window\n                </div>\n            </v-col>\n\n            <v-col cols=\"12\" md=\"4\">\n                <v-btn-toggle v-model=\"statusFilter\" density=\"compact\" variant=\"outlined\" divided mandatory>\n                    <v-btn value=\"All\" size=\"small\">All</v-btn>\n                    <v-btn value=\"Overdue\" size=\"small\" color=\"error\">\n                        Overdue ({{ counts.Overdue }})\n                    </v-btn>\n                    <v-btn value=\"DueSoon\" size=\"small\" color=\"warning\">\n                        Due soon ({{ counts.DueSoon }})\n                    </v-btn>\n                    <v-btn value=\"Valid\" size=\"small\" color=\"success\">\n                        Valid ({{ counts.Valid }})\n                    </v-btn>\n                </v-btn-toggle>\n            </v-col>\n\n            <v-col cols=\"12\" md=\"3\">\n                <v-text-field v-model=\"search\" label=\"Search assets\" density=\"compact\" variant=\"solo-filled\"\n                    hide-details clearable prepend-inner-icon=\"mdi-magnify\"></v-text-field>\n            </v-col>\n        </v-row>\n\n        <v-data-table :headers=\"visibleHeaders\" :items=\"filteredRows\" :search=\"search\" :sort-by=\"sortBy\"\n            :items-per-page=\"10\" density=\"compact\" item-value=\"tool_id\" fixed-header height=\"420\" hover>\n\n            <template #item.status=\"{ item }\">\n                <v-chip :color=\"cell(item).status_color\" size=\"small\" variant=\"flat\">\n                    {{ cell(item).status }}\n                </v-chip>\n            </template>\n\n            <template #item.last_calibration_ts=\"{ item }\">\n                {{ cell(item).last_cal_text }}\n            </template>\n\n            <template #item.next_due_ts=\"{ item }\">\n                <span :class=\"cell(item).days_remaining < 0 ? 'text-error font-weight-bold' : ''\">\n                    {{ cell(item).next_due_text }}\n                </span>\n            </template>\n\n            <template #item.days_remaining=\"{ item }\">\n                <span :class=\"cell(item).days_remaining < 0 ? 'text-error font-weight-bold' : ''\">\n                    {{ cell(item).days_text }}\n                </span>\n            </template>\n\n            <template #item.calibration_interval_months=\"{ item }\">\n                {{ cell(item).calibration_interval_months }} mo\n            </template>\n\n            <template #no-data>\n                <div class=\"pa-6 text-center text-medium-emphasis\">\n                    No assets match the current filters.\n                </div>\n            </template>\n\n        </v-data-table>\n    </v-card>\n</template>\n\n<script>\n    export default {\n        data() {\n            return {\n                rows: [],\n                windowLabel: '',\n                search: '',\n                statusFilter: 'All',\n                sortBy: [{ key: 'next_due_ts', order: 'asc' }],\n                headers: [\n                    { title: 'Tool ID', key: 'tool_id', width: '110px' },\n                    { title: 'Equipment', key: 'equipment_name' },\n                    { title: 'Department', key: 'department', width: '130px' },\n                    { title: 'Location', key: 'location', width: '140px' },\n                    { title: 'Status', key: 'status', width: '120px' },\n                    { title: 'Interval', key: 'calibration_interval_months', width: '100px' },\n                    { title: 'Last calibrated', key: 'last_calibration_ts', width: '140px' },\n                    { title: 'Next due', key: 'next_due_ts', width: '140px' },\n                    { title: 'Remaining', key: 'days_remaining', align: 'end', width: '120px' }\n                ]\n            }\n        },\n\n        computed: {\n            filteredRows() {\n                if (this.statusFilter === 'All') return this.rows\n                return this.rows.filter(r => r.status === this.statusFilter)\n            },\n\n            // A single-department view makes that column a constant, so drop it.\n            visibleHeaders() {\n                const depts = new Set(this.rows.map(r => r.department))\n                if (depts.size > 1) return this.headers\n                return this.headers.filter(h => h.key !== 'department')\n            },\n\n            counts() {\n                const c = { Overdue: 0, DueSoon: 0, Valid: 0 }\n                for (const r of this.rows) {\n                    if (c[r.status] !== undefined) c[r.status]++\n                }\n                return c\n            }\n        },\n\n        watch: {\n            msg: {\n                handler(msg) { this.applyMsg(msg) },\n                immediate: true,\n                deep: true\n            }\n        },\n\n        mounted() {\n            this.applyMsg(this.msg)\n            this.$socket.on('msg-input:' + this.id, this.applyMsg)\n        },\n\n        unmounted() {\n            this.$socket.off('msg-input:' + this.id, this.applyMsg)\n        },\n\n        methods: {\n            applyMsg(msg) {\n                const payload = msg && msg.payload\n                if (!Array.isArray(payload)) return\n\n                // Constant across rows; used to caption the table's scope.\n                if (payload[0] && payload[0].filter_window) {\n                    this.windowLabel = payload[0].filter_window\n                }\n\n                this.rows = payload\n                    .filter(r => r && typeof r === 'object')\n                    .map(r => {\n                        const days = (r.days_remaining === null || r.days_remaining === undefined)\n                            ? null\n                            : Number(r.days_remaining)\n                        return {\n                            ...r,\n                            days_remaining: days,\n                            last_cal_text: this.fmtDate(r.last_calibration_ts),\n                            next_due_text: this.fmtDate(r.next_due_ts),\n                            days_text: this.daysText(days),\n                            status_color: this.statusColor(r.status)\n                        }\n                    })\n            },\n\n            // Vuetify 3 passes the raw item on some minors and a wrapper on\n            // others, so normalise before reading fields.\n            cell(item) {\n                return (item && item.raw) ? item.raw : item\n            },\n\n            fmtDate(value) {\n                if (!value) return '-'\n                const d = new Date(value)\n                if (isNaN(d.getTime())) return value\n                return d.toLocaleDateString([], { day: '2-digit', month: 'short', year: 'numeric' })\n            },\n\n            daysText(days) {\n                if (days === null) return '-'\n                if (days < 0) return Math.abs(days) + 'd overdue'\n                if (days === 0) return 'due today'\n                return days + 'd'\n            },\n\n            statusColor(status) {\n                if (status === 'Overdue') return 'error'\n                if (status === 'DueSoon') return 'warning'\n                if (status === 'Valid') return 'success'\n                return 'grey'\n            }\n        }\n    }\n</script>","storeOutMessages":true,"passthru":false,"resendOnRefresh":true,"templateScope":"local","className":"","x":590,"y":400,"wires":[[]]},{"id":"13c06e7c625a1885","type":"ui-group","name":"Asset Detail","page":"89515a0645eddeee","width":"12","height":1,"order":2,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"89515a0645eddeee","type":"ui-page","name":"Home","ui":"6481b1c613ec9a93","path":"/home","icon":"home","layout":"grid","theme":"faac104f34962f3e","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"6481b1c613ec9a93","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control","ui-number-input","ui-file-input","ui-button","ui-button-group","ui-dropdown","ui-radio-group","ui-slider","ui-switch","ui-text","ui-table","ui-gauge","ui-chart","ui-template","ui-markdown","ui-progress","ui-webcam"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":false},{"id":"faac104f34962f3e","type":"ui-theme","name":"Default Theme","colors":{"surface":"#ffffff","primary":"#1e4e8c","bgPage":"#eef1f5","groupBg":"#ffffff","groupOutline":"#d3dae3"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"563dc603fb7848c5","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.30.2"}}]
```
::

4. Wire the nodes: **Refresh Asset Table → Asset Rows → Asset Table**.

Deploy and open `/home`. The table fills in below the cards, most urgent first, with its header naming the window it covers. Change a dropdown and both halves of the page update together.

![the asset detail table with the status toggle and search box](https://flowfuse.com/blog/2026/07/images/calibration-asset-table.png) &#x2A;Instruments due inside the selected window, soonest due first, with status chips and days remaining.*

> **Note:** The toggle counts describe the table, not the register, so they will read lower than the cards above. That's the point of the split: the cards answer "how are we doing," and the table answers "what needs collecting." Select *All future* and the two match.

## Checking a Tool at the Station

A dashboard in the quality office doesn't reach the person about to pick up a torque wrench. This page does: hold the calibration label to a camera, press one button, get one answer.

1. Add a `ui-button` node named "Scan Label Button" in the **Verdict** group, order 1. Set the label to `SCAN` and the payload to the string `capture`, which tells the webcam to take a frame.
2. Add a `ui-webcam` node in the **Scanner** group, with **Pass through** and **QR detection** both off. Leave image width, height and quality blank to use the camera's defaults.
3. Add a `change` node that sets `msg.payload` to `msg.payload.image`. The webcam outputs an object; the OCR node just needs the image.
4. Add a `simple-ocr` node, then a `link out` / `link in` pair to carry the result down to the next row of the canvas.

> **Tip:** OCR keeps this tutorial hardware-free, but if your labels have a barcode or QR code, scanning one is faster and far more reliable than reading printed text. Swap the camera and OCR nodes for a [barcode scanner](https://flowfuse.com/node-red/peripheral/barcodescanner/) and feed the decoded ID straight into "Set Tool ID," and everything downstream will keep working. You can also drop "Extract Tool ID" and "Scan Valid?", since a scanner either returns an ID or nothing.

5. Add a `function` node named "Extract Tool ID":

> **Tip:** The same goes for function node logic. Describe what you want the function to do in plain English, and [FlowFuse Expert](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/#function-node-creation) will generate the code for you.

```javascript
// Stickers read TL followed by four digits. OCR loses the hyphen and swaps
// look-alike characters, so normalise before matching.
const text = String(msg.payload?.text || msg.payload || '');
const flat = text.toUpperCase().replace(/[^A-Z0-9]/g, '');

const FIXES = { O: '0', Q: '0', I: '1', L: '1', S: '5', B: '8', Z: '2', G: '6' };

const m = flat.match(/T[L1I]([A-Z0-9]{4})/);
const digits = m ? m[1].replace(/[A-Z]/g, c => FIXES[c] || c) : '';
const toolId = /^\d{4}$/.test(digits) ? 'TL-' + digits : null;

msg.payload = {
    success: !!toolId,
    toolId,
    // Shows what OCR actually read when a scan fails.
    rawText: text.replace(/\s+/g, ' ').trim()
};
return msg;
```

Wire a `debug` node to this as well and leave it enabled. When a scan fails, `rawText` shows what the camera actually read, which is the difference between fixing the label and guessing at it.

> **Note:** The pattern above expects `TL` followed by four digits, because that's what the seeded data uses. Your labels almost certainly look different: a different prefix, more digits, a plant code, or no letters at all. Change the regex and the length check to match your own sticker format before you test this on real tools, or every scan will come back as **Label not readable**.

6. Add a `switch` node named "Scan Valid?" on `payload.success`, with **is true** on the first output and **otherwise** on the second. A failed read skips the database entirely.
7. Add a `change` node named "Set Tool ID" on the true branch, with two rules:
   - Set `queryParameters` to the JSONata `{ "toolId": $trim(payload.toolId) }`
   - Set `scannedId` to the JSONata `$trim(payload.toolId)`, so the ID survives to the verdict even when no row comes back
8. Add a `tables-query` node named "Look Up Tool":

```sql
SELECT
    tool_id,
    equipment_name,

    -- The safety answer comes from the date, not the stored status flag,
    -- which can go stale if whatever recalculates it falls behind.
    (next_due_ts >= NOW()) AS ok_to_use

FROM calibration_assets

-- Deliberately NOT filtered by department or time window: a scan is a
-- lookup of one tool, not a view. Case, padding and hyphens are all
-- normalised away, at the cost of the index, which is fine at register size.
WHERE replace(upper(btrim(tool_id)), '-', '')
    = replace(upper(btrim($toolId)), '-', '');
```

9. Add a `function` node named "Build Verdict". Wire **both** the query output and the switch's second output into it:

```javascript
// Two paths feed this node: a completed lookup, and a failed scan routed
// straight past the query. Tell them apart by payload shape.
const p = msg.payload;

if (p?.success === false) {
    msg.payload = { state: 'scan_failed' };
    return msg;
}

const row = Array.isArray(p) ? p[0] : p;

if (!row?.tool_id) {
    msg.payload = { state: 'not_found', scannedId: msg.scannedId };
    return msg;
}

msg.payload = {
    state: row.ok_to_use ? 'ok' : 'blocked',
    tool: row
};
return msg;
```

Four states come out of it, and they're the only four an operator ever sees:

| State         | When                       | Verdict                       |
| ------------- | -------------------------- | ----------------------------- |
| `ok`          | Due date in the future     | **OK to use**, green          |
| `blocked`     | Due date has passed        | **Do not use**, red           |
| `not_found`   | ID read, no matching row   | **Not in register**, amber    |
| `scan_failed` | No `TL-####` pattern found | **Label not readable**, amber |

10. Add a `function` node named "Format Notification". It shows what was scanned, the verdict, and what to do about it:

```javascript
const v = msg.payload || {};
const t = v.tool;

// timeout 0 on 'blocked' is deliberate: an expired-tool verdict must be
// dismissed by a person, not fade out while nobody is watching.
const VERDICTS = {
    ok:          { text: 'OK to use',          do: 'Carry on.',                        color: '#15803d', timeout: 8 },
    blocked:     { text: 'Do not use',         do: 'Tag it and tell your supervisor.',  color: '#b3261e', timeout: 0 },
    not_found:   { text: 'Not in register',    do: 'Tell your supervisor.',             color: '#b45309', timeout: 12 },
    scan_failed: { text: 'Label not readable', do: 'Wipe the label and scan again.',    color: '#b45309', timeout: 8 }
};

const cfg = VERDICTS[v.state] || VERDICTS.scan_failed;

// ui-notification renders raw HTML, so escape what came from the register.
const esc = s => String(s ?? '').replace(/[<>&"]/g,
    c => ({ '<': '&lt;', '>': '&gt;', '&': '&amp;', '"': '&quot;' }[c]));

const scanned = t
    ? esc(t.tool_id) + ' - ' + esc(t.equipment_name)
    : esc(v.scannedId || 'No ID read');

msg.payload = `<div style="font-size:1rem;opacity:.85">${scanned}</div>`
    + `<div style="font-size:2rem;font-weight:700;margin:4px 0">${cfg.text}</div>`
    + `<div style="font-size:1rem">${cfg.do}</div>`;

msg.color = cfg.color;
msg.timeout = cfg.timeout;
return msg;
```

11. Add a `ui-notification` node named "Verdict" and select your ui-base. Set **Position** to **center center**, turn off **Use default colour**, turn on **Show countdown**, **Allow dismiss** and **Allow raw HTML**. The display time and colour on the node are only fallbacks; `msg.timeout` and `msg.color` override them for each verdict.
12. Add a `ui-markdown` node named "Tool Check Instructions" in the **Verdict** group, order 2:

```markdown
<div style="text-align: center">

### Before you use a tool

</div>

**1** Hold the calibration label flat in front of the camera.

**2** Press **SCAN**.

**3** Read the message in the middle of the screen.

---

**"OK to use"**: the tool is inside its calibration interval. Carry on.

**"Do not use"**: set the tool aside, tag it, and tell your supervisor. If you have already used it on parts today, say so; those measurements need checking.

**"Not in register"** or **"Label not readable"**: wipe the label and scan again. If it fails twice, tell your supervisor.

---

Anything other than **"OK to use"** means the tool stays out of production.
```

13. Wire the nodes: &#x2A;*Scan Label Button → ui-webcam → change → simple-ocr → Extract Tool ID → Scan Valid?**, then **Scan Valid? (true) → Set Tool ID → Look Up Tool → Build Verdict**, and **Scan Valid? (otherwise) → Build Verdict → Format Notification → Verdict**.

Deploy and open `/tool-check` on a device with a camera. Hold a label reading `TL-0007`, or one in whatever format you configured above, in front of it and press **SCAN**. Whatever the seeded data says about that tool is what comes back. Because the verdict compares the date instead of reading the status column, it will always agree with the Home page.

![the Tool Check page with the camera preview and SCAN button](https://flowfuse.com/blog/2026/07/images/tool-check.png) &#x2A;The scanner page: camera preview, one button, and the operator instructions below it.*

## What Next

You've built a calibration application that answers two different questions from the same data. The office screen tells a quality engineer how the plant stands and what needs collecting this week. The station screen tells an operator whether the tool in their hand is fit to use. Both read the due date, so neither can drift from the other.

Right now it runs on generated data. To go live, remove the simulator flow and point the queries at your own register. Just alias your column names in the `SELECT` lists, and everything downstream keeps working. If your records sit in a CMMS or ERP behind an API, swap the query nodes for `http request` nodes and nothing else changes. From there, the obvious next steps are ones the register already supports: email the overdue list to the calibration lab each Monday, or [notify](https://flowfuse.com/node-red/notification/) someone the moment a critical gauge goes overdue instead of waiting for a screen to be looked at. The same approach works for [defect tracking](https://flowfuse.com/blog/2026/07/defect-and-quality-monitoring/) and [downtime](https://flowfuse.com/blog/2026/07/build-downtime-logger/) too, and for the other [manufacturing dashboards](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/) teams build on the same data. It also pairs with floor-level checks such as a [layered process audit](https://flowfuse.com/blog/2026/08/layered-process-audit/), where a tool's calibration status is exactly the kind of item this dashboard can hand the auditor an answer for instead of a lookup. See how manufacturers are using it on our [automotive solutions page](https://flowfuse.com/industries/automotive/).


# Control and Track Machines on the Factory Floor

Operators need more than buttons to control machines - they also need visibility into what's actually happening on the factory floor. Knowing whether a motor is running is useful, but knowing how long it has been running helps with maintenance, production tracking, and troubleshooting.

In this tutorial, you'll connect FlowFuse to a Siemens S7 PLC, build an operator dashboard to control a motor and stack light, and automatically track the runtime of each device. By the end, you'll have a dashboard that not only sends commands to the PLC but also displays live operating time for every connected device.

:lite-youtube{style="width: 100%; aspect-ratio: 16/9; background-image: url('/blog/2026/07/images/demo-thumbnail.jpg'); background-size: cover; background-position: center;" title="Control and Track the Shopfloor Machines" videoid="kiOufj0ghxg"}

## Prerequisites

Before you begin, make sure you have the following:

- A Siemens S7 PLC, or **S7-PLCSIM** if you're using a simulated PLC.
- A FlowFuse instance running on your edge device with the Device Agent installed. If you don't already have one, [sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and follow the [Device Agent Quick Start guide](https://flowfuse.com/docs/device-agent/quickstart/) to connect your first device.
- The following packages installed:
  - `@flowfuse/node-red-dashboard`
  - `node-red-contrib-s7`
  - `node-red-contrib-hourglass`
- A motor and stack light connected to the PLC, or simulated outputs.

> Note: This tutorial uses a Siemens S7 PLC and the node-red-contrib-s7 package, but FlowFuse isn't limited to S7 PLCs. It has community nodes for most major PLC brands and protocols, including Allen-Bradley/Rockwell (EtherNet/IP), Modbus, OPC UA, Mitsubishi, and more, so you can follow the same pattern with whichever PLC and connection node matches your hardware.

## Example PLC Logic

The demo above uses a simple example PLC program with four normally open contacts stored inside a data block, each controlling a PLC output:

- Motor
- RedLightCmd
- YellowLightCmd
- GreenLightCmd

Whenever one of these data block values is set to `TRUE`, the PLC energizes the corresponding output. Setting the value back to `FALSE` turns the output off again.

Throughout this tutorial, FlowFuse writes to these data block variables whenever an operator interacts with the dashboard. At the same time, it continuously reads those same variables so it always knows the current state of each device. We'll later use those live values to calculate runtime automatically.

If your PLC program is structured differently, that's fine: you just need to know which data block(s) and addresses correspond to the outputs you want to control, and adjust the variable configuration in the following sections accordingly.

The example ladder logic used in this tutorial is shown below.

![Example ladder logic with four normally open contacts controlling the motor, red light, yellow light, and green light outputs](https://flowfuse.com/blog/2026/07/images/plc-program-runtime.png)&#x2A;The example ladder logic used in this tutorial: four contacts controlling the motor and the three stack light colors.*

## Connecting FlowFuse to the PLC

With an example PLC program in mind, let's establish communication between FlowFuse and the controller.

We'll use the `node-red-contrib-s7` package to communicate with the PLC. The first task is creating an S7 endpoint, which stores the connection details that every S7 node in the flow will reuse.

### Configure the S7 Endpoint

Drag either an **S7 In** or **S7 Out** node onto the workspace and create a new **S7 Endpoint**.

Configure it as follows:

1. Select &#x2A;*Ethernet (ISO on TCP)** as the transport.
2. Enter the PLC's IP address.
3. Leave the port set to **102**.
4. Set the connection mode to **Rack**.
5. Enter the appropriate **Rack** and **Slot** values for your PLC.
6. Set the **Cycle Time** and **Timeout** values according to your application's requirements.

Your configuration should look similar to the example below.

![S7 Endpoint configuration showing transport, IP address, rack, slot, and cycle time fields](https://flowfuse.com/blog/2026/07/images/plc-config.png)&#x2A;S7 Endpoint configuration used to connect FlowFuse to the PLC over Ethernet (ISO on TCP).*

The endpoint now manages communication with the PLC, allowing every S7 node in the flow to reuse the same connection rather than creating multiple independent PLC connections.

### Add the PLC Variables

Next, tell the endpoint which PLC variables it should read and write.

1. Open the **Variables** tab.
2. Add the following variables.

| Variable     | Address    |
| ------------ | ---------- |
| Motor        | `DB1,X0.0` |
| Red Light    | `DB1,X0.1` |
| Yellow Light | `DB1,X0.2` |
| Green Light  | `DB1,X0.3` |

These addresses correspond to the example ladder logic used in this tutorial. Replace them with the data block and address values that match the outputs on your own PLC. If you'd like to learn more about how variable addresses are defined for the S7 nodes, see our guide on [Addressing Scheme for Variables in FlowFuse with the S7 Node](https://flowfuse.com/blog/2025/01/integrating-siemens-s7-plcs-with-node-red-guide/#addressing-scheme-for-variables-in-node-red-with-the-s7-node).

After adding them, your configuration should resemble the following.

![S7 Endpoint Variables tab listing Motor, Red Light, Yellow Light, and Green Light with their data block addresses](https://flowfuse.com/blog/2026/07/images/s7-config-variables-counter.png)&#x2A;The four PLC variables mapped to their data block addresses in the S7 Endpoint.*

### Add the Output Nodes

The dashboard will control each PLC output independently, so we'll create one **S7 Out** node per Output.

1. Drag four **S7 Out** nodes onto the workspace.
2. Configure each node to use the endpoint created earlier.
3. Assign one PLC variable to each node:
   - Motor
   - Red Light
   - Yellow Light
   - Green Light

All four nodes are configured the same way: only the assigned variable changes. For reference, here's the configuration for the **Motor** node; configure the other three the same way, assigning **Red Light**, **Yellow Light**, and **Green Light** respectively.

![S7 Out node configured to write to the Motor variable using the S7 Endpoint](https://flowfuse.com/blog/2026/07/images/motor-s7-out.png)&#x2A;Reference configuration for the Motor S7 Out node. Repeat this setup for Red Light, Yellow Light, and Green Light, changing only the assigned variable.*

Each node is now responsible for updating a single PLC variable whenever it receives a new value.

### Read the PLC Status

Writing values to the PLC is only half of the solution. We also need to monitor the current output states so the dashboard always reflects what's happening inside the controller.

1. Drag an **S7 In** node onto the workspace.
2. Select the same S7 Endpoint.
3. Set the node to **All Variables** mode.
4. Connect a **Debug** node to its output.
5. Deploy the flow.

Whenever one of the configured variables changes, the S7 In node publishes the latest state of every PLC variable as a single object.

```javascript
{
    "Motor": true,
    "Red Light": false,
    "Yellow Light": false,
    "Green Light": true
}
```

This message represents the live state of the PLC. Later in the tutorial we'll use these values to synchronize the dashboard and determine when each runtime timer should start or stop.

![S7 In node set to All Variables mode connected to a Debug node, with the Debug panel showing the live PLC state object](https://flowfuse.com/blog/2026/07/images/read-all-s7-in.png)&#x2A;S7 In node reading all PLC variables at once and publishing the combined state to a Debug node.*

### Verify the Connection

Once everything has been configured, deploy the flow one final time.

If the connection is successful, every S7 node should display an **Online** status.

At this point, FlowFuse can both control the PLC outputs and continuously monitor their current state. In the next section, we'll use these S7 nodes to build an operator dashboard for controlling the motor and stack light.

## Building the Dashboard

With communication to the PLC established, we can now build the operator interface.

For this tutorial, the dashboard provides controls for both the motor and the stack light. The motor uses two buttons: one to start it and another to stop it, while each stack light color is controlled using its own switch.

The finished dashboard will contain the following widgets.

| Widget | Purpose      |
| ------ | ------------ |
| Button | Start Motor  |
| Button | Stop Motor   |
| Switch | Red Light    |
| Switch | Yellow Light |
| Switch | Green Light  |

### Control the Motor

Let's start by creating the controls for the motor.

1. Add two **Button** widgets to the dashboard.
2. Configure the first button with:
   - **Label:** Start Motor
   - **Payload:** `true`
3. Configure the second button with:
   - **Label:** Stop Motor
   - **Payload:** `false`
4. Connect both buttons to the **Motor** S7 Out node.

Whenever an operator presses one of these buttons, the corresponding Boolean value is written to the PLC. Writing `true` starts the motor, while writing `false` stops it.

Configure each button the same way, changing only the label and payload. For example, here's the configuration for the **Start Motor** button:

![Button widget configuration with label "Start Motor" and payload set to true](https://flowfuse.com/blog/2026/07/images/motor-on-button-config.png)&#x2A;Example Button widget configuration for Start Motor. Use the same setup for Stop Motor, with the payload set to `false`.*

### Control the Stack Light

Next, create controls for each color of the stack light.

Rather than using buttons, switches are a better choice because they clearly indicate whether each light is currently enabled or disabled.

1. Add three **Switch** widgets to the dashboard.
2. Label them:
   - Red Light
   - Yellow Light
   - Green Light
3. Configure each switch with:
   - **ON Payload:** `true`
   - **OFF Payload:** `false`
4. Connect each switch to its corresponding **S7 Out** node.

When a switch changes state, FlowFuse immediately writes the updated value to the PLC, turning the selected light on or off.

Configure each switch the same way, changing only the label and connected node. For example, here's the configuration for the **Red Light** switch:

![Switch widget configuration for Red Light with ON payload true and OFF payload false](https://flowfuse.com/blog/2026/07/images/red-led-switch.png)&#x2A;Example Switch widget configuration for Red Light. Use the same setup for Yellow Light and Green Light.*

### Test the Dashboard

At this point the dashboard is fully wired to the PLC.

Deploy the flow and open the dashboard in your browser. Verify that:

- Pressing **Start Motor** starts the motor.
- Pressing **Stop Motor** stops it.
- Each switch controls the correct stack light output.
- Changes made from the dashboard are immediately reflected in the PLC.

You now have a functional PLC control dashboard that can operate each connected device independently.

## Tracking Device Runtime

The dashboard can now control the PLC, but it still doesn't provide any information about how long each device has been operating.

Since the **S7 In** node continuously reports the state of every PLC output, we can use those values to determine when a device starts and stops running. We'll use the **Hourglass** node to maintain an independent runtime counter for each device.

Before connecting the Hourglass nodes, we first need to convert the PLC states into the commands they expect.

### Convert PLC States into Timer Commands

The S7 In node outputs all configured variables as a single object. The Hourglass node, however, expects individual messages containing either a `start` or `stop` command.

We'll use a **Function** node to bridge this gap.

1. Drag a **Function** node onto the workspace after the **S7 In** node.
2. Configure the node with **four outputs**.
3. Replace the default code with the following:

```javascript
return [
    { command: msg.payload.Motor ? "start" : "stop" },
    { command: msg.payload["Red Light"] ? "start" : "stop" },
    { command: msg.payload["Yellow Light"] ? "start" : "stop" },
    { command: msg.payload["Green Light"] ? "start" : "stop" }
];
```

The Function node examines the current state of each PLC output and converts it into either a `start` or `stop` command. Update the field names (`msg.payload.Motor`, etc.) to match the variable names you used in your own PLC Variables configuration.

For example:

- If the motor is running (`true`), the first output sends `{ command: "start" }`.
- If the motor stops (`false`), it sends `{ command: "stop" }`.

The same logic is applied independently to each stack light.

![Function node code editor showing the four-output script that converts PLC states into start and stop commands](https://flowfuse.com/blog/2026/07/images/function-config-state-to-commands.png)&#x2A;Function node converting the PLC's live output states into start/stop commands for the four Hourglass nodes.*

### Add the Hourglass Nodes

Now that each device has its own stream of timer commands, we can begin tracking runtime.

1. Drag four Hourglass nodes onto the workspace.
2. Configure each node to use English as the language.
3. Use one Hourglass node for each device:
   - Motor
   - Red Light
   - Yellow Light
   - Green Light

All four nodes use the same configuration: only the device they're wired to changes.

Each Hourglass node maintains its own accumulated runtime. This means every device is tracked independently, allowing the motor and each stack light to start and stop without affecting the timers for the other devices.

### Request Runtime Updates

The Hourglass node stores the elapsed time internally and only reports its current status when requested. To keep the dashboard updated in real time, we'll periodically ask each Hourglass node to publish its current runtime.

1. Add an **Inject** node to the workspace.
2. Configure it to repeat every **1 second**.
3. Set the payload type to **JSON**.
4. Use the following payload:

```json
{
    "command": "status"
}
```

5. Connect the Inject node to all four Hourglass nodes.

Every second, the Inject node sends a `status` command, prompting each Hourglass node to return its latest runtime information.

At this point, every Hourglass node is continuously tracking the runtime of its assigned device and publishing an updated status once per second. The final step is displaying that information on the dashboard.

## Displaying the Runtime

We'll use **UI Template** widgets to build a simple HMI-style runtime display for each device.

### Create the Runtime Display

1. Drag four **UI Template** widgets onto the workspace and configure each one to use the appropriate Page and Group based on your dashboard layout and type to "Widget ( Group Scoped )"
2. Connect each Hourglass node to its corresponding UI Template.
3. Give each widget an appropriate label:
   - Motor
   - Red Light
   - Yellow Light
   - Green Light

> **Note:** The dashboard layout, groups, and theme are intentionally left to your preference. You can organize the widgets in whatever way best suits your application. For guidance on pages, groups, navigation, layouts, and styling in FlowFuse Dashboard, see [FlowFuse Dashboard: Layout, Navigation & Styling](https://flowfuse.com/blog/2024/05/node-red-dashboard-2-layout-navigation-styling/).

Whenever an Hourglass node publishes its status, the connected UI Template receives a message similar to the following.

```javascript
{
    started: true,
    elapsed: {
        time: {
            hours: 0,
            minutes: 12,
            seconds: 34
        }
    }
}
```

The `started` property indicates whether the device is currently running, while `elapsed.time` contains the accumulated runtime.

### Build the Runtime Widget

Paste the following code into each **UI Template** widget, updating only the device label (for example **Motor**, **Red Light**, **Yellow Light**, or **Green Light**) where required.

> **Note:** If you'd like a different design for the runtime widget, you can use **FlowFuse Expert**. Simply describe the UI you want in plain English, and it will generate the component for your dashboard. Learn more about [FlowFuse Expert](https://flowfuse.com/docs/user/expert/node-red-embedded-ai).

```html
<template>
  <div class="hmi-timer" :class="{ running: started }" @mouseenter="hover = true" @mouseleave="hover = false">
    <span class="label">Motor</span>
    <span class="clock">{{ clock }}</span>
  </div>
</template>

<script>
export default {
  name: 'HmiTimer',
  data() {
    return { hover: false }
  },
  computed: {
    started() {
      return this.msg?.started === true
    },
    clock() {
      const t = this.msg?.elapsed?.time
      const pad = (n) => String(n ?? 0).padStart(2, '0')

      if (!t) return '00h:00m:00s'

      return `${pad(t.hours)}h:${pad(t.minutes)}m:${pad(t.seconds)}s`
    }
  }
}
</script>

<style scoped>
.hmi-timer {
  --accent: #2ecc71;
  display: flex;
  flex-direction: row;
  align-items: center;
  justify-content: center;
  gap: 16px;
  width: 100%;
  box-sizing: border-box;
  background: #11161d;
  border: 1px solid #2c3744;
  border-radius: 10px;
  font-family: 'Courier New', monospace;
  font-weight: 700;
  letter-spacing: 2px;
  padding: 16px 24px;
  color: #5b6675;
  transition: all .3s ease;
  transform: .95;
}

.label {
  font-size: 2.4rem;
  font-weight: 600;
}

.clock {
  font-size: 2.4rem;
}

.hmi-timer.running {
  padding: 26px 36px;
  color: var(--accent);
  border-color: var(--accent);
  background: #0d1c13;
  box-shadow: 0 0 18px rgba(46, 204, 113, .35),
              inset 0 0 12px rgba(46, 204, 113, .15);
}

.hmi-timer.running .label {
  font-size: 3.6rem;
}

.hmi-timer.running .clock {
  font-size: 5rem;
}
</style>
```

All four widgets use the same template code: only the label changes. For reference, this example uses the **Motor** label; configure the other three the same way, swapping in **Red Light**, **Yellow Light**, and **Green Light**.

![Finished HMI-style runtime widget for the Motor, showing elapsed time and a highlighted green state while running](https://flowfuse.com/blog/2026/07/images/runtime-display-motor.png)&#x2A;Reference result for the Motor runtime widget. Repeat this setup for Red Light, Yellow Light, and Green Light, changing only the label.*

The template formats the elapsed time into an easy-to-read `HHh:MMm:SSs` display and automatically changes its appearance while the device is running. Because each widget is connected to a separate Hourglass node, every device maintains its own independent runtime display.

Deploy the flow and open the dashboard.

Start the motor and toggle each stack light while watching the runtime displays update.


# Build a Defect Tracking and Quality Monitoring Dashboard

Every production line produces defects. On their own they're easy to wave off, a bit of scrap here, an hour of rework there. But add them up and the cost is real, and that's the part most teams never see. The defects are sitting in a spreadsheet nobody sorts, or locked inside a quality system you can't get a live view out of. So the recurring problems stay invisible until someone runs a report, and by then the bad batch has already shipped.

![The finished defect tracking dashboard showing stat cards, Pareto chart, and trend line](https://flowfuse.com/blog/2026/07/images/flowfuse-defect-monitoring-dashboard.png)*The finished defect tracking dashboard showing stat cards, Pareto chart, and trend line*

In this tutorial, you'll build a defect tracking and quality monitoring dashboard using FlowFuse in about 30 minutes. It reads defects from a database, calculates the KPIs a quality engineer actually looks at, and renders them live, filtered by line, shift, and date range.

You can interact with the live demo here: :live-demo-link{href="https://defect-monitoring-dashboard.flowfuse.cloud/dashboard/defects" label="Try the Quality Monitoring Dashboard"}.

By the end, you'll have a foundation you can extend into broader production monitoring or OEE tracking, or a plant-wide quality report.

## What You'll Need

Before you start building, make sure you have the following ready:

- **A FlowFuse account.** [Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} for FlowFuse Cloud, or use a self-hosted instance.
- **A FlowFuse instance up and running.** If you don't have one yet, create a new instance from your FlowFuse Platform.
- **FlowFuse Dashboard installed.** This tutorial uses `@flowfuse/node-red-dashboard` nodes (`ui-text`, `ui-chart`, `ui-table`, and `ui-template`) to build the interface. If it is not already installed, add it from the Node-RED Palette Manager. If you are new to FlowFuse Dashboard, follow the [Getting Started guide](https://dashboard.flowfuse.com/getting-started.html){rel="&#x22;nofollow&#x22;"} to become familiar with the basics before continuing.

> Note: [FlowFuse Tables](https://flowfuse.com/docs/user/ff-tables/) is currently in beta and available to Enterprise tier teams on FlowFuse Cloud, as well as Enterprise licensed self hosted teams running on Kubernetes. If you're on a different tier, you can follow along using any external database instead, Postgres, MySQL, or whatever you already have, with the standard database nodes from the palette. The SQL and flow logic in this tutorial will work the same either way.

## How the Application Works

This dashboard is a read layer. It doesn't capture defects itself; it sits on top of a table of them and turns that table into something a supervisor can read at a glance:

- **Defects live in one table.** Each defect is a row: where it happened, what it was, how severe, its root cause, how it was handled, and what it cost. Something else fills this table: an operator logging defects from a form, or automatic events arriving over MQTT. For the tutorial, a simulator stands in for that source.
- **One query calculates everything.** A single query filters the table once and computes every KPI on the dashboard in one pass, then splits the result across every card, chart, and table, so the whole dashboard updates from a single source of truth.
- **The header drives it all.** Line, shift, and date-range dropdowns live in the dashboard header. Change any one and every widget recalculates together.

## Importing the Simulator

You need a table and data in it before the dashboard can show anything. Rather than build that by hand, import the simulator flow; it creates the `defects` table and fills it for you.

It gives you two generators. A **historical seed** fills about six months of defects, so the charts have something to show right away. A **live feed** then inserts a fresh defect every few seconds, so the dashboard keeps updating on its own while you build.

::render-flow{:height='300'}
```json
[{"id":"fc4cfab8a41f3bdb","type":"group","z":"7f9feb3283fbb929","name":"Data Simulation","style":{"label":true},"nodes":["7ff2fe3d22e543d8","77f9a234e079a6dd","e9c9fbed2e767b9f","23504c3b0f35db82","475645219af52b5e","d978f663921063a7","d2facb93da0e58db","1188c4b2256949a3"],"x":34,"y":219,"w":812,"h":142},{"id":"7ff2fe3d22e543d8","type":"debug","z":"7f9feb3283fbb929","g":"fc4cfab8a41f3bdb","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":260,"wires":[]},{"id":"77f9a234e079a6dd","type":"inject","z":"7f9feb3283fbb929","g":"fc4cfab8a41f3bdb","name":"","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":130,"y":260,"wires":[["e9c9fbed2e767b9f"]]},{"id":"e9c9fbed2e767b9f","type":"function","z":"7f9feb3283fbb929","g":"fc4cfab8a41f3bdb","name":"Historical Seed","func":"// ============================================================\n// SHARED GENERATOR LOGIC (v4 — full station coverage + EV-specific defect)\n// ============================================================\n\n// ---- Helper: weighted random pick ------------------------------\nfunction weightedPick(items, weights) {\n    const r = Math.random();\n    let cumulative = 0;\n    for (let i = 0; i < items.length; i++) {\n        cumulative += weights[i];\n        if (r <= cumulative) return items[i];\n    }\n    return items[items.length - 1];\n}\n\n// ---- Convert an ARRAY of records into column-wise arrays, for a\n// single bulk INSERT ... SELECT * FROM UNNEST(...) query -----------\nfunction recordsToColumnParams(records) {\n    const cols = [\n        \"defect_id\", \"date\", \"line\", \"station\", \"shift\", \"sku\",\n        \"defect_type\", \"defect_category\", \"severity\", \"detected_stage\",\n        \"root_cause\", \"disposition\", \"status\", \"cost_impact\", \"resolution_hours\"\n    ];\n    return cols.map(col => records.map(r => r[col]));\n}\n\n\n// ---- Unique defect_id (no context store needed) ----------------\nfunction nextDefectId() {\n    const rand = Math.floor(Math.random() * 46656).toString(36).padStart(3, \"0\");\n    return \"DEF-\" + Date.now().toString(36).toUpperCase() + \"-\" + rand.toUpperCase();\n}\n\n// ---- Assembly lines: NOT equal — SUV Line has an aging robot cell\nconst LINES = [\"Sedan Line\", \"SUV Line\", \"EV Line\"];\nconst LINE_WEIGHTS = [0.30, 0.45, 0.25];   // SUV Line skewed higher\n\n// ---- Shifts: Night skewed higher (fatigue/less supervision) -----\nconst SHIFTS = [\"Morning\", \"Evening\", \"Night\"];\nconst SHIFT_WEIGHTS = [0.30, 0.25, 0.45];\n\n// ---- Trims: EV is the newest variant, has early teething defects --\nconst SKUS = [\"Base Trim\", \"Sport Trim\", \"Premium Trim\", \"EV Trim\"];\nconst SKU_WEIGHTS = [0.20, 0.20, 0.25, 0.35]; // EV = newest, higher defect rate\n\n// ---- Defect types: Pareto-shaped (80/20 rule), each with a home\n// shop, plausible root causes, and where it typically gets caught.\n// Now covers ALL 5 stations (Chassis & Powertrain and Trim were\n// previously listed as stations but had zero defect types assigned).\nconst DEFECT_TYPES = [\n    {\n        name: \"Weld Crack\", category: \"Body/Weld\", station: \"Body Shop\", weight: 0.24,\n        causes: [\"Robot/Tooling Wear\", \"Operator Error\", \"Calibration Drift\", \"Process Deviation\"],\n        causeWeights: [0.40, 0.30, 0.20, 0.10],\n        stageWeights: [0.05, 0.35, 0.50, 0.10]\n    },\n    {\n        name: \"Paint Defect\", category: \"Paint/Surface\", station: \"Paint Shop\", weight: 0.19,\n        causes: [\"Operator Error\", \"Process Deviation\", \"Environmental Factor\", \"Robot/Tooling Wear\"],\n        causeWeights: [0.35, 0.30, 0.20, 0.15],\n        stageWeights: [0.05, 0.25, 0.55, 0.15]\n    },\n    {\n        name: \"Panel Gap Deviation\", category: \"Dimensional\", station: \"Body Shop\", weight: 0.13,\n        causes: [\"Calibration Drift\", \"Robot/Tooling Wear\", \"Process Deviation\", \"Supplier Material Defect\"],\n        causeWeights: [0.40, 0.30, 0.20, 0.10],\n        stageWeights: [0.25, 0.45, 0.28, 0.02]\n    },\n    {\n        name: \"Door Misalignment\", category: \"Assembly\", station: \"Final Assembly\", weight: 0.10,\n        causes: [\"Operator Error\", \"Process Deviation\", \"Robot/Tooling Wear\"],\n        causeWeights: [0.35, 0.35, 0.30],\n        stageWeights: [0.05, 0.35, 0.55, 0.05]\n    },\n    {\n        name: \"Paint Contamination\", category: \"Material\", station: \"Paint Shop\", weight: 0.09,\n        causes: [\"Supplier Material Defect\", \"Environmental Factor\", \"Process Deviation\"],\n        causeWeights: [0.50, 0.30, 0.20],\n        stageWeights: [0.40, 0.35, 0.20, 0.05]\n    },\n    {\n        name: \"Fluid Leak\", category: \"Powertrain\", station: \"Chassis & Powertrain\", weight: 0.08,\n        causes: [\"Robot/Tooling Wear\", \"Process Deviation\", \"Supplier Material Defect\"],\n        causeWeights: [0.40, 0.35, 0.25],\n        stageWeights: [0.10, 0.40, 0.40, 0.10]\n    },\n    {\n        name: \"Missing Fastener\", category: \"Assembly\", station: \"Final Assembly\", weight: 0.06,\n        causes: [\"Operator Error\", \"Process Deviation\"],\n        causeWeights: [0.60, 0.40],\n        stageWeights: [0.05, 0.30, 0.60, 0.05]\n    },\n    {\n        name: \"Interior Trim Defect\", category: \"Trim\", station: \"Trim\", weight: 0.05,\n        causes: [\"Operator Error\", \"Supplier Material Defect\", \"Process Deviation\"],\n        causeWeights: [0.45, 0.30, 0.25],\n        stageWeights: [0.10, 0.30, 0.55, 0.05]\n    },\n    {\n        name: \"Transport Damage\", category: \"Logistics\", station: \"Final Assembly\", weight: 0.04,\n        causes: [\"Process Deviation\", \"Operator Error\", \"Environmental Factor\"],\n        causeWeights: [0.50, 0.30, 0.20],\n        stageWeights: [0.05, 0.15, 0.50, 0.30] // often only found at dealer/yard, not on-line\n    },\n    {\n        // EV-EXCLUSIVE: only EV Trim vehicles physically have a high-voltage\n        // battery/charging system, so this defect type is deterministically\n        // forced to EV Trim in generateOneDefect() below — not just skewed\n        // toward it. Rare fleet-wide, but gives the \"EV teething defects\"\n        // story an actual distinct failure mode instead of just a higher\n        // rate of the same generic defects.\n        name: \"HV Battery/Charging Fault\", category: \"Electrical\", station: \"Chassis & Powertrain\", weight: 0.02,\n        causes: [\"Supplier Material Defect\", \"Process Deviation\", \"Calibration Drift\"],\n        causeWeights: [0.45, 0.30, 0.25],\n        stageWeights: [0.20, 0.30, 0.35, 0.15]\n    }\n];\nconst DEFECT_TYPE_WEIGHTS = DEFECT_TYPES.map(d => d.weight);\n\nconst STATIONS = [\"Body Shop\", \"Paint Shop\", \"Chassis & Powertrain\", \"Trim\", \"Final Assembly\"];\n\n// ---- Severity: most defects are Minor ----------------------------\nconst SEVERITIES = [\"Critical\", \"Major\", \"Minor\"];\nconst SEVERITY_WEIGHTS = [0.15, 0.35, 0.50];\n\n// ---- Detected stage: driven per-defect-type (see stageWeights above)\nconst STAGES = [\"Incoming\", \"In-Process\", \"Final QC\", \"Field Return\"];\n\n// ---- Disposition: correlated with severity, not independent -----\nconst DISPOSITION_BY_SEVERITY = {\n    Critical: { items: [\"Scrap\", \"Rework\", \"Use-as-is\"], weights: [0.60, 0.35, 0.05] },\n    Major: { items: [\"Scrap\", \"Rework\", \"Use-as-is\"], weights: [0.25, 0.55, 0.20] },\n    Minor: { items: [\"Scrap\", \"Rework\", \"Use-as-is\"], weights: [0.05, 0.35, 0.60] }\n};\n\n// ---- Cost: driven primarily by DISPOSITION, not just severity —\n// Scrap means full material loss, Rework is labor-only, Use-as-is is\n// near-zero (paperwork/inspection). Severity still scales the range\n// within each disposition.\nconst COST_RANGES = {\n    Scrap: { Critical: [800, 2000], Major: [400, 1000], Minor: [150, 400] },\n    Rework: { Critical: [300, 800], Major: [150, 500], Minor: [50, 200] },\n    \"Use-as-is\": { Critical: [50, 150], Major: [20, 80], Minor: [5, 40] }\n};\n\n// ---- Delay likelihood: tied to ROOT CAUSE, not a flat rate — a\n// supplier reorder (Supplier Material Defect) or an infrastructure\n// fix (Environmental Factor) realistically takes far longer to close\n// out than an operator simply redoing the work.\nconst DELAY_PROB_BY_CAUSE = {\n    \"Robot/Tooling Wear\": 0.12,\n    \"Operator Error\": 0.05,\n    \"Calibration Drift\": 0.08,\n    \"Process Deviation\": 0.07,\n    \"Supplier Material Defect\": 0.30,\n    \"Environmental Factor\": 0.15\n};\n\n// ---- Status: correlated with how OLD the defect is --------------\nfunction pickStatusForAge(ageDays) {\n    if (ageDays > 90) {\n        return weightedPick(\n            [\"Verified\", \"Resolved\", \"Corrective Action\"],\n            [0.85, 0.10, 0.05]\n        );\n    } else if (ageDays > 30) {\n        return weightedPick(\n            [\"Verified\", \"Resolved\", \"Corrective Action\", \"RCA\", \"Detected\"],\n            [0.50, 0.25, 0.15, 0.07, 0.03]\n        );\n    } else if (ageDays > 7) {\n        return weightedPick(\n            [\"Corrective Action\", \"RCA\", \"Resolved\", \"Detected\", \"Verified\"],\n            [0.35, 0.30, 0.20, 0.10, 0.05]\n        );\n    } else {\n        return weightedPick(\n            [\"Detected\", \"RCA\", \"Corrective Action\", \"Resolved\"],\n            [0.50, 0.30, 0.15, 0.05]\n        );\n    }\n}\n\n// ---- Day-of-week + \"bad batch\" seasonal bump ---------------------\nfunction dayOfWeekMultiplier(date) {\n    const day = date.getDay();\n    if (day === 1) return 1.3;\n    if (day === 0 || day === 6) return 1.15;\n    return 1.0;\n}\nconst BAD_BATCH_AGE_MIN = 95;\nconst BAD_BATCH_AGE_MAX = 110;\n\n// ---- Core generator: builds ONE defect record --------------------\nfunction generateOneDefect(forcedDate, ageDays) {\n    if (ageDays === undefined || ageDays === null) ageDays = 0;\n\n    let defectTypeObj;\n    if (ageDays >= BAD_BATCH_AGE_MIN && ageDays <= BAD_BATCH_AGE_MAX && Math.random() < 0.45) {\n        // Simulated bad batch of primer/paint material from a supplier\n        defectTypeObj = DEFECT_TYPES.find(d => d.name === \"Paint Contamination\");\n    } else {\n        defectTypeObj = weightedPick(DEFECT_TYPES, DEFECT_TYPE_WEIGHTS);\n    }\n\n    const station = Math.random() < 0.8\n        ? defectTypeObj.station\n        : STATIONS[Math.floor(Math.random() * STATIONS.length)];\n\n    const rootCause = weightedPick(defectTypeObj.causes, defectTypeObj.causeWeights);\n    const severity = weightedPick(SEVERITIES, SEVERITY_WEIGHTS);\n\n    const dispoTable = DISPOSITION_BY_SEVERITY[severity];\n    const disposition = weightedPick(dispoTable.items, dispoTable.weights);\n\n    const status = pickStatusForAge(ageDays);\n\n    // Detected stage comes from THIS defect type's own distribution\n    // (e.g. Paint Contamination is caught early via incoming material\n    // inspection; Transport Damage is often only found at the dealer)\n    const stage = weightedPick(STAGES, defectTypeObj.stageWeights);\n    const stageCostMultiplier = stage === \"Field Return\" ? 2.2 : 1.0;\n\n    // Cost driven by disposition + severity (see COST_RANGES above),\n    // not just severity alone — a Scrapped part costs far more than\n    // a Use-as-is one, even at the same severity.\n    const [costMin, costMax] = COST_RANGES[disposition][severity];\n    const cost = (costMin + Math.random() * (costMax - costMin)) * stageCostMultiplier;\n\n    const resolutionHoursBase = severity === \"Critical\" ? 2 + Math.random() * 10\n        : severity === \"Major\" ? 6 + Math.random() * 24\n            : 12 + Math.random() * 48;\n\n    // Delay probability comes from the ROOT CAUSE (see\n    // DELAY_PROB_BY_CAUSE above) instead of a flat rate for everyone —\n    // e.g. waiting on a supplier reorder takes far longer than an\n    // operator simply redoing the work.\n    const delayProb = DELAY_PROB_BY_CAUSE[rootCause] ?? 0.10;\n    const isDelayed = Math.random() < delayProb;\n    const resolutionHours = isDelayed\n        ? resolutionHoursBase * (3 + Math.random() * 3)\n        : resolutionHoursBase;\n\n    // Trim/SKU: HV Battery/Charging Fault is EV-EXCLUSIVE — only EV Trim\n    // vehicles physically have a high-voltage battery/charging system,\n    // so this is deterministic, not just weighted probability.\n    const sku = defectTypeObj.name === \"HV Battery/Charging Fault\"\n        ? \"EV Trim\"\n        : weightedPick(SKUS, SKU_WEIGHTS);\n\n    return {\n        defect_id: nextDefectId(),\n        date: forcedDate,\n        line: weightedPick(LINES, LINE_WEIGHTS),\n        station: station,\n        shift: weightedPick(SHIFTS, SHIFT_WEIGHTS),\n        sku: sku,\n        defect_type: defectTypeObj.name,\n        defect_category: defectTypeObj.category,\n        severity: severity,\n        detected_stage: stage,\n        root_cause: rootCause,\n        disposition: disposition,\n        status: status,\n        cost_impact: Math.round(cost * 100) / 100,\n        resolution_hours: Math.round(resolutionHours * 10) / 10\n    };\n}\n\n// ============================================================\n// FUNCTION NODE 1: HISTORICAL SEED (v2 — realistic correlations)\n// Wire: [Inject: manual]\n//        -> [THIS Function node]\n//        -> [postgresql/FlowFuse Tables node: bulk UNNEST INSERT]\n// ============================================================\n\nconst DAYS_BACK = 180;          // ~6 months of history\nconst RECORDS_PER_DAY_AVG = 7;  // baseline volume (~1260 records before multipliers)\n\nconst records = [];\nconst today = new Date();\n\nfor (let ageDays = DAYS_BACK; ageDays >= 0; ageDays--) {\n    const day = new Date(today);\n    day.setDate(day.getDate() - ageDays);\n    const dateStr = day.toISOString().slice(0, 10);\n\n    const dowMultiplier = dayOfWeekMultiplier(day);\n    const countToday = Math.max(0, Math.round(\n        (RECORDS_PER_DAY_AVG + (Math.random() - 0.5) * 4) * dowMultiplier\n    ));\n\n    for (let i = 0; i < countToday; i++) {\n        records.push(generateOneDefect(dateStr, ageDays));\n    }\n}\n\nnode.log(`Generated ${records.length} historical defect records (with realistic skew).`);\n\nmsg.params = recordsToColumnParams(records); // FlowFuse Tables node reads params from msg.params\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":340,"y":260,"wires":[["d2facb93da0e58db"]]},{"id":"23504c3b0f35db82","type":"inject","z":"7f9feb3283fbb929","g":"fc4cfab8a41f3bdb","name":"","props":[],"repeat":"5","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":130,"y":320,"wires":[["475645219af52b5e"]]},{"id":"475645219af52b5e","type":"function","z":"7f9feb3283fbb929","g":"fc4cfab8a41f3bdb","name":"Live Feed","func":"// ============================================================\n// SHARED GENERATOR LOGIC (v4 — full station coverage + EV-specific defect)\n// ============================================================\n\n// ---- Helper: weighted random pick ------------------------------\nfunction weightedPick(items, weights) {\n    const r = Math.random();\n    let cumulative = 0;\n    for (let i = 0; i < items.length; i++) {\n        cumulative += weights[i];\n        if (r <= cumulative) return items[i];\n    }\n    return items[items.length - 1];\n}\n\n// ---- Convert a record object into the flat params array Postgres\n// node needs, in the exact column order of the INSERT query ------\nfunction recordToParams(r) {\n    return [\n        r.defect_id, r.date, r.line, r.station, r.shift, r.sku,\n        r.defect_type, r.defect_category, r.severity, r.detected_stage,\n        r.root_cause, r.disposition, r.status, r.cost_impact, r.resolution_hours\n    ];\n}\n\n\n// ---- Unique defect_id (no context store needed) ----------------\nfunction nextDefectId() {\n    const rand = Math.floor(Math.random() * 46656).toString(36).padStart(3, \"0\");\n    return \"DEF-\" + Date.now().toString(36).toUpperCase() + \"-\" + rand.toUpperCase();\n}\n\n// ---- Assembly lines: NOT equal — SUV Line has an aging robot cell\nconst LINES         = [\"Sedan Line\", \"SUV Line\", \"EV Line\"];\nconst LINE_WEIGHTS   = [0.30,          0.45,       0.25];   // SUV Line skewed higher\n\n// ---- Shifts: Night skewed higher (fatigue/less supervision) -----\nconst SHIFTS         = [\"Morning\", \"Evening\", \"Night\"];\nconst SHIFT_WEIGHTS  = [0.30,       0.25,      0.45];\n\n// ---- Trims: EV is the newest variant, has early teething defects --\nconst SKUS           = [\"Base Trim\", \"Sport Trim\", \"Premium Trim\", \"EV Trim\"];\nconst SKU_WEIGHTS    = [0.20,          0.20,          0.25,           0.35]; // EV = newest, higher defect rate\n\n// ---- Defect types: Pareto-shaped (80/20 rule), each with a home\n// shop, plausible root causes, and where it typically gets caught.\n// Now covers ALL 5 stations (Chassis & Powertrain and Trim were\n// previously listed as stations but had zero defect types assigned).\nconst DEFECT_TYPES = [\n    {\n        name: \"Weld Crack\", category: \"Body/Weld\", station: \"Body Shop\", weight: 0.24,\n        causes: [\"Robot/Tooling Wear\", \"Operator Error\", \"Calibration Drift\", \"Process Deviation\"],\n        causeWeights: [0.40, 0.30, 0.20, 0.10],\n        stageWeights: [0.05, 0.35, 0.50, 0.10]\n    },\n    {\n        name: \"Paint Defect\", category: \"Paint/Surface\", station: \"Paint Shop\", weight: 0.19,\n        causes: [\"Operator Error\", \"Process Deviation\", \"Environmental Factor\", \"Robot/Tooling Wear\"],\n        causeWeights: [0.35, 0.30, 0.20, 0.15],\n        stageWeights: [0.05, 0.25, 0.55, 0.15]\n    },\n    {\n        name: \"Panel Gap Deviation\", category: \"Dimensional\", station: \"Body Shop\", weight: 0.13,\n        causes: [\"Calibration Drift\", \"Robot/Tooling Wear\", \"Process Deviation\", \"Supplier Material Defect\"],\n        causeWeights: [0.40, 0.30, 0.20, 0.10],\n        stageWeights: [0.25, 0.45, 0.28, 0.02]\n    },\n    {\n        name: \"Door Misalignment\", category: \"Assembly\", station: \"Final Assembly\", weight: 0.10,\n        causes: [\"Operator Error\", \"Process Deviation\", \"Robot/Tooling Wear\"],\n        causeWeights: [0.35, 0.35, 0.30],\n        stageWeights: [0.05, 0.35, 0.55, 0.05]\n    },\n    {\n        name: \"Paint Contamination\", category: \"Material\", station: \"Paint Shop\", weight: 0.09,\n        causes: [\"Supplier Material Defect\", \"Environmental Factor\", \"Process Deviation\"],\n        causeWeights: [0.50, 0.30, 0.20],\n        stageWeights: [0.40, 0.35, 0.20, 0.05]\n    },\n    {\n        name: \"Fluid Leak\", category: \"Powertrain\", station: \"Chassis & Powertrain\", weight: 0.08,\n        causes: [\"Robot/Tooling Wear\", \"Process Deviation\", \"Supplier Material Defect\"],\n        causeWeights: [0.40, 0.35, 0.25],\n        stageWeights: [0.10, 0.40, 0.40, 0.10]\n    },\n    {\n        name: \"Missing Fastener\", category: \"Assembly\", station: \"Final Assembly\", weight: 0.06,\n        causes: [\"Operator Error\", \"Process Deviation\"],\n        causeWeights: [0.60, 0.40],\n        stageWeights: [0.05, 0.30, 0.60, 0.05]\n    },\n    {\n        name: \"Interior Trim Defect\", category: \"Trim\", station: \"Trim\", weight: 0.05,\n        causes: [\"Operator Error\", \"Supplier Material Defect\", \"Process Deviation\"],\n        causeWeights: [0.45, 0.30, 0.25],\n        stageWeights: [0.10, 0.30, 0.55, 0.05]\n    },\n    {\n        name: \"Transport Damage\", category: \"Logistics\", station: \"Final Assembly\", weight: 0.04,\n        causes: [\"Process Deviation\", \"Operator Error\", \"Environmental Factor\"],\n        causeWeights: [0.50, 0.30, 0.20],\n        stageWeights: [0.05, 0.15, 0.50, 0.30] // often only found at dealer/yard, not on-line\n    },\n    {\n        // EV-EXCLUSIVE: only EV Trim vehicles physically have a high-voltage\n        // battery/charging system, so this defect type is deterministically\n        // forced to EV Trim in generateOneDefect() below — not just skewed\n        // toward it. Rare fleet-wide, but gives the \"EV teething defects\"\n        // story an actual distinct failure mode instead of just a higher\n        // rate of the same generic defects.\n        name: \"HV Battery/Charging Fault\", category: \"Electrical\", station: \"Chassis & Powertrain\", weight: 0.02,\n        causes: [\"Supplier Material Defect\", \"Process Deviation\", \"Calibration Drift\"],\n        causeWeights: [0.45, 0.30, 0.25],\n        stageWeights: [0.20, 0.30, 0.35, 0.15]\n    }\n];\nconst DEFECT_TYPE_WEIGHTS = DEFECT_TYPES.map(d => d.weight);\n\nconst STATIONS = [\"Body Shop\", \"Paint Shop\", \"Chassis & Powertrain\", \"Trim\", \"Final Assembly\"];\n\n// ---- Severity: most defects are Minor ----------------------------\nconst SEVERITIES      = [\"Critical\", \"Major\", \"Minor\"];\nconst SEVERITY_WEIGHTS = [0.15, 0.35, 0.50];\n\n// ---- Detected stage: driven per-defect-type (see stageWeights above)\nconst STAGES = [\"Incoming\", \"In-Process\", \"Final QC\", \"Field Return\"];\n\n// ---- Disposition: correlated with severity, not independent -----\nconst DISPOSITION_BY_SEVERITY = {\n    Critical: { items: [\"Scrap\", \"Rework\", \"Use-as-is\"], weights: [0.60, 0.35, 0.05] },\n    Major:    { items: [\"Scrap\", \"Rework\", \"Use-as-is\"], weights: [0.25, 0.55, 0.20] },\n    Minor:    { items: [\"Scrap\", \"Rework\", \"Use-as-is\"], weights: [0.05, 0.35, 0.60] }\n};\n\n// ---- Cost: driven primarily by DISPOSITION, not just severity —\n// Scrap means full material loss, Rework is labor-only, Use-as-is is\n// near-zero (paperwork/inspection). Severity still scales the range\n// within each disposition.\nconst COST_RANGES = {\n    Scrap:        { Critical: [800, 2000], Major: [400, 1000], Minor: [150, 400] },\n    Rework:       { Critical: [300, 800],  Major: [150, 500],  Minor: [50, 200] },\n    \"Use-as-is\":  { Critical: [50, 150],   Major: [20, 80],    Minor: [5, 40] }\n};\n\n// ---- Delay likelihood: tied to ROOT CAUSE, not a flat rate — a\n// supplier reorder (Supplier Material Defect) or an infrastructure\n// fix (Environmental Factor) realistically takes far longer to close\n// out than an operator simply redoing the work.\nconst DELAY_PROB_BY_CAUSE = {\n    \"Robot/Tooling Wear\": 0.12,\n    \"Operator Error\": 0.05,\n    \"Calibration Drift\": 0.08,\n    \"Process Deviation\": 0.07,\n    \"Supplier Material Defect\": 0.30,\n    \"Environmental Factor\": 0.15\n};\n\n// ---- Status: correlated with how OLD the defect is --------------\nfunction pickStatusForAge(ageDays) {\n    if (ageDays > 90) {\n        return weightedPick(\n            [\"Verified\", \"Resolved\", \"Corrective Action\"],\n            [0.85, 0.10, 0.05]\n        );\n    } else if (ageDays > 30) {\n        return weightedPick(\n            [\"Verified\", \"Resolved\", \"Corrective Action\", \"RCA\", \"Detected\"],\n            [0.50, 0.25, 0.15, 0.07, 0.03]\n        );\n    } else if (ageDays > 7) {\n        return weightedPick(\n            [\"Corrective Action\", \"RCA\", \"Resolved\", \"Detected\", \"Verified\"],\n            [0.35, 0.30, 0.20, 0.10, 0.05]\n        );\n    } else {\n        return weightedPick(\n            [\"Detected\", \"RCA\", \"Corrective Action\", \"Resolved\"],\n            [0.50, 0.30, 0.15, 0.05]\n        );\n    }\n}\n\n// ---- Day-of-week + \"bad batch\" seasonal bump ---------------------\nfunction dayOfWeekMultiplier(date) {\n    const day = date.getDay();\n    if (day === 1) return 1.3;\n    if (day === 0 || day === 6) return 1.15;\n    return 1.0;\n}\nconst BAD_BATCH_AGE_MIN = 95;\nconst BAD_BATCH_AGE_MAX = 110;\n\n// ---- Core generator: builds ONE defect record --------------------\nfunction generateOneDefect(forcedDate, ageDays) {\n    if (ageDays === undefined || ageDays === null) ageDays = 0;\n\n    let defectTypeObj;\n    if (ageDays >= BAD_BATCH_AGE_MIN && ageDays <= BAD_BATCH_AGE_MAX && Math.random() < 0.45) {\n        // Simulated bad batch of primer/paint material from a supplier\n        defectTypeObj = DEFECT_TYPES.find(d => d.name === \"Paint Contamination\");\n    } else {\n        defectTypeObj = weightedPick(DEFECT_TYPES, DEFECT_TYPE_WEIGHTS);\n    }\n\n    const station = Math.random() < 0.8\n        ? defectTypeObj.station\n        : STATIONS[Math.floor(Math.random() * STATIONS.length)];\n\n    const rootCause = weightedPick(defectTypeObj.causes, defectTypeObj.causeWeights);\n    const severity = weightedPick(SEVERITIES, SEVERITY_WEIGHTS);\n\n    const dispoTable = DISPOSITION_BY_SEVERITY[severity];\n    const disposition = weightedPick(dispoTable.items, dispoTable.weights);\n\n    const status = pickStatusForAge(ageDays);\n\n    // Detected stage comes from THIS defect type's own distribution\n    // (e.g. Paint Contamination is caught early via incoming material\n    // inspection; Transport Damage is often only found at the dealer)\n    const stage = weightedPick(STAGES, defectTypeObj.stageWeights);\n    const stageCostMultiplier = stage === \"Field Return\" ? 2.2 : 1.0;\n\n    // Cost driven by disposition + severity (see COST_RANGES above),\n    // not just severity alone — a Scrapped part costs far more than\n    // a Use-as-is one, even at the same severity.\n    const [costMin, costMax] = COST_RANGES[disposition][severity];\n    const cost = (costMin + Math.random() * (costMax - costMin)) * stageCostMultiplier;\n\n    const resolutionHoursBase = severity === \"Critical\" ? 2 + Math.random() * 10\n                              : severity === \"Major\"    ? 6 + Math.random() * 24\n                              :                            12 + Math.random() * 48;\n\n    // Delay probability comes from the ROOT CAUSE (see\n    // DELAY_PROB_BY_CAUSE above) instead of a flat rate for everyone —\n    // e.g. waiting on a supplier reorder takes far longer than an\n    // operator simply redoing the work.\n    const delayProb = DELAY_PROB_BY_CAUSE[rootCause] ?? 0.10;\n    const isDelayed = Math.random() < delayProb;\n    const resolutionHours = isDelayed\n        ? resolutionHoursBase * (3 + Math.random() * 3)\n        : resolutionHoursBase;\n\n    // Trim/SKU: HV Battery/Charging Fault is EV-EXCLUSIVE — only EV Trim\n    // vehicles physically have a high-voltage battery/charging system,\n    // so this is deterministic, not just weighted probability.\n    const sku = defectTypeObj.name === \"HV Battery/Charging Fault\"\n        ? \"EV Trim\"\n        : weightedPick(SKUS, SKU_WEIGHTS);\n\n    return {\n        defect_id: nextDefectId(),\n        date: forcedDate,\n        line: weightedPick(LINES, LINE_WEIGHTS),\n        station: station,\n        shift: weightedPick(SHIFTS, SHIFT_WEIGHTS),\n        sku: sku,\n        defect_type: defectTypeObj.name,\n        defect_category: defectTypeObj.category,\n        severity: severity,\n        detected_stage: stage,\n        root_cause: rootCause,\n        disposition: disposition,\n        status: status,\n        cost_impact: Math.round(cost * 100) / 100,\n        resolution_hours: Math.round(resolutionHours * 10) / 10\n    };\n}\n\n// ============================================================\n// FUNCTION NODE 2: LIVE FEED (v2 — realistic correlations)\n// Wire: [Inject: repeat every 20s]\n//        -> [THIS Function node]\n//        -> [postgresql/FlowFuse Tables node: single row INSERT]\n//        -> (optional) [Switch: msg.critical === true] -> [ui_notification]\n// ============================================================\n\nconst todayStr = new Date().toISOString().slice(0, 10);\nconst record = generateOneDefect(todayStr, 0); // ageDays=0: fresh, mostly \"Detected\"\n\nmsg.critical = (record.severity === \"Critical\");\nmsg.params = recordToParams(record); // FlowFuse Tables node reads params from msg.params\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":320,"y":320,"wires":[["1188c4b2256949a3"]]},{"id":"d978f663921063a7","type":"debug","z":"7f9feb3283fbb929","g":"fc4cfab8a41f3bdb","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":320,"wires":[]},{"id":"d2facb93da0e58db","type":"tables-query","z":"7f9feb3283fbb929","g":"fc4cfab8a41f3bdb","name":"Insert Historical Records","query":"-- BULK INSERT for historical seed (single query, no Split node needed)\n-- Use this in the postgresql node wired directly after the\n-- \"historical seed\" Function node.\n--\n-- msg.payload must be an array of 15 arrays (column-wise), which is\n-- exactly what recordsToColumnParams() in function-shared-logic.js\n-- produces: [ [all defect_ids], [all dates], [all lines], ... ]\n\nINSERT INTO defects (\n    defect_id, date, line, station, shift, sku,\n    defect_type, defect_category, severity, detected_stage,\n    root_cause, disposition, status, cost_impact, resolution_hours\n)\nSELECT * FROM UNNEST(\n    $1::varchar[],  $2::date[],     $3::varchar[],  $4::varchar[],\n    $5::varchar[],  $6::varchar[],  $7::varchar[],  $8::varchar[],\n    $9::varchar[],  $10::varchar[], $11::varchar[], $12::varchar[],\n    $13::varchar[], $14::numeric[], $15::numeric[]\n)\nON CONFLICT (defect_id) DO NOTHING;\n\n-- ------------------------------------------------------------\n-- LIVE FEED still uses the simple single-row query below,\n-- unchanged, fed by function-live-feed.js (one param-array per msg):\n--\n-- INSERT INTO defects (\n--     defect_id, date, line, station, shift, sku,\n--     defect_type, defect_category, severity, detected_stage,\n--     root_cause, disposition, status, cost_impact, resolution_hours\n-- )\n-- VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15)\n-- ON CONFLICT (defect_id) DO NOTHING;","split":false,"rowsPerMsg":1,"x":570,"y":260,"wires":[["7ff2fe3d22e543d8"]]},{"id":"1188c4b2256949a3","type":"tables-query","z":"7f9feb3283fbb929","g":"fc4cfab8a41f3bdb","name":"Insert Live Record","query":"INSERT INTO defects (\n    defect_id, date, line, station, shift, sku,\n    defect_type, defect_category, severity, detected_stage,\n    root_cause, disposition, status, cost_impact, resolution_hours\n)\nVALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15)\nON CONFLICT (defect_id) DO NOTHING;","split":false,"rowsPerMsg":1,"x":550,"y":320,"wires":[["d978f663921063a7"]]},{"id":"d1c5372e4c488212","type":"group","z":"7f9feb3283fbb929","name":"Create Defect Table","style":{"label":true},"nodes":["f4a14ba58c9e129d","a08e0258f5c5242e","83e51297506816b4"],"x":34,"y":19,"w":812,"h":82},{"id":"f4a14ba58c9e129d","type":"inject","z":"7f9feb3283fbb929","g":"d1c5372e4c488212","name":"","props":[],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":130,"y":60,"wires":[["a08e0258f5c5242e"]]},{"id":"a08e0258f5c5242e","type":"tables-query","z":"7f9feb3283fbb929","g":"d1c5372e4c488212","name":"Create Defect Table","query":"CREATE TABLE IF NOT EXISTS defects (\n    defect_id         VARCHAR(20) PRIMARY KEY,\n    date              DATE NOT NULL,\n    line              VARCHAR(20),\n    station           VARCHAR(30),\n    shift             VARCHAR(20),\n    sku               VARCHAR(20),\n    defect_type       VARCHAR(50),\n    defect_category   VARCHAR(30),\n    severity          VARCHAR(10),\n    detected_stage    VARCHAR(20),\n    root_cause        VARCHAR(50),\n    disposition       VARCHAR(20),\n    status            VARCHAR(20),\n    cost_impact       NUMERIC(10,2),\n    resolution_hours  NUMERIC(6,1)\n);\n\nCREATE INDEX IF NOT EXISTS idx_defects_date ON defects(date);\nCREATE INDEX IF NOT EXISTS idx_defects_line ON defects(line);\nCREATE INDEX IF NOT EXISTS idx_defects_shift ON defects(shift);","split":false,"rowsPerMsg":1,"x":350,"y":60,"wires":[["83e51297506816b4"]]},{"id":"83e51297506816b4","type":"debug","z":"7f9feb3283fbb929","g":"d1c5372e4c488212","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":60,"wires":[]},{"id":"78a99932f3724e3e","type":"group","z":"7f9feb3283fbb929","name":"Delete All Records","style":{"label":true},"nodes":["1c3ce2ba4a766cee","e38d9a6684c6b3bb","c0c78694aa023826"],"x":34,"y":119,"w":812,"h":82},{"id":"1c3ce2ba4a766cee","type":"inject","z":"7f9feb3283fbb929","d":true,"g":"78a99932f3724e3e","name":"","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":130,"y":160,"wires":[["e38d9a6684c6b3bb"]]},{"id":"e38d9a6684c6b3bb","type":"tables-query","z":"7f9feb3283fbb929","g":"78a99932f3724e3e","name":"Delete All Records","query":"DELETE FROM defects;","split":false,"rowsPerMsg":1,"x":350,"y":160,"wires":[["c0c78694aa023826"]]},{"id":"c0c78694aa023826","type":"debug","z":"7f9feb3283fbb929","g":"78a99932f3724e3e","name":"Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":750,"y":160,"wires":[]},{"id":"d7a304ca96634e82","type":"global-config","env":[],"modules":{"@flowfuse/nr-tables-nodes":"0.2.2"}}]
```
::

Both run automatically on deploy: no buttons to click. The table is created first, the historical seed lands a few seconds later, and the live feed takes over from there. Within moments your table holds over a thousand records and keeps growing.

### The schema it creates

You don't run this yourself; the import handles it. But it's the contract the whole dashboard depends on, so it's worth knowing what the `defects` table looks like, especially if you later point the dashboard at your own database:

```sql
CREATE TABLE IF NOT EXISTS defects (
    defect_id         VARCHAR(20) PRIMARY KEY,
    date              DATE NOT NULL,
    line              VARCHAR(20),
    station           VARCHAR(30),
    shift             VARCHAR(20),
    sku               VARCHAR(20),
    defect_type       VARCHAR(50),
    defect_category   VARCHAR(30),
    severity          VARCHAR(10),
    detected_stage    VARCHAR(20),
    root_cause        VARCHAR(50),
    disposition       VARCHAR(20),
    status            VARCHAR(20),
    cost_impact       NUMERIC(10,2),
    resolution_hours  NUMERIC(6,1)
);

CREATE INDEX IF NOT EXISTS idx_defects_date ON defects(date);
CREATE INDEX IF NOT EXISTS idx_defects_line ON defects(line);
CREATE INDEX IF NOT EXISTS idx_defects_shift ON defects(shift);
```

Each row is one defect. The columns group into where it happened (`line`, `station`, `shift`, `sku`), what it was (`defect_type`, `severity`, `detected_stage`), how it was handled (`root_cause`, `disposition`, `status`), and what it cost (`cost_impact`, `resolution_hours`). The three indexes cover the columns the dashboard filters by, so queries stay fast as the table grows.

## Building the Query

Running one query per widget means a dozen database trips on every refresh. This dashboard runs a single query instead. It returns one row where each field holds one widget's data, and every widget reads just its own field.

Two CTEs at the top do the filtering. `filtered_all` applies all three filters: line, shift, and date range. `filtered_line_and_shift` skips the date filter, so the live ticker always shows the latest defects. After that, one `json_agg` block builds the data for each widget:

> Tip: You don't have to write SQL yourself. Use [FlowFuse Expert](https://flowfuse.com/blog/2025/09/ai-assistant-flowfuse-tables/) and describe the interface in plain English. It will generate the ui-template code for you.

```sql
WITH
  filtered_all AS ( -- full 3-filter set, used by almost every widget
    SELECT * FROM defects
    WHERE ($line = 'All' OR line = $line)
      AND ($shift = 'All' OR shift = $shift)
      AND date >= CURRENT_DATE - ($daysback || ' days')::interval
  ),
  filtered_line_and_shift AS ( -- ticker: "right now" view, ignores the date filter
    SELECT * FROM defects
    WHERE ($line = 'All' OR line = $line) AND ($shift = 'All' OR shift = $shift)
  )
SELECT
  -- stat cards + cost of poor quality (one pass over the filtered rows)
  (SELECT json_agg(t) FROM (
    SELECT
      COUNT(*) FILTER (WHERE status IN ('Resolved','Verified'))     AS closed_count,
      COUNT(*) FILTER (WHERE status NOT IN ('Resolved','Verified')) AS open_count,
      COUNT(*)                    AS total_count,
      ROUND(SUM(cost_impact), 2)  AS total_copq
    FROM filtered_all
  ) t) AS stat_cards_and_copq,

  -- average resolution time + SLA breach per severity
  -- (SLA targets: Critical 24h, Major 72h, Minor 168h)
  (SELECT json_agg(t) FROM (
    SELECT severity,
      ROUND(AVG(resolution_hours), 1) AS avg_resolution_hours,
      COUNT(*)                        AS resolved_count,
      COUNT(*) FILTER (WHERE resolution_hours >
        CASE severity WHEN 'Critical' THEN 24 WHEN 'Major' THEN 72 ELSE 168 END) AS sla_breached_count,
      ROUND(100.0 * COUNT(*) FILTER (WHERE resolution_hours >
        CASE severity WHEN 'Critical' THEN 24 WHEN 'Major' THEN 72 ELSE 168 END)
        / NULLIF(COUNT(*), 0), 1) AS sla_breach_pct
    FROM filtered_all WHERE status IN ('Resolved', 'Verified')
    GROUP BY severity
    ORDER BY CASE severity WHEN 'Critical' THEN 1 WHEN 'Major' THEN 2 ELSE 3 END
  ) t) AS avg_resolution_and_sla,

  -- Pareto: defect-type counts with a cumulative % (window functions)
  (SELECT json_agg(t) FROM (
    SELECT defect_type, COUNT(*) AS defect_count,
      ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 1) AS pct_of_total,
      ROUND(SUM(COUNT(*)) OVER (ORDER BY COUNT(*) DESC) * 100.0
            / SUM(COUNT(*)) OVER (), 1) AS cumulative_pct
    FROM filtered_all GROUP BY defect_type ORDER BY defect_count DESC
  ) t) AS pareto,

  -- daily trend
  (SELECT json_agg(t) FROM (
    SELECT date, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY date ORDER BY date
  ) t) AS trend,

  -- disposition breakdown
  (SELECT json_agg(t) FROM (
    SELECT disposition, COUNT(*) AS defect_count, ROUND(SUM(cost_impact), 2) AS total_cost
    FROM filtered_all GROUP BY disposition ORDER BY defect_count DESC
  ) t) AS disposition,

  -- severity breakdown
  (SELECT json_agg(t) FROM (
    SELECT severity, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY severity
    ORDER BY CASE severity WHEN 'Critical' THEN 1 WHEN 'Major' THEN 2 ELSE 3 END
  ) t) AS severity,

  -- root-cause breakdown
  (SELECT json_agg(t) FROM (
    SELECT root_cause, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY root_cause ORDER BY defect_count DESC
  ) t) AS root_cause,

  -- status funnel, ordered by workflow stage
  (SELECT json_agg(t) FROM (
    SELECT status, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY status
    ORDER BY CASE status WHEN 'Detected' THEN 1 WHEN 'RCA' THEN 2 WHEN 'Corrective Action' THEN 3
      WHEN 'Resolved' THEN 4 WHEN 'Verified' THEN 5 END
  ) t) AS status_funnel,

  -- most recent 20 defects, for the live ticker
  (SELECT json_agg(t) FROM (
    SELECT defect_id, date, line, station, defect_type, severity, status, cost_impact
    FROM filtered_line_and_shift ORDER BY defect_id DESC LIMIT 20
  ) t) AS ticker;
```

With the query written, wire it up so it runs on a timer and its result reaches every widget.

1. Add a change node before the Query node and name it "Set Params". This maps the saved filters onto the `$line`, `$shift`, and `$daysback` parameters the SQL reads. Set four rules, in order:
   - Set `queryParameters` to `{}` (JSON): starts clean so stale values don't linger.
   - Set `queryParameters.line` to `filters.line` (global persistent).
   - Set `queryParameters.shift` to `filters.shift` (global persistent).
   - Set `queryParameters.daysback` to `filters.dateRange` (global persistent).

![Screenshot: Set Params change node with its four rules](https://flowfuse.com/blog/2026/07/images/set-params-change-node.png)&#x2A;The "Set Params" change node open in the edit panel, all four rules visible.*

1. Add an inject node named "Poll Data" and set it to repeat every 10 to 30 seconds. Wire it into "Set Params"; this re-runs the query on a timer so the dashboard keeps up as new defects arrive. Also add a link in node here, named "Refresh Trigger," and connect it to the "Set Params" change node; this will let the filter flow you build next trigger a refresh as well.
2. After the Query node, add a single link out node and name it "KPI Result". Each widget you build next will connect a link in node to it, so the one result broadcasts to every widget at once.

## Adding the Filters

The filters go in the dashboard header rather than a widget group, since they control the whole page, not one chart. Each selection saves to the global `filters` object that "Set Params" reads before every query run.

1. Add a ui-event node. It fires on page load, so a fresh browser session starts with the dropdowns populated.
2. Add a change node named "Set Filters". Set `payload` to one JSON object containing your filter options. For this tutorial it looks like the following, but update it to match your table:

```json
{
    "line": "SUV Line",
    "shift": "Night",
    "dateRange": 30,
    "lineOptions": [
        "All",
        "Sedan Line",
        "SUV Line",
        "EV Line"
    ],
    "shiftOptions": [
        "All",
        "Morning",
        "Evening",
        "Night"
    ],
    "dateRangeOptions": [
        {
            "label": "Last 7 days",
            "value": 7
        },
        {
            "label": "Last 30 days",
            "value": 30
        },
        {
            "label": "Last 90 days",
            "value": 90
        },
        {
            "label": "All time",
            "value": 100000
        }
    ]
}
```

3. Add a ui-template node named "Header Filters". Set its type to "Widget" (UI scoped) and select your UI. Ask [FlowFuse Expert](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/#css-and-html-generation-for-flowfuse-dashboard) to build it:

> Create a ui-template with three header dropdowns, Line, Shift, and Date Range, wrapped in `<Teleport defer to="#app-bar-actions">` so they render in the header bar and survive a reload. msg.payload has the selections (line, shift, dateRange) and options (lineOptions, shiftOptions, dateRangeOptions). Line/Shift options are strings; dateRangeOptions items are {label, value} objects, so bind label as text and value as the value, not the whole object. On any change, and on load, send {line, shift, dateRange} downstream.

Below is the template it produced for us, import it directly if you prefer:

::render-flow{:height='300'}
```json
[{"id":"cb03d95bcad4cbd8","type":"ui-template","z":"b069d8356c10f58e","g":"6a002542e7c91e0e","group":"","page":"","ui":"6481b1c613ec9a93","name":"App Header Filters","order":1,"width":0,"height":0,"head":"","format":"<template>\n    <!-- Filter dropdowns, teleported into the dashboard header -->\n    <Teleport v-if=\"mounted\" to=\"#app-bar-actions\">\n        <div class=\"filter-bar\">\n            <v-select :model-value=\"line\" @update:model-value=\"val => { line = val; onFilterChange(); }\"\n                :items=\"lineOptions\" label=\"Line\" density=\"compact\" variant=\"solo\" hide-details\n                style=\"min-width: 120px\"></v-select>\n\n            <v-select :model-value=\"shift\" @update:model-value=\"val => { shift = val; onFilterChange(); }\"\n                :items=\"shiftOptions\" label=\"Shift\" density=\"compact\" variant=\"solo\" hide-details\n                style=\"min-width: 120px\"></v-select>\n\n            <v-select :model-value=\"dateRange\" @update:model-value=\"val => { dateRange = val; onFilterChange(); }\"\n                :items=\"dateRangeOptions\" item-title=\"label\" item-value=\"value\" label=\"Date Range\" density=\"compact\"\n                variant=\"solo\" hide-details style=\"min-width: 160px\"></v-select>\n        </div>\n    </Teleport>\n</template>\n\n<script>\n    export default {\n    data() {\n        return {\n            mounted: false,\n\n            // Selected values\n            line: 'All',\n            shift: 'All',\n            dateRange: 30,\n\n            // Available options\n            lineOptions: [],\n            shiftOptions: [],\n            dateRangeOptions: []\n        }\n    },\n\n    mounted() {\n        // Wait until the dashboard header exists before teleporting.\n        this.mounted = true;\n    },\n\n    watch: {\n        msg: {\n            immediate: true,\n            deep: true,\n            handler(msg) {\n                if (!msg?.payload) return;\n\n                // Selected values\n                this.line = msg.payload.line ?? this.line;\n                this.shift = msg.payload.shift ?? this.shift;\n                this.dateRange = msg.payload.dateRange ?? this.dateRange;\n\n                // Dropdown options\n                this.lineOptions = msg.payload.lineOptions ?? this.lineOptions;\n                this.shiftOptions = msg.payload.shiftOptions ?? this.shiftOptions;\n                this.dateRangeOptions = msg.payload.dateRangeOptions ?? this.dateRangeOptions;\n\n                // Send initial state downstream\n                this.onFilterChange();\n            }\n        }\n    },\n\n    methods: {\n        onFilterChange() {\n            this.send({\n                payload: {\n                    line: this.line,\n                    shift: this.shift,\n                    dateRange: this.dateRange\n                }\n            });\n        }\n    }\n}\n</script>\n\n<style>\n    .filter-bar {\n        display: flex;\n        gap: 12px;\n        align-items: center;\n        padding-right: 12px;\n    }\n</style>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"widget:ui","className":"","x":450,"y":140,"wires":[["e958c99e3f1ecb94"]]},{"id":"6481b1c613ec9a93","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":false},{"id":"18db5e6eeee7d1d9","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.30.2"}}]
```
::

![Screenshot: the three header dropdowns (Line, Shift, and Date Range) rendered in the dashboard header](https://flowfuse.com/blog/2026/07/images/dashboard-header-filter.png)&#x2A;The finished header filters. Capture the Line, Shift, and Date Range dropdowns in the live dashboard header.*

4. Add a change node named "Save Filters" that sets the persistent global `filters` to `msg.payload`, and connect its input to the "Header Filters" ui-template node.

![The Save Filters change node configured to set the global filters object to msg.payload](https://flowfuse.com/blog/2026/07/images/store-filters.png)&#x2A;The "Save Filters" change node, setting the persistent global `filters` to `msg.payload`.*

5. Next, add a link out node, connect its input to the "Save Filters" change node, and connect its output to the "Refresh Trigger" link in node you added earlier.

Deploy, and the dropdowns appear in the header. Change one and the next query pass redraws every widget against it.

## Building the Widgets

Everything the dashboard shows comes from the "KPI Result" broadcast, so every widget follows the same wiring: a **link in** node connected to "KPI Result", a change node that extracts that widget's field, and the display node.

Before adding widgets, create a page for the dashboard (ours is "Assembly Quality Monitor") and a ui-group for each widget. The group is what positions and sizes a widget on the grid.

### Stat cards

Start with the four numbers a supervisor checks first: total defects, open, closed, and cost of poor quality.

1. Add a link in node and connect it to "KPI Result".
2. Add a change node named "Extract KPI Summary" with one rule: set `msg.payload` to `msg.payload[0].stat_cards_and_copq` (msg). Wire the link in to it.
3. Add four ui-text nodes, one in each of the four top groups (Total Defects, Open, Closed, Cost of Poor Quality). Wire the change node to all four.
4. In each ui-text node, set the value to the matching field: `msg.payload[0].total_count`, `msg.payload[0].open_count`, `msg.payload[0].closed_count`, `msg.payload[0].total_copq`.

Open counts everything not yet Resolved or Verified; the cost figure sums `cost_impact` across the current filter, so it moves the moment you switch line or shift.

![Screenshot: the four stat cards: Total Defects, Open, Closed, and Cost of Poor Quality](https://flowfuse.com/blog/2026/07/images/stat-cards.png)&#x2A;The four stat cards populated with seeded data.*

### Pareto chart

The [Pareto chart](https://flowfuse.com/blog/2025/08/pareto-chart-manufacturing-guide/) ranks defect types by count and overlays a cumulative-percentage line with an 80% marker. It is the fastest way to see which few defect types cause most of the pain. The built-in ui-chart can't combine bars and a line, so this one is a ui-template that draws the SVG itself.

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Pareto Data": set `msg.payload` to `msg.payload[0].pareto` (msg).
3. Add a ui-template node in the Pareto group. Ask [FlowFuse Expert](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/#css-and-html-generation-for-flowfuse-dashboard) to generate it:

> Create a Vue ui-template that renders a Pareto chart as responsive inline SVG. `msg.payload` is an array of `{defect_type, defect_count, cumulative_pct}`, sorted by count descending. Draw a bar per defect type with its count above and a word-wrapped label below, a cumulative-percentage line with dots over the bars, a dashed threshold line at 80%, and a small legend. Derive the rows from `msg.payload` reactively so the chart redraws on every new message.

Below is the template it produced for us, import it directly if you prefer:

::render-flow{:height='300'}
```json
[{"id":"fef40951758bc433","type":"ui-template","z":"b069d8356c10f58e","g":"54e9382e7013c157","group":"867ef11afa029061","page":"","ui":"","name":"Custom Pareto Chart","order":1,"width":0,"height":0,"head":"","format":"<template>\n    <div class=\"pareto-container\">\n        <svg :viewBox=\"`0 0 ${svgWidth} ${svgHeight}`\" preserveAspectRatio=\"xMidYMid meet\">\n            <!-- Bars -->\n            <g v-for=\"(row, i) in rows\" :key=\"'bar-' + row.defect_type\">\n                <rect\n                    :x=\"barX(i)\"\n                    :y=\"barY(row.defect_count)\"\n                    :width=\"barWidth\"\n                    :height=\"barHeight(row.defect_count)\"\n                    fill=\"#CEBA8C\"\n                    rx=\"3\"\n                />\n                <text\n                    :x=\"barX(i) + barWidth / 2\"\n                    :y=\"barY(row.defect_count) - 8\"\n                    text-anchor=\"middle\"\n                    class=\"bar-label-value\"\n                >{{ row.defect_count }}</text>\n                <text\n                    :x=\"barX(i) + barWidth / 2\"\n                    :y=\"chartAreaHeight + 16\"\n                    text-anchor=\"middle\"\n                    class=\"axis-label\"\n                >\n                    <tspan\n                        v-for=\"(line, li) in wrapLabel(row.defect_type)\"\n                        :key=\"li\"\n                        :x=\"barX(i) + barWidth / 2\"\n                        :dy=\"li === 0 ? 0 : 12\"\n                    >{{ line }}</tspan>\n                </text>\n            </g>\n\n            <!-- 80% threshold dashed line -->\n            <line\n                :x1=\"padding.left\" :x2=\"svgWidth - padding.right\"\n                :y1=\"pctToY(80)\" :y2=\"pctToY(80)\"\n                stroke=\"#74A086\" stroke-width=\"1.5\" stroke-dasharray=\"5,4\"\n            />\n            <text :x=\"svgWidth - padding.right\" :y=\"pctToY(80) - 6\" text-anchor=\"end\" class=\"threshold-label\">80%</text>\n\n            <!-- Cumulative % line -->\n            <polyline\n                :points=\"cumulativeLinePoints\"\n                fill=\"none\"\n                stroke=\"#C28181\"\n                stroke-width=\"2.5\"\n            />\n            <circle\n                v-for=\"(row, i) in rows\"\n                :key=\"'pt-' + row.defect_type\"\n                :cx=\"barX(i) + barWidth / 2\"\n                :cy=\"pctToY(row.cumulative_pct)\"\n                r=\"3.5\"\n                fill=\"#C28181\"\n            />\n        </svg>\n\n        <div class=\"legend\">\n            <span class=\"legend-item\"><span class=\"swatch\" style=\"background:#CEBA8C\"></span>Defect Count</span>\n            <span class=\"legend-item\"><span class=\"swatch\" style=\"background:#C28181\"></span>Cumulative %</span>\n            <span class=\"legend-item\"><span class=\"swatch dash\" style=\"border-color:#74A086\"></span>80% Threshold</span>\n        </div>\n    </div>\n</template>\n\n<script>\nexport default {\n    data() {\n        return {\n            svgWidth: 600,\n            svgHeight: 260,\n            padding: { top: 20, right: 40, bottom: 62, left: 10 }\n        }\n    },\n    computed: {\n        // Per the docs: `msg` is a built-in variable, automatically\n        // assigned whenever this ui-template node receives a message\n        // from Node-RED. Deriving `rows` from it directly (rather than\n        // manually managing a socket listener) means Vue's reactivity\n        // handles updates for us — any change to `msg` recomputes `rows`\n        // and re-renders the SVG automatically.\n        rows() {\n            const payload = this.msg?.payload;\n            return Array.isArray(payload) ? payload : [];\n        },\n        chartAreaHeight() {\n            return this.svgHeight - this.padding.bottom;\n        },\n        maxCount() {\n            return Math.max(1, ...this.rows.map(r => r.defect_count));\n        },\n        barWidth() {\n            const usableWidth = this.svgWidth - this.padding.left - this.padding.right;\n            const n = this.rows.length || 1;\n            return Math.min(60, (usableWidth / n) * 0.6);\n        },\n        cumulativeLinePoints() {\n            return this.rows\n                .map((row, i) => `${this.barX(i) + this.barWidth / 2},${this.pctToY(row.cumulative_pct)}`)\n                .join(' ');\n        }\n    },\n    watch: {\n        // Debug aid only — doesn't drive the chart (the `rows` computed\n        // property does that). Open the browser console (F12) to confirm\n        // messages are actually arriving and check the field names match\n        // (defect_type, defect_count, cumulative_pct).\n        msg: function () {\n            console.log('[Pareto widget] msg updated:', this.msg);\n        }\n    },\n    methods: {\n        barX(i) {\n            const usableWidth = this.svgWidth - this.padding.left - this.padding.right;\n            const n = this.rows.length || 1;\n            const slot = usableWidth / n;\n            return this.padding.left + i * slot + (slot - this.barWidth) / 2;\n        },\n        barY(count) {\n            const usableHeight = this.chartAreaHeight - this.padding.top;\n            return this.chartAreaHeight - (count / this.maxCount) * usableHeight;\n        },\n        barHeight(count) {\n            const usableHeight = this.chartAreaHeight - this.padding.top;\n            return (count / this.maxCount) * usableHeight;\n        },\n        pctToY(pct) {\n            const usableHeight = this.chartAreaHeight - this.padding.top;\n            return this.chartAreaHeight - (pct / 100) * usableHeight;\n        },\n        wrapLabel(label) {\n            // Greedy word-wrap: fits as many words as possible per line\n            // (targeting ~11 chars/line) instead of truncating with \"…\".\n            const words = label.split(' ');\n            const maxCharsPerLine = 11;\n            const lines = [];\n            let currentLine = '';\n\n            words.forEach(word => {\n                const candidate = currentLine ? `${currentLine} ${word}` : word;\n                if (candidate.length > maxCharsPerLine && currentLine) {\n                    lines.push(currentLine);\n                    currentLine = word;\n                } else {\n                    currentLine = candidate;\n                }\n            });\n            if (currentLine) lines.push(currentLine);\n\n            return lines;\n        }\n    }\n}\n</script>\n\n<style>\n.pareto-container {\n    width: 100%;\n}\n.pareto-container svg {\n    width: 100%;\n    height: 260px;\n}\n.bar-label-value {\n    font-size: 11px;\n    fill: #B6BBC1;\n    font-family: sans-serif;\n}\n.axis-label {\n    font-size: 10px;\n    fill: #B6BBC1;\n    font-family: sans-serif;\n}\n.threshold-label {\n    font-size: 10px;\n    fill: #74A086;\n    font-family: sans-serif;\n}\n.legend {\n    display: flex;\n    gap: 16px;\n    justify-content: center;\n    margin-top: 6px;\n    font-size: 12px;\n    color: #B6BBC1;\n}\n.legend-item {\n    display: flex;\n    align-items: center;\n    gap: 6px;\n}\n.swatch {\n    width: 10px;\n    height: 10px;\n    border-radius: 2px;\n    display: inline-block;\n}\n.swatch.dash {\n    background: transparent;\n    border-top: 2px dashed;\n    height: 0;\n}\n</style>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":620,"y":640,"wires":[[]]},{"id":"867ef11afa029061","type":"ui-group","d":true,"name":"Pareto Chart","page":"e7cfd3329956406b","width":"4","height":"2","order":5,"showTitle":false,"className":"","visible":"true","disabled":"false","groupType":"default"},{"id":"e7cfd3329956406b","type":"ui-page","name":"Assembly Quality Monitor","ui":"6481b1c613ec9a93","path":"/defects","icon":"home","layout":"grid","theme":"faac104f34962f3e","breakpoints":[{"name":"Default","px":"0","cols":"3"},{"name":"Tablet","px":"576","cols":"6"},{"name":"Small Desktop","px":"768","cols":"9"},{"name":"Desktop","px":"1024","cols":"12"}],"order":1,"className":"","visible":"true","disabled":"false"},{"id":"6481b1c613ec9a93","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":false},{"id":"faac104f34962f3e","type":"ui-theme","name":"Default Theme","colors":{"surface":"#2e3134","primary":"#5a96d6","bgPage":"#383b3f","groupBg":"#454950","groupOutline":"#585d63"},"sizes":{"density":"default","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}},{"id":"7c924e25db7a85a3","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.30.2"}}]
```
::

![Screenshot: the Pareto chart with bars per defect type and the cumulative-percentage line crossing the 80% marker](https://flowfuse.com/blog/2026/07/images/pareto-chart-added.png)&#x2A;The rendered Pareto chart. Make sure the cumulative line and the dashed 80% threshold are both visible.*

### Root cause

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Root Cause Data": set `msg.payload` to `msg.payload[0].root_cause` (msg).
3. Add a ui-chart node in the Root Cause group, chart type Bar, `root_cause` on the x-axis, `defect_count` on the y.

The query sorts it most-common-first, so the chart reads left to right as a priority list.

![Screenshot: the Root Cause bar chart, sorted most-common-first](https://flowfuse.com/blog/2026/07/images/root-cause-added.png)&#x2A;The root cause bar chart, bars descending left to right.*

### Severity and disposition

1. Add two link in nodes connected to "KPI Result", one per chart.
2. Add two change nodes: "Extract Severity Data" sets `msg.payload` to `msg.payload[0].severity`; "Extract Disposition Data" sets `payload` to `payload[0].disposition`.
3. Add two ui-chart nodes in their groups, chart type Pie. For each, set the label to the category column (`severity` / `disposition`) and the value to `defect_count`.

Severity shows how serious the mix is; disposition shows what it's costing you: Scrap, Rework, or Use-as-is.

![Screenshot: the Severity and Disposition pie charts side by side](https://flowfuse.com/blog/2026/07/images/severity-and-disposition-added.png)&#x2A;The two pie charts. Capture Severity and Disposition together.*

### Defects per day

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Trend Data": set `msg.payload` to `msg.payload[0].trend` (msg).
3. Add a ui-chart node in the Defects Per Day group. Set the chart type to Line, the x-axis property to `date` (type: time), and the y-axis property to `defect_count`.

This is where a bad week, or a bad batch, shows up as a bump you can point at.

![Screenshot: the Defects Per Day line chart showing daily counts over the selected date range](https://flowfuse.com/blog/2026/07/images/defect-day-added.png)&#x2A;The daily trend line chart. A date range showing a visible bump makes the point best.*

### Resolution time and SLA

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Resolution & SLA Data": set `msg.payload` to `msg.payload[0].avg_resolution_and_sla` (msg).
3. Add a ui-table node in the Average Resolution group. Turn off auto-columns and configure five: Severity (`severity`), Hours (`avg_resolution_hours`), Resolved (`resolved_count`), SLA Breached (`sla_breached_count`), SLA % (`sla_breach_pct`).

This is the widget that answers whether defects are being closed fast enough, not just how many exist.

![Screenshot: the Average Resolution & SLA table with its five columns per severity](https://flowfuse.com/blog/2026/07/images/avg-resolution-added.png)&#x2A;The resolution/SLA table, all five columns per severity row.*

### Status funnel

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Status Funnel Data": set `payload` to `payload[0].status_funnel` (msg).
3. Add a ui-chart node in the Status Funnel group, chart type Bar, `status` on the x-axis, `defect_count` on the y.

The query orders it by workflow stage (Detected, RCA, Corrective Action, Resolved, Verified), so a pile-up at any stage is visible at a glance.

![Screenshot: the Status Funnel bar chart, ordered by workflow stage](https://flowfuse.com/blog/2026/07/images/status-funnel.png)&#x2A;The status funnel bar chart, bars in workflow order.*

Deploy and open the dashboard. Every widget populates from the seeded data at once. Change a filter in the header and the whole page recalculates together; leave the live feed running and the numbers keep ticking.

## What Next

You've built a working quality dashboard: a `defects` table, a single query that computes every KPI in one pass, and a page of stat cards, a Pareto chart, trend and breakdown charts, an SLA table, and a status funnel, all filtering live by line, shift, and date.

Right now it runs on the simulator, but that was only ever a stand-in for your real data. To go live, remove the simulator flow and point the query at your own `defects` table. Everything downstream keeps working, because the dashboard only ever reads from that one query. Your defects don't live in PostgreSQL? That's fine too. FlowFuse connects to MySQL, MongoDB, InfluxDB, and more, as our [database integration guides](https://flowfuse.com/node-red/database/) show.

That's the real point. FlowFuse lets you build the exact application your floor needs quickly, without deep engineering knowledge or writing code, wired to the systems you already run instead of forcing your process to fit a fixed tool. This tutorial happened to build defect tracking, but the same approach covers the full range of [manufacturing dashboards](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/), production monitoring, OEE, and the wider quality picture. See how manufacturers are already putting it to work on our [automotive solutions page](https://flowfuse.com/industries/automotive/).


# Building Digital Work Instructions Dashboard for the Shop Floor

Operators need to know what to build, how to build it, and what to do when something breaks. Digital work instructions put that on a screen, guided steps, a checklist, buttons to finish or flag a defect, and retire the paper binder.

But shared stations raise a question paper never had: who's using it? Without a way to tell operators apart, the work order, the current step, and the record of what happened all blur together. Authentication draws the line, the operator's identity becomes the thread the app hangs on.

![Digital work instructions dashboard showing operator work orders, production status](https://flowfuse.com/blog/2026/07/images/digital-work-instruction-dashboard.png)*Digital work instructions dashboard showing operator work orders, production status*

![Operator interface displaying guided work instructions with step completion and defect reporting options](https://flowfuse.com/blog/2026/07/images/digital-work-instruction-2.png)*Operator interface displaying guided work instructions with step completion and defect reporting options*

In this article, we'll build a digital work instructions app in FlowFuse: an operator interface with work orders, step-by-step assembly guidance, defect reporting, and traceability via authentication.

> **Note:** This demo is deliberately configured with a preset demo user so anyone can try it, even without being on the team where it's deployed. The version you build following this article uses FlowFuse User Authentication, which limits dashboard access to members of the same team.

You can interact with the live demo here: :live-demo-link{href="https://expensive-pied-flycatcher-5052.flowfuse.cloud/dashboard/home" label="Try the Digital Work Instruction Dashboard Demo"}.

## What You'll Need

Before you start building, get these ready:

- **A FlowFuse account.** [Sign up](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} for FlowFuse Cloud, or use a self-hosted instance.
- **A FlowFuse instance up and running.** If you don't have one yet, create a new instance from your FlowFuse Platform.
- **FlowFuse Dashboard installed.** This tutorial uses `@flowfuse/node-red-dashboard` nodes (`ui-template`, `ui-table`, `ui-form`, `ui-button`, `ui-control`, `ui-event`, `ui-text`) to build the operator interface. Install it from the Palette Manager if it isn't already in your instance.
- **The FlowFuse Dashboard user addon.** This is what attaches the logged-in user to every dashboard message. We'll install it in the first section.

> Note: The Multi-User addon is available to Teams and Enterprise Self-Hosted customers. If you're on a different tier, [contact us](https://flowfuse.com/contact-us/) for the configuration to get started.

## How the Application Works

Before we build anything, let's walk through what the app does and how the pieces fit together. There are three pages, and one idea holding them together.

1. **Home.** After logging in, the application uses the operator's username to retrieve only the work orders assigned to them from the ERP or MES. It displays their station, production summary, the highest-priority work order, and the remaining queue. Selecting **Start Work Order** opens the instructions.
2. **Instructions.** Operators follow step-by-step instructions with images, checklists, and target cycle times. They can progress through each step, complete the operation, or report an issue at any time.
3. **Report Issue.** Operators can quickly log defects by selecting the issue type, severity, affected part, and description, with the issue automatically linked to the current work order.

The logged-in username acts as the application's lookup key. It retrieves the operator's assigned work orders and stores their active work order and current step, allowing them to resume exactly where they left off, even on shared production stations.

There are two different questions the app has to answer, and it's worth keeping them separate from the start:

- **"Where is this operator's data stored?"** — under a persistent global key named after their username, e.g. `global.get('operator1', 'persistent')`. This is a durable, shared store, and it's meant to be: it's what lets progress survive reloads and reconnects.
- **"Who is acting right now, in this message?"** — this must be read fresh from the message that triggered the flow (`msg._client.user`), not from a single shared "current user" variable. A shared variable has only one value at a time; the moment a second operator's browser connects, it overwrites the first operator's identity for the whole running flow. We'll come back to this the moment it becomes relevant, but it's the one rule that makes every "per operator" claim in this tutorial actually true when two people are logged in at once.

## Importing the Simulated Flow

Instead of connecting to a real ERP or MES, we'll use a simple simulated backend that serves sample work orders through an HTTP API.

1. Import the following flow into FlowFuse and click **Deploy**.

::render-flow{:height='300'}
```json
[{"id":"83cd1b1c4cc8e310","type":"group","z":"3012f9c2796b5b41","style":{"stroke":"#b2b3bd","stroke-opacity":"1","fill":"#f2f3fb","fill-opacity":"0.5","label":true,"label-position":"nw","color":"#32333b"},"nodes":["5a2c1cb7932accb9","f2334a5d527a684a","f65db363fdde0eba","cdda81f6a2701b7c","8554ad9dfdb36f54","6dd109a105da5dd5","439862e5c86675cd","9d853fad37785bec","3506d88cd094d44c","wo_stats_http_in","wo_stats_func","wo_stats_response","6d1644eabb9a5bf5","62760b81dea503c2"],"x":44,"y":59,"w":652,"h":482},{"id":"5a2c1cb7932accb9","type":"http in","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"GET Work Orders","url":"/workorders","method":"get","upload":false,"skipBodyParsing":false,"swaggerDoc":"","x":160,"y":300,"wires":[["f2334a5d527a684a"]]},{"id":"f2334a5d527a684a","type":"function","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"Generate Work Orders","func":"const stationId = msg.req.query.stationId;\nconst username = msg.req.query.username;\n\nconst workOrders = global.get(\"workOrders\", \"persistent\") || [];\n\nconst result = workOrders.filter(w =>\n    w.stationId === stationId &&\n    w.assignedTo === username &&\n    w.status !== \"defect\" &&\n    w.status !== \"completed\"\n);\n\nmsg.payload = result;\n\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":420,"y":300,"wires":[["f65db363fdde0eba"]]},{"id":"f65db363fdde0eba","type":"http response","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"","statusCode":"","headers":{"Content-Type":"application/json"},"x":610,"y":300,"wires":[]},{"id":"cdda81f6a2701b7c","type":"http in","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"POST Mark Defect","url":"/workorders/defect","method":"post","upload":false,"skipBodyParsing":false,"swaggerDoc":"","x":160,"y":400,"wires":[["8554ad9dfdb36f54"]]},{"id":"8554ad9dfdb36f54","type":"function","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"Mark Defect","func":"const { workOrderId, issueType, severity, affectedPart, description } = msg.payload || {};\n\nif (!workOrderId || !issueType || !severity || !affectedPart) {\n    msg.statusCode = 400;\n    msg.payload = { error: 'workOrderId, issueType, severity, and affectedPart are required' };\n    return msg;\n}\n\nconst workOrders = global.get('workOrders', 'persistent') || [];\nconst idx = workOrders.findIndex(w => w.workOrderId === workOrderId);\n\nif (idx === -1) {\n    msg.statusCode = 404;\n    msg.payload = { error: 'Work order not found' };\n    return msg;\n}\n\nworkOrders[idx].status = 'defect';\nworkOrders[idx].defect = {\n    issueType,\n    severity,\n    affectedPart,\n    description: description || null,\n    reportedAt: new Date().toISOString()\n};\n\nglobal.set('workOrders', workOrders, 'persistent');\n\nmsg.statusCode = 200;\nmsg.payload = { success: true, workOrder: workOrders[idx] };\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":390,"y":400,"wires":[["6dd109a105da5dd5"]]},{"id":"6dd109a105da5dd5","type":"http response","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"","statusCode":"","headers":{"Content-Type":"application/json"},"x":610,"y":400,"wires":[]},{"id":"439862e5c86675cd","type":"http in","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"POST Complete Order","url":"/workorders/complete","method":"post","upload":false,"skipBodyParsing":false,"swaggerDoc":"","x":170,"y":500,"wires":[["9d853fad37785bec"]]},{"id":"9d853fad37785bec","type":"function","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"Complete Work Order","func":"const { workOrderId } = msg.payload || {};\n\nif (!workOrderId) {\n    msg.statusCode = 400;\n    msg.payload = { error: 'workOrderId is required' };\n    return msg;\n}\n\nconst workOrders = global.get('workOrders', 'persistent') || [];\nconst idx = workOrders.findIndex(w => w.workOrderId === workOrderId);\n\nif (idx === -1) {\n    msg.statusCode = 404;\n    msg.payload = { error: 'Work order not found' };\n    return msg;\n}\n\nworkOrders[idx].status = 'completed';\nworkOrders[idx].completedAt = new Date().toISOString();\n\nglobal.set('workOrders', workOrders, 'persistent');\n\nmsg.statusCode = 200;\nmsg.payload = { success: true, workOrder: workOrders[idx] };\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":410,"y":500,"wires":[["3506d88cd094d44c"]]},{"id":"3506d88cd094d44c","type":"http response","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"","statusCode":"","headers":{"Content-Type":"application/json"},"x":620,"y":500,"wires":[]},{"id":"wo_stats_http_in","type":"http in","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"GET Work Order Stats","url":"/workorders/stats","method":"get","upload":false,"skipBodyParsing":false,"swaggerDoc":"","x":180,"y":220,"wires":[["wo_stats_func"]]},{"id":"wo_stats_func","type":"function","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"Compute Stats","func":"const workOrders = global.get('workOrders', 'persistent') || [];\nnode.warn(msg.req.query);\nconst stationId = msg.req.query.stationId;\nconst username = msg.req.query.username;\n\n// Filter only by station\nconst stationWorkOrders = stationId\n    ? workOrders.filter(w => w.stationId === stationId)\n    : workOrders;\n\nconst total = stationWorkOrders.length;\nconst completed = stationWorkOrders.filter(w => w.status === \"completed\").length;\nconst defected = stationWorkOrders.filter(w => w.status === \"defect\").length;\n\n// Filter by user within the station\nconst assignedToMe = username\n    ? stationWorkOrders.filter(w => w.assignedTo === username).length\n    : 0;\n\nmsg.statusCode = 200;\nmsg.payload = {\n    total,\n    completed,\n    defected,\n    assignedToMe\n};\n\nreturn msg;","outputs":1,"timeout":"","noerr":0,"initialize":"","finalize":"","libs":[],"x":400,"y":220,"wires":[["wo_stats_response"]]},{"id":"wo_stats_response","type":"http response","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"","statusCode":"","headers":{"Content-Type":"application/json"},"x":610,"y":220,"wires":[]},{"id":"6d1644eabb9a5bf5","type":"function","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","name":"Generate Mock Work Orders","func":"const user = global.get(\"user\", \"persistent\");\nconst currentUser = user?.username || \"operator1\";\n\n// Pool of 5 operators (logged-in user + 4 others)\nconst operators = [\n    currentUser,\n    \"operator2\",\n    \"operator3\",\n    \"operator4\",\n    \"operator5\"\n];\n\nconst vehicles = [\n    {\n        model: \"Sedan X\",\n        variants: [\"Standard\", \"Premium\", \"Sport\"],\n        colors: [\"White\", \"Black\", \"Red\"]\n    },\n    {\n        model: \"SUV Y\",\n        variants: [\"Base\", \"Premium\", \"Sport\"],\n        colors: [\"Grey\", \"White\", \"Black\"]\n    },\n    {\n        model: \"Truck Z\",\n        variants: [\"Standard\", \"Heavy Duty\"],\n        colors: [\"Blue\", \"Green\", \"White\"]\n    },\n    {\n        model: \"Hatchback W\",\n        variants: [\"Base\", \"Sport\"],\n        colors: [\"Silver\", \"Yellow\", \"Red\"]\n    }\n];\n\nconst operations = [\n    {\n        operationId: \"OP_WHEEL_FL\",\n        name: \"Install Front Left Wheel\",\n        instructionSetId: \"INS001\",\n        estimatedCycleTime: 45\n    },\n    {\n        operationId: \"OP_WHEEL_FR\",\n        name: \"Install Front Right Wheel\",\n        instructionSetId: \"INS002\",\n        estimatedCycleTime: 45\n    }\n];\n\nconst priorities = [\"Critical\", \"High\", \"Normal\", \"Low\"];\nconst statuses = [\"Ready\", \"Waiting\", \"Queued\"];\n\nfunction random(arr) {\n    return arr[Math.floor(Math.random() * arr.length)];\n}\n\n// Read existing work orders\nconst existingWorkOrders = global.get(\"workOrders\", \"persistent\") || [];\n\n// Start IDs after the existing ones\nlet nextId = 10245 + existingWorkOrders.length;\n\n// Generate 20 new work orders\nfor (let i = 0; i < 20; i++) {\n    const vehicle = random(vehicles);\n    const operation = random(operations);\n\n    existingWorkOrders.push({\n        workOrderId: `WO-${nextId++}`,\n        stationId: \"ST12\",\n        status: random(statuses),\n        priority: random(priorities),\n        assignedTo: random(operators),\n        vehicle: {\n            vin: `MH01AB${1234567890 + existingWorkOrders.length}`,\n            model: vehicle.model,\n            variant: random(vehicle.variants),\n            color: random(vehicle.colors)\n        },\n        operation: {\n            operationId: operation.operationId,\n            name: operation.name,\n            estimatedCycleTime: operation.estimatedCycleTime,\n            instructionSetId: operation.instructionSetId\n        }\n    });\n}\n\n// Save updated list\nglobal.set(\"workOrders\", existingWorkOrders, \"persistent\");\n\nmsg.payload = existingWorkOrders;\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":440,"y":100,"wires":[[]]},{"id":"62760b81dea503c2","type":"ui-event","z":"3012f9c2796b5b41","g":"83cd1b1c4cc8e310","ui":"37b66bc5b4d6d3d3","name":"","x":160,"y":100,"wires":[["6d1644eabb9a5bf5"]]},{"id":"37b66bc5b4d6d3d3","type":"ui-base","name":"My Dashboard","path":"/dashboard","appIcon":"","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control","ui-template","ui-form","ui-table","ui-text-input","ui-number-input","ui-file-input","ui-button","ui-button-group","ui-dropdown","ui-radio-group","ui-slider","ui-text","ui-switch","ui-chart","ui-audio","ui-markdown","ui-progress","ui-gauge"],"showPathInSidebar":false,"headerContent":"page","navigationStyle":"default","titleBarStyle":"default","showReconnectNotification":true,"notificationDisplayTime":1,"showDisconnectNotification":true,"allowInstall":false},{"id":"4b583d9b76bf5cf2","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.30.2"}}]
```
::

The flow initializes a set of sample work orders and exposes REST APIs that the Digital Work Instructions application uses throughout this tutorial. The `GET /workorders` endpoint returns the active work orders, while the other endpoints simulate completing a work order, reporting defects, and retrieving production statistics. This lets you build and test the application without a live ERP or MES. Later, you can replace these endpoints with calls to your production system while keeping the rest of the application unchanged.

## Setting Up the Dashboard Layout

The application consists of three pages. Most widgets are placed inside named groups, while a few are scoped differently. See the [Dashboard layout docs](https://dashboard.flowfuse.com/getting-started){rel="&#x22;nofollow&#x22;"} if you're new to how pages, groups, and bases relate. The app bar greeting is **UI-scoped**, and the work instruction widget is **page-scoped**, allowing it to fill the entire **Instructions** page without requiring a group. Before adding any widgets, create the dashboard structure by setting up the pages and groups.

1. Create three **ui-page** nodes. The Dashboard automatically creates a base dashboard the first time you add a Dashboard node to the canvas.
   - **Home** (path: `/home`) – The operator's landing page after login. Set the layout to **Notebook** to match the demo application.
   - **Instructions** (path: `/instructions`) – Displays the step-by-step work instructions. Set the layout to **Grid**.
   - **Report Issue** (path: `/report-issue`) – Contains the defect reporting form. Set the layout to **Grid**.
2. Configure the theme for each page as desired.
3. On the **Home** page, create four **ui-group** nodes:
   - **Current Station**
   - **Stats**
   - **Current Work Order**
   - **Up Next**
4. On the **Report Issue** page, create a single **ui-group** named **Report Issue**. This group will contain the issue reporting form and its action buttons.

The **Instructions** page does not require a **ui-group** because the work instruction widget is page-scoped and automatically occupies the full page.

With this layout in place, each widget added in the following sections can be assigned to the appropriate group, or directly to the page when required.

## Enabling FlowFuse User Authentication

Everything starts with a login. Without authentication, the dashboard cannot identify who is using it, so every visitor sees the same experience.

> **Note:** FlowFuse User Authentication grants dashboard access to members of the same team as the instance. Operators you want to sign in must belong to that team, otherwise they won't be able to reach the dashboard. If you need people outside the team to use the application, you'll need to add them to the team.

1. Open your FlowFuse instance **Settings**.
2. Select the **Security** tab.
3. Enable **FlowFuse User Authentication**.

![Screenshot: the Security tab in instance settings with FlowFuse User Authentication enabled](https://flowfuse.com/blog/2024/04/images/displaying-logged-in-user-flowfuse-instance-setting.png)&#x2A;Enable FlowFuse User Authentication in the instance Security settings. You'll also create a Personal Access Token here for authenticating API requests later in the tutorial.*

The first time someone opens the dashboard, they will be prompted to sign in using their FlowFuse username and password. Once authenticated, the dashboard can personalize the experience for each operator throughout the rest of this tutorial.

Because this tutorial also interacts with the FlowFuse API, you'll need to create a Personal Access Token:

4. In the same **Security** tab, click **Add Token**.
5. Enter a name for the token and choose an expiration date.
6. Click **Create**, then copy the generated token and save it somewhere secure. You will need it later in the tutorial.

> **Security note:** Every `http request` node in this tutorial authenticates with this token, and for the sake of a self-contained tutorial we reference it as a plain Bearer token on each node. Don't leave it hardcoded that way in a real deployment. Store it as an environment variable on your FlowFuse instance and reference that variable from each `http request` node's auth config instead, so the raw token never sits in exported flow JSON or version control.

## Installing the User Addon

Authentication identifies the user, but your flows also need access to that information. The FlowFuse User Addon attaches the authenticated user's details to every Dashboard message.

1. Open **Manage Palette**.
2. Go to the **Install** tab.
3. Search for `@flowfuse/node-red-dashboard-2-user-addon`.
4. Click **Install**.

After installation, every Dashboard message includes a `msg._client.user` object:

```json
{
  "userId": "",
  "username": "",
  "email": "",
  "name": "",
  "image": ""
}
```

The same information is available in a **ui-template** using `setup.socketio.auth.user` (or `this.setup.socketio.auth.user` in the script).

1. In the **FF Auth** sidebar tab, ensure **Include Client Data** is enabled.
2. Also enable **Accept Client Data** for **ui-template**, **ui-control**, **ui-event**, **ui-form**, and **ui-table** so each browser session is handled independently and operators don't affect each other's dashboard.

![Screenshot: FF Auth settings showing Include Client Data and Accept Client Data enabled for Dashboard nodes](https://flowfuse.com/blog/2026/07/images/client-data-tab-dashboard.png)&#x2A;Enable **Include Client Data** and **Accept Client Data** to make Dashboard interactions user-specific.*

This is the setting that matters most in this tutorial, and it's worth being explicit about why. With **Accept Client Data** enabled, every message a widget sends carries `msg._client.user` for the session that sent it. That's a per-session identity attached directly to the message, as opposed to a single shared variable that every session would otherwise read and overwrite. We'll use `msg._client.user` as the source of truth for "who is acting right now" in every function node from here on, rather than a global variable.

## Greeting the Logged-In Operator

The first, simplest payoff: show the operator their name and avatar in the app bar, so it's obvious who's signed in at this station. This uses Vue's [Teleport](https://dashboard.flowfuse.com/nodes/widgets/ui-template.html#teleports){rel="&#x22;nofollow&#x22;"} to render into the header's action area from a single widget that lives on every page, so you don't have to add it per page.

1. Add a `ui-template` node and name it "App Bar User Info".
2. Set its type to &#x2A;*Widget (UI-Scoped)** and select your "My Dashboard" ui-base. UI-scoped widgets render on every page automatically, so one widget covers the whole app, no group needed.
3. Paste in the snippet below:

```html
<template>
    <!-- Teleport into #app-bar-actions, the action bar's right-hand corner -->
    <Teleport v-if="loaded" to="#app-bar-actions">
        <div class="user-info">
            <img :src="setup.socketio.auth.user.image" />
            <span>Hi, {{ setup.socketio.auth.user.name }}</span>
        </div>
    </Teleport>
</template>

<script>
export default {
    data() {
        return { loaded: false };
    },
    mounted() {
        // Wait for mount so #app-bar-actions exists before teleporting into it.
        this.loaded = true;
    }
}
</script>

<style>
.user-info { display: flex; align-items: center; gap: 8px; }
.user-info img { width: 24px; height: 24px; }
</style>
```

Deploy and open the dashboard. The signed-in operator's name and avatar appear in the top-right corner. You don't redeploy when a different operator logs in, the addon fetches each user's data at runtime, so everyone sees their own. This widget reads identity straight off the browser's own socket session (`setup.socketio.auth.user`), so it's already per-operator by construction, no shared state involved.

![Screenshot: the dashboard app bar showing the logged-in operator's avatar and greeting](https://flowfuse.com/blog/2026/07/images/logged-in-user-app-bar.png) &#x2A;The signed-in operator greeted by name and avatar in the app bar, rendered from a single UI-scoped widget.*

## Seeding the Operator into Context on Login

Greeting the operator is the visible half. The other half is making their identity available to every function node, not just the widgets.

You might reach for a single shared global here, `global.set('user', msg._client.user, 'persistent')` on connect, then read it everywhere. &#x2A;*Don't.** Global context is one store for the whole flow, not one per session, so if two operators are connected at once, whichever connects last overwrites the identity for everyone, and function nodes start attributing the wrong operator's actions to the wrong person.

Instead, read `msg._client.user` off each message for "who is acting right now," and use the username only as a durable storage key for saved state. A shared global is still handy as a bootstrap fallback for the very first tick of a page, before any client-tagged message has round-tripped.

1. Add a `ui-event` node named "Client connected" and select the "My Dashboard" ui-base. It fires when a browser session connects.
2. Add a `change` node named "Seed globals" with these `set`rules, in order:
   - `user` (global, persistent) → `msg._client.user`. **Bootstrap fallback only**, not the source of truth elsewhere.
   - `StationContext.stationName` (global) → your station's name, e.g. `Wheel Assembly Station 12`.
   - `StationContext.stationId` (global, persistent) → this station's ID, e.g. `ST12`.
   - `Instructions` (global, persistent) → the instruction set (steps, images, target times, checklists), cached so the Instructions page loads instantly.
3. Wire "Client connected" into "Seed globals".

From here on, every function node that needs the current operator uses this pattern, per-session identity first, bootstrap global only as a fallback:

```javascript
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;
```

## Showing the Station and Stats on the Home Page

The Home page shows the current station and a quick summary of work order statistics. Both update whenever the page opens.

### Display the Station Name

1. From the **Client connected** event, add a **change** node named **Read station name** and set `msg.payload` to `global.StationContext.stationName`.
2. Connect it to a **ui-text** node named **Current Station** in the **Current Station** group. Set the value to `msg.payload`.

### Display the Stats

1. Add a **ui-control** node named **Page changed**, set its event to **change**, and select your dashboard.
2. Add a **function** node named **Build /stats request URL** and paste in the following code. &#x2A;*Replace `https://your-instance.flowfuse.cloud` with your own FlowFuse instance URL.**

```javascript
const StationContext = global.get('StationContext', 'persistent');
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

const params = new URLSearchParams();
params.set('stationId', StationContext.stationId);
if (username) params.set('username', username);

msg.url = `https://your-instance.flowfuse.cloud/workorders/stats?${params}`;
msg.method = "GET";
return msg;
```

3. Add an **http request** node that uses `msg.method` and `msg.url`, returns a parsed JSON object, and uses **Bearer** authentication.
4. Configure the bearer token using the access token you created earlier. For production, store it as an environment variable instead of hardcoding it in the flow.
5. Add a **ui-template** named **Stats Cards** in the **Stats** group and paste in the template below.
6. Wire the nodes: **Page changed → Build /stats request URL → HTTP Request → Stats Cards**.

The request includes the logged-in username, so the **Assigned to me** count is personalized for each operator, and because `ui-control` is client-data-aware, `msg._client.user` reflects whichever operator's browser triggered the page change.

![Placeholder: Stats Cards widget rendered on the Home page](https://flowfuse.com/blog/2026/07/images/stats-and-station.png)&#x2A;The Home page displays station statistics, including total, assigned to me, completed, and defected work orders.*

## Loading the Operator's Work Orders

Now for the main part of the Home page: fetching and displaying the operator's work orders. Because the request includes the logged-in username, each operator only sees the work orders assigned to them at the current station.

1. Add a **ui-control** node named **Page changed**, select your dashboard, and set the event to **change**. It fires whenever the operator navigates to the Home page, triggering the work order request.
2. Add a **function** node named **Build /workorders request URL**, paste in the code below, and replace `https://your-instance.flowfuse.cloud` with your own FlowFuse instance URL.

```javascript id="8m19sv"
const StationContext = global.get('StationContext', 'persistent');
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

const stationId = StationContext?.stationId;

const params = new URLSearchParams();
params.set('stationId', stationId);
if (username) params.set('username', username);

msg.url = `https://your-instance.flowfuse.cloud/workorders?${params.toString()}`;
msg.method = 'GET';
return msg;
```

3. Add an **http request** node, set the **Method** to &#x2A;*Use `msg.method`**, leave the **URL** field blank so it uses `msg.url`, set the **Return** type to a **parsed JSON object**, and configure **Bearer** authentication. Use the access token you created earlier as the bearer token. For production deployments, store the token as an environment variable and reference it here instead of hardcoding it in the flow.
4. Connect the **http request** node to a **link out** node named **Work Orders Out**. The widgets that display the work orders will connect to this node using their own **link in** nodes, allowing the same API response to be reused without stretching wires across the canvas.

The username in the request is what makes the dashboard personal. Two operators can open the same page at the same station, yet each receives only the work orders assigned to them, because each one's `ui-control` event carries their own `_client.user`, not a shared one.

## Splitting the Current Order From the Queue

The Home page shows one work order front and centre and the rest as a queue. A function splits the list, sorting by priority so the most urgent job is the one the operator sees first. This function also records which work order the operator is about to start, that's the record the Instructions page, the Complete Operation flow, and the Report Issue flow will all read back later, so it has to be attributed to the right operator from the start.

1. Add a `link in` node named "link in 6" and point it at the "work orders out" link.
2. Add a `function` node named "split current vs queue (by priority)" with **2 outputs**:

```javascript
const orders = Array.isArray(msg.payload) ? msg.payload : [];

// Sort by priority (Critical/Urgent -> High -> Medium -> Normal -> Low)
const priorityOrder = { critical: 0, urgent: 0, high: 1, medium: 2, normal: 3, low: 4 };
const sorted = [...orders].sort(
    (a, b) => (priorityOrder[(a.priority || '').toLowerCase()] ?? 5)
            - (priorityOrder[(b.priority || '').toLowerCase()] ?? 5)
);

const currentWorkOrder = sorted[0] || null;

// Record which work order the current operator is about to see/start.
// Identity comes from the triggering message's client data, not a shared global,
// so this is always attributed to the operator whose browser fetched this list.
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

if (username && currentWorkOrder) {
    const userState = global.get(username, 'persistent') || {};
    userState.workOrderId = currentWorkOrder.workOrderId;
    global.set(username, userState, 'persistent');
}

return [
    { payload: currentWorkOrder },  // output 1: current order (for card)
    { payload: sorted.slice(1) }    // output 2: remaining orders (queue)
];
```

3. Import the Current Work Order Card ui-template below and assign it to the Current Work Order group. The complete component is provided below, so there's no need to recreate it.

> **Tip:** Whenever you need a custom Dashboard widget, you don't have to write the Vue code yourself. Use [FlowFuse Expert](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/#css-and-html-generation-for-flowfuse-dashboard) and describe the widget in plain English and it will generate the `ui-template` for you.

::render-flow{:height='300'}
```json
[{"id":"eb41d1ba8e4bfb01","type":"ui-template","z":"c50b1b501a74c081","g":"3e9b1176168ca254","group":"","page":"","ui":"","name":"Current Work Order Card","order":1,"width":0,"height":0,"head":"","format":"<template>\n  <div class=\"wi-root\">\n    <!-- Top status bar -->\n    <div class=\"wi-topbar\">\n      <div class=\"wi-topbar-left\">\n        <span class=\"wi-wo-label\">WORK ORDER</span>\n        <span class=\"wi-wo-id\">{{ msg?.payload?.workOrderId ?? '—' }}</span>\n      </div>\n      <div class=\"wi-topbar-right\">\n        <v-chip size=\"large\" variant=\"flat\" label :color=\"priorityColor\" class=\"wi-chip\">\n          <v-icon start icon=\"mdi-flag\"></v-icon>\n          {{ (msg?.payload?.priority ?? 'Normal').toUpperCase() }} PRIORITY\n        </v-chip>\n      </div>\n    </div>\n\n    <v-row no-gutters class=\"wi-body\">\n      <!-- Left: Station + Operation -->\n      <v-col cols=\"12\" md=\"5\" class=\"wi-col\">\n        <v-card flat class=\"wi-card wi-card-station\">\n          <div class=\"wi-card-head\">\n            <v-icon icon=\"mdi-map-marker-radius\" size=\"22\"></v-icon>\n            <span>STATION</span>\n          </div>\n          <div class=\"wi-station-id\">{{ msg?.payload?.stationId ?? '—' }}</div>\n\n          <v-divider class=\"wi-divider\"></v-divider>\n\n          <div class=\"wi-card-head\">\n            <v-icon icon=\"mdi-clipboard-text-outline\" size=\"22\"></v-icon>\n            <span>OPERATION</span>\n          </div>\n          <div class=\"wi-operation-name\">\n            {{ msg?.payload?.operation?.name ?? 'Awaiting operation' }}\n          </div>\n\n          <div class=\"wi-cycle\">\n            <v-icon icon=\"mdi-timer-outline\" size=\"26\"></v-icon>\n            <div class=\"wi-cycle-text\">\n              <span class=\"wi-cycle-label\">ESTIMATED CYCLE TIME</span>\n              <span class=\"wi-cycle-value\">\n                {{ msg?.payload?.operation?.estimatedCycleTime ?? '—' }}\n              </span>\n            </div>\n          </div>\n        </v-card>\n      </v-col>\n\n      <!-- Right: Vehicle -->\n      <v-col cols=\"12\" md=\"7\" class=\"wi-col\">\n        <v-card flat class=\"wi-card wi-card-vehicle\">\n          <div class=\"wi-card-head\">\n            <v-icon icon=\"mdi-car-side\" size=\"22\"></v-icon>\n            <span>VEHICLE</span>\n          </div>\n\n          <div class=\"wi-vehicle-model\">\n            {{ msg?.payload?.vehicle?.model ?? 'Unknown model' }}\n          </div>\n          <div class=\"wi-vehicle-variant\">\n            {{ msg?.payload?.vehicle?.variant ?? '' }}\n          </div>\n\n          <v-row no-gutters class=\"wi-spec-grid\">\n            <v-col cols=\"12\" sm=\"7\">\n              <div class=\"wi-spec\">\n                <span class=\"wi-spec-label\">VIN</span>\n                <span class=\"wi-spec-value wi-vin\">\n                  {{ msg?.payload?.vehicle?.vin ?? '—' }}\n                </span>\n              </div>\n            </v-col>\n            <v-col cols=\"12\" sm=\"5\">\n              <div class=\"wi-spec\">\n                <span class=\"wi-spec-label\">COLOR</span>\n                <span class=\"wi-spec-value\">\n                  <v-icon\n                    icon=\"mdi-circle\"\n                    size=\"18\"\n                    class=\"wi-color-dot\"\n                  ></v-icon>\n                  {{ msg?.payload?.vehicle?.color ?? '—' }}\n                </span>\n              </div>\n            </v-col>\n          </v-row>\n        </v-card>\n      </v-col>\n    </v-row>\n\n    <!-- Start button -->\n    <v-btn block size=\"x-large\" color=\"green-darken-1\" class=\"wi-start-btn\" :disabled=\"!msg?.payload?.workOrderId\"\n      @click=\"send({ payload: { action: 'start', workOrderId: msg?.payload?.workOrderId, stationId: msg?.payload?.stationId } })\">\n      <v-icon start icon=\"mdi-play-circle\" size=\"34\"></v-icon>\n      START WORK ORDER\n    </v-btn>\n  </div>\n</template>\n\n<script>\n  export default {\n  computed: {\n    priorityColor () {\n      const p = (this.msg?.payload?.priority ?? '').toLowerCase()\n      if (p === 'high' || p === 'urgent' || p === 'critical') return 'red-darken-1'\n      if (p === 'medium') return 'amber-darken-2'\n      return 'blue-grey-darken-1'\n    }\n  }\n}\n</script>\n\n<style>\n  .wi-root {\n    font-family: 'Roboto', system-ui, sans-serif;\n    color: #1f2933;\n    padding: 4px;\n  }\n\n  .wi-topbar {\n    display: flex;\n    align-items: center;\n    justify-content: space-between;\n    flex-wrap: wrap;\n    gap: 12px;\n    background: #ffffff;\n    border: 1px solid #e2e8f0;\n    border-left: 6px solid #1565c0;\n    border-radius: 10px;\n    padding: 14px 20px;\n    margin-bottom: 14px;\n  }\n\n  .wi-topbar-left {\n    display: flex;\n    flex-direction: column;\n    line-height: 1.1;\n  }\n\n  .wi-wo-label {\n    font-size: 12px;\n    letter-spacing: 2px;\n    color: #64748b;\n    font-weight: 600;\n  }\n\n  .wi-wo-id {\n    font-size: 30px;\n    font-weight: 700;\n    color: #0f172a;\n    font-variant-numeric: tabular-nums;\n  }\n\n  .wi-topbar-right {\n    display: flex;\n    gap: 10px;\n    flex-wrap: wrap;\n  }\n\n  .wi-chip {\n    font-weight: 700 !important;\n    letter-spacing: 0.5px;\n  }\n\n  .wi-body {\n    gap: 0;\n  }\n\n  .wi-col {\n    padding: 6px;\n  }\n\n  .wi-card {\n    background: #ffffff !important;\n    border: 1px solid #e2e8f0 !important;\n    border-radius: 10px !important;\n    padding: 20px 22px;\n    height: 100%;\n  }\n\n  .wi-card-vehicle {\n    border-left: 6px solid #00897b !important;\n  }\n\n  .wi-card-station {\n    border-left: 6px solid #5e35b1 !important;\n  }\n\n  .wi-card-head {\n    display: flex;\n    align-items: center;\n    gap: 8px;\n    font-size: 13px;\n    letter-spacing: 2px;\n    font-weight: 700;\n    color: #64748b;\n    margin-bottom: 6px;\n  }\n\n  .wi-station-id {\n    font-size: 44px;\n    font-weight: 700;\n    color: #4527a0;\n    line-height: 1;\n    margin-bottom: 6px;\n  }\n\n  .wi-divider {\n    margin: 16px 0;\n    border-color: #edf2f7 !important;\n  }\n\n  .wi-operation-name {\n    font-size: 24px;\n    font-weight: 600;\n    color: #0f172a;\n    margin-bottom: 18px;\n  }\n\n  .wi-cycle {\n    display: flex;\n    align-items: center;\n    gap: 12px;\n    background: #f1f5f9;\n    border-radius: 8px;\n    padding: 12px 16px;\n  }\n\n  .wi-cycle-text {\n    display: flex;\n    flex-direction: column;\n    line-height: 1.2;\n  }\n\n  .wi-cycle-label {\n    font-size: 11px;\n    letter-spacing: 1.5px;\n    font-weight: 600;\n    color: #64748b;\n  }\n\n  .wi-cycle-value {\n    font-size: 22px;\n    font-weight: 700;\n    color: #0f172a;\n    font-variant-numeric: tabular-nums;\n  }\n\n  .wi-vehicle-model {\n    font-size: 34px;\n    font-weight: 700;\n    color: #0f172a;\n    line-height: 1.05;\n  }\n\n  .wi-vehicle-variant {\n    font-size: 18px;\n    font-weight: 500;\n    color: #00695c;\n    margin-bottom: 20px;\n  }\n\n  .wi-spec-grid {\n    gap: 0;\n  }\n\n  .wi-spec {\n    display: flex;\n    flex-direction: column;\n    padding: 10px 0;\n  }\n\n  .wi-spec-label {\n    font-size: 11px;\n    letter-spacing: 1.5px;\n    font-weight: 600;\n    color: #64748b;\n    margin-bottom: 2px;\n  }\n\n  .wi-spec-value {\n    font-size: 20px;\n    font-weight: 600;\n    color: #0f172a;\n    display: flex;\n    align-items: center;\n    gap: 6px;\n  }\n\n  .wi-vin {\n    font-family: 'Roboto Mono', monospace;\n    font-size: 18px;\n    letter-spacing: 1px;\n  }\n\n  .wi-color-dot {\n    color: #cbd5e1;\n  }\n\n  .wi-start-btn {\n    margin-top: 16px;\n    height: 84px !important;\n    font-size: 24px !important;\n    font-weight: 700 !important;\n    letter-spacing: 1px;\n    border-radius: 12px !important;\n  }\n</style>","storeOutMessages":true,"passthru":false,"resendOnRefresh":true,"templateScope":"local","className":"","x":570,"y":620,"wires":[["455c7536a9adcfe6"]]},{"id":"77ecf88a48f8c4f0","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.30.2"}}]
```
::

4. Wire **output 1** to the "Current Work Order Card" `ui-template` in the **Current Work Order** group. It shows the work order ID, station, operation and estimated cycle time, the vehicle (model, variant, VIN, colour), a priority chip, and a **Start Work Order** button. On click, the button sends `{ action: 'start', workOrderId, stationId }`.

![Placeholder: Current Work Order Card rendered on the Home page](https://flowfuse.com/blog/2026/07/images/current-work-order.png) &#x2A;The Current Work Order card: work order ID, priority chip, station, operation, vehicle details, and the Start button.*

5. Add a `ui-table` node and assign it to the **Up Next** group. Turn off auto-columns and add two text columns as shown below: Work Order (workOrderId) and Priority (priority). Wire output 2 of the split function into it.

![Placeholder: Up Next table listing queued work orders](https://flowfuse.com/blog/2026/07/images/up-next.png) &#x2A;The Up Next table showing the remaining queued work orders with their priority.*

6. From the card, wire a `change` node named "go to Instructions" that sets `payload` (msg) to `Instructions`, then into a `ui-control` node with its event set to **change** to switch the page.

When the operator taps **Start Work Order**, the card sends them to the Instructions page. Because the split function already saved this operator's `workOrderId` under their own username, the Instructions page, Complete Operation, and Report Issue flows can all look it back up correctly, even if another operator is doing the exact same thing on another screen at the same moment.

## Loading the Cached Instruction Set

The Instructions page needs the steps to show. Because the instruction set was cached in context on login, the page can paint it instantly without another round trip.

1. Add a `ui-event` node named "Page opened" for the Instructions page.
2. Add a `change` node named "Load cached instruction set". Set `payload` (msg) to the persistent global `Instructions`.
3. Wire "Page opened" into it, and its output into the "Work Instruction Widget" you build next.

## Remembering Each Operator's Step

This is something paper can't do and shared screens get wrong. If an operator completes the first two steps of a five-step wheel installation and returns later, they should resume at **step 3**, not start again at **step 1**. We achieve this by saving their progress against their username, the one they were identified as when the step was saved, not whichever username happens to be sitting in a shared global at read time.

The instruction widget emits two housekeeping actions: `save_step` whenever the operator moves between steps, and `load_step` when the page opens and needs to know where to resume. One function node handles both.

1. Import the **Work Instruction Widget** `ui-template` below, assign it to the **Instructions** page, and set its scope to **Page**. The widget displays one instruction at a time with its image, target cycle time, and checklist. Operators can't move to the next step until every checklist item is completed, and the final step changes the button to **Complete Operation**.

> **Tip:** Whenever you need a custom Dashboard widget, you don't have to write the Vue code yourself. Use [FlowFuse Expert](https://flowfuse.com/docs/user/expert/node-red-embedded-ai/?utm_source=chatgpt.com#css-and-html-generation-for-flowfuse-dashboard) and describe the widget in plain English and it will generate the `ui-template` for you.

::render-flow{:height='300'}
```json
[{"id":"d3492b9665d71f27","type":"ui-template","z":"c50b1b501a74c081","g":"96f12d35d68b430e","group":"","page":"","ui":"","name":"Work Instruction Widget","order":1,"width":0,"height":0,"head":"","format":"<template>\n  <div class=\"wi-root\">\n    <!-- Context header with live timer -->\n    <div class=\"wi-topbar\">\n      <div class=\"wi-topbar-left\">\n        <span class=\"wi-op-label\">OPERATION</span>\n        <span class=\"wi-op-name\">{{ payload?.operation ?? 'Work Instruction' }}</span>\n        <span class=\"wi-op-sub\">\n          {{ payload?.instructionSetId ?? '—' }} &nbsp;·&nbsp; v{{ payload?.version ?? '—' }}\n        </span>\n      </div>\n      <div class=\"wi-topbar-right\">\n        <div class=\"wi-timer\">\n          <v-icon icon=\"mdi-timer-outline\" size=\"26\"></v-icon>\n          <div class=\"wi-timer-text\">\n            <span class=\"wi-timer-label\">TARGET TIME</span>\n            <span class=\"wi-timer-value\">{{ currentStep?.estimatedTime ?? '—' }}s</span>\n          </div>\n        </div>\n      </div>\n    </div>\n\n    <!-- Step progress -->\n    <v-card flat class=\"wi-card wi-stepper-card\">\n      <div class=\"wi-stepper-head\">\n        <span class=\"wi-step-count\">\n          STEP {{ (currentIndex + 1) }} OF {{ steps.length }}\n        </span>\n        <span class=\"wi-step-percent\">{{ progressPercent }}% COMPLETE</span>\n      </div>\n      <v-progress-linear :model-value=\"progressPercent\" color=\"green-darken-1\" height=\"8\" rounded></v-progress-linear>\n    </v-card>\n\n    <!-- Main instruction pane: image left, instruction + checklist right -->\n    <v-card flat class=\"wi-card wi-card-instruction\">\n      <div class=\"wi-instruction-flex\">\n        <!-- Reference image (left) -->\n        <div class=\"wi-img-col\">\n          <div class=\"wi-image-wrap\">\n            <img\n              :src=\"stepImage\"\n              :alt=\"currentStep?.title\"\n              class=\"wi-image\"\n              @error=\"onImageError\"\n            />\n          </div>\n        </div>\n\n        <!-- Instruction + checklist (right) -->\n        <div class=\"wi-text-col\">\n          <div class=\"wi-card-head\">\n            <v-icon icon=\"mdi-clipboard-text-outline\" size=\"20\"></v-icon>\n            <span>INSTRUCTION</span>\n          </div>\n          <div class=\"wi-step-title\">{{ currentStep?.title ?? '—' }}</div>\n          <p class=\"wi-step-instruction\">{{ currentStep?.instruction ?? '' }}</p>\n\n          <div class=\"wi-card-head wi-checklist-head\">\n            <v-icon icon=\"mdi-format-list-checks\" size=\"20\"></v-icon>\n            <span>CHECKLIST</span>\n          </div>\n          <div class=\"wi-checklist\">\n            <label\n              v-for=\"(item, i) in (currentStep?.checklist ?? [])\"\n              :key=\"i\"\n              class=\"wi-check-row\"\n              :class=\"{ 'wi-check-row-done': checkedState[i] }\"\n            >\n              <v-checkbox-btn\n                :model-value=\"checkedState[i]\"\n                color=\"green-darken-1\"\n                density=\"comfortable\"\n                @update:model-value=\"toggleCheck(i)\"\n              ></v-checkbox-btn>\n              <span>{{ item }}</span>\n            </label>\n          </div>\n        </div>\n      </div>\n    </v-card>\n\n    <!-- Controls -->\n    <v-row no-gutters class=\"wi-controls\">\n      <v-col cols=\"12\" sm=\"3\" class=\"wi-ctrl-col\">\n        <v-btn block size=\"x-large\" variant=\"outlined\" color=\"blue-grey-darken-1\" class=\"wi-nav-btn\"\n          :disabled=\"currentIndex === 0\" @click=\"prevStep\">\n          <v-icon start icon=\"mdi-chevron-left\" size=\"30\"></v-icon>\n          PREVIOUS\n        </v-btn>\n      </v-col>\n\n      <v-col cols=\"12\" sm=\"3\" class=\"wi-ctrl-col\">\n        <v-btn block size=\"x-large\" variant=\"flat\" color=\"red-darken-1\" class=\"wi-nav-btn\" @click=\"reportDefect\">\n          <v-icon start icon=\"mdi-alert-octagon-outline\" size=\"28\"></v-icon>\n          REPORT ISSUE\n        </v-btn>\n      </v-col>\n\n      <v-col cols=\"12\" sm=\"6\" class=\"wi-ctrl-col\">\n        <v-btn block size=\"x-large\" variant=\"flat\" :color=\"isLastStep ? 'green-darken-2' : 'green-darken-1'\"\n          class=\"wi-nav-btn wi-next-btn\" :disabled=\"!allChecked\" @click=\"nextStep\">\n          <v-icon start :icon=\"isLastStep ? 'mdi-check-circle' : 'mdi-chevron-right'\" size=\"30\"></v-icon>\n          {{ isLastStep ? 'COMPLETE OPERATION' : 'NEXT STEP' }}\n        </v-btn>\n      </v-col>\n    </v-row>\n\n    <div v-if=\"!allChecked\" class=\"wi-hint\">\n      <v-icon icon=\"mdi-information-outline\" size=\"18\"></v-icon>\n      Complete all checklist items to continue.\n    </div>\n  </div>\n</template>\n\n<script>\n  export default {\n  data () {\n    return {\n      currentIndex: 0,\n      checked: {},\n      assetBase: '/assets/',\n      placeholder: 'https://placehold.co/800x600/eef2f7/475569?text=Step+Reference',\n      instruction: null\n    }\n  },\n  computed: {\n    payload () {\n      return this.instruction ?? {}\n    },\n    steps () {\n      return this.instruction?.steps ?? []\n    },\n    currentStep () {\n      return this.steps[this.currentIndex] ?? null\n    },\n    isLastStep () {\n      return this.currentIndex === this.steps.length - 1\n    },\n    progressPercent () {\n      if (!this.steps.length) return 0\n      return Math.round((this.currentIndex / this.steps.length) * 100)\n    },\n    checkedState () {\n      return this.checked[this.currentIndex] ?? []\n    },\n    allChecked () {\n      const list = this.currentStep?.checklist ?? []\n      if (!list.length) return true\n      const state = this.checkedState\n      return list.every((_, i) => state[i])\n    },\n    stepImage () {\n      return this.resolveImage(this.currentStep?.image)\n    }\n  },\n  methods: {\n    resolveImage (img) {\n      if (!img) return this.placeholder\n      if (/^https?:\\/\\//.test(img) || img.startsWith('/')) return img\n      return this.assetBase + img\n    },\n    preloadImages () {\n      for (const step of this.steps) {\n        const url = this.resolveImage(step?.image)\n        if (url && url !== this.placeholder) {\n          const im = new Image()\n          im.src = url\n        }\n      }\n    },\n    saveStep () {\n      this.send({\n        payload: {\n          action: 'save_step',\n          stepIndex: this.currentIndex,\n          stepName: this.currentStep?.title ?? null,\n          stepId: this.currentStep?.stepId ?? null\n        }\n      })\n    },\n    toggleCheck (i) {\n      const arr = (this.checked[this.currentIndex] ?? []).slice()\n      arr[i] = !arr[i]\n      this.checked = { ...this.checked, [this.currentIndex]: arr }\n    },\n    onImageError (e) {\n      if (e?.target && e.target.src !== this.placeholder) {\n        e.target.src = this.placeholder\n      }\n    },\n    goToStep (i) {\n      const max = this.steps.length - 1\n      this.currentIndex = Math.min(Math.max(i, 0), Math.max(max, 0))\n      this.saveStep()\n    },\n    nextStep () {\n      if (this.isLastStep) {\n        this.send({ payload: { action: 'complete_operation', stepIndex: this.currentIndex } })\n        return\n      }\n      this.goToStep(this.currentIndex + 1)\n    },\n    prevStep () {\n      if (this.currentIndex === 0) return\n      this.goToStep(this.currentIndex - 1)\n    },\n    reportDefect () {\n      this.send({\n        payload: {\n          action: 'Report Issue',\n        }\n      })\n    }\n  },\n  watch: {\n    msg: {\n      immediate: true,\n      handler (m) {\n        const pl = m?.payload\n        if (!pl) return\n        if (Array.isArray(pl.steps)) {\n          // Instruction-set data: cache it so later messages can't wipe it.\n          this.instruction = pl\n          // Preload every step image so navigation is instant.\n          this.$nextTick(() => this.preloadImages())\n        } else if (typeof pl.stepIndex === 'number') {\n          // Resume reply from the tracker: jump to the saved step.\n          this.currentIndex = Math.min(\n            Math.max(pl.stepIndex, 0),\n            Math.max(this.steps.length - 1, 0)\n          )\n        }\n      }\n    }\n  },\n  mounted () {\n    // Ask the tracker which step this work order was left on.\n    this.send({ payload: { action: 'load_step' } })\n  }\n}\n</script>\n\n<style>\n  .wi-root {\n    font-family: 'Roboto', system-ui, sans-serif;\n    color: #1f2933;\n    padding: 2px;\n  }\n\n  /* Header */\n  .wi-topbar {\n    display: flex;\n    align-items: center;\n    justify-content: space-between;\n    flex-wrap: wrap;\n    gap: 12px;\n    background: #ffffff;\n    border: 1px solid #e2e8f0;\n    border-left: 6px solid #1565c0;\n    border-radius: 10px;\n    padding: 10px 16px;\n    margin-bottom: 10px;\n  }\n\n  .wi-topbar-left {\n    display: flex;\n    flex-direction: column;\n    line-height: 1.15;\n  }\n\n  .wi-op-label {\n    font-size: 11px;\n    letter-spacing: 2px;\n    color: #64748b;\n    font-weight: 600;\n  }\n\n  .wi-op-name {\n    font-size: 21px;\n    font-weight: 700;\n    color: #0f172a;\n  }\n\n  .wi-op-sub {\n    font-size: 12px;\n    color: #94a3b8;\n    font-weight: 500;\n    margin-top: 2px;\n  }\n\n  .wi-timer {\n    display: flex;\n    align-items: center;\n    gap: 10px;\n    padding: 8px 14px;\n    border-radius: 10px;\n    background: #f1f5f9;\n    color: #0f172a;\n  }\n\n  .wi-timer-text {\n    display: flex;\n    flex-direction: column;\n    line-height: 1.1;\n  }\n\n  .wi-timer-label {\n    font-size: 10px;\n    letter-spacing: 1.5px;\n    font-weight: 600;\n    opacity: 0.75;\n  }\n\n  .wi-timer-value {\n    font-size: 20px;\n    font-weight: 700;\n    font-variant-numeric: tabular-nums;\n  }\n\n  /* Cards */\n  .wi-card {\n    background: #ffffff !important;\n    border: 1px solid #e2e8f0 !important;\n    border-radius: 10px !important;\n    padding: 14px 18px !important;\n    height: 100%;\n    box-sizing: border-box;\n  }\n\n  .wi-card-head {\n    display: flex;\n    align-items: center;\n    gap: 8px;\n    font-size: 13px;\n    letter-spacing: 2px;\n    font-weight: 700;\n    color: #64748b;\n    margin-bottom: 8px;\n  }\n\n  /* Stepper (compact) */\n  .wi-stepper-card {\n    margin-bottom: 10px;\n    padding: 10px 16px;\n  }\n\n  .wi-stepper-head {\n    display: flex;\n    justify-content: space-between;\n    align-items: baseline;\n    margin-bottom: 8px;\n  }\n\n  .wi-step-count {\n    font-size: 14px;\n    font-weight: 700;\n    letter-spacing: 1px;\n    color: #0f172a;\n  }\n\n  .wi-step-percent {\n    font-size: 12px;\n    font-weight: 600;\n    letter-spacing: 1px;\n    color: #64748b;\n  }\n\n  /* Instruction card */\n  .wi-card-instruction {\n    border-left: 5px solid #5e35b1 !important;\n    padding: 16px 20px !important;\n    box-sizing: border-box;\n  }\n\n  /* Desktop: keep the instruction card a consistent size across every step,\n     so navigating between steps does not make the layout jump. The card\n     still grows taller when the reference image needs more room. */\n  @media (min-width: 701px) {\n    .wi-card-instruction {\n      min-height: 360px;\n    }\n  }\n\n  .wi-step-title {\n    font-size: 19px;\n    font-weight: 700;\n    color: #0f172a;\n    margin-bottom: 6px;\n    line-height: 1.15;\n  }\n\n  .wi-step-instruction {\n    font-size: 15px;\n    line-height: 1.55;\n    color: #334155;\n    margin: 0 0 16px;\n  }\n\n  .wi-checklist-head {\n    margin-top: 6px;\n    padding-top: 12px;\n    border-top: 1px solid #edf2f7;\n  }\n\n  .wi-checklist {\n    display: flex;\n    flex-direction: column;\n    gap: 4px;\n  }\n\n  .wi-check-row {\n    display: flex;\n    align-items: center;\n    justify-content: flex-start;\n    gap: 10px;\n    padding: 6px 4px;\n    border-radius: 8px;\n    font-size: 15px;\n    font-weight: 500;\n    color: #1f2933;\n    cursor: pointer;\n  }\n\n  .wi-check-row>span {\n    flex: 1;\n    line-height: 1.35;\n  }\n\n  .wi-check-row .v-selection-control {\n    flex: none;\n    min-width: 0;\n  }\n\n  .wi-check-row-done>span {\n    color: #94a3b8;\n  }\n\n  /* Instruction two-column layout (plain flexbox, no Vuetify grid) */\n  .wi-instruction-flex {\n    display: flex;\n    gap: 20px;\n    align-items: stretch;\n    width: 100%;\n    height: 100%;\n  }\n\n  .wi-img-col {\n    flex: 0 0 40%;\n    display: flex;\n    min-width: 0;\n  }\n\n  .wi-text-col {\n    flex: 1 1 60%;\n    padding-top: 4px;\n    min-width: 0;\n  }\n\n  /* Reference image (left) */\n  .wi-image-wrap {\n    border-radius: 10px;\n    overflow: hidden;\n    background: #f1f5f9;\n    border: 1px solid #e2e8f0;\n    width: 100%;\n    height: 100%;\n    min-height: 210px;\n    display: flex;\n    align-items: center;\n    justify-content: center;\n  }\n\n  /* Desktop: image box tracks a fixed aspect ratio based on its column\n     width, so the card height scales with the image. The text column\n     stretches to match via align-items: stretch on the flex container. */\n  @media (min-width: 701px) {\n    .wi-image-wrap {\n      aspect-ratio: 4 / 3;\n      height: auto;\n      align-self: flex-start;\n    }\n  }\n\n  .wi-image {\n    width: 100%;\n    height: 100%;\n    object-fit: contain;\n  }\n\n  @media (max-width: 700px) {\n    .wi-instruction-flex {\n      flex-direction: column;\n    }\n\n    .wi-img-col {\n      flex: none;\n    }\n\n    .wi-image-wrap {\n      min-height: 150px;\n    }\n  }\n\n  /* Controls */\n  .wi-controls {\n    margin-top: 12px;\n    gap: 0;\n  }\n\n  .wi-ctrl-col {\n    padding: 6px 8px;\n  }\n\n  .wi-nav-btn {\n    height: 52px !important;\n    font-size: 15px !important;\n    font-weight: 700 !important;\n    letter-spacing: 0.5px;\n    border-radius: 12px !important;\n  }\n\n  .wi-nav-btn .v-btn__content {\n    display: flex;\n    align-items: center;\n    justify-content: center;\n  }\n\n  .wi-next-btn {\n    font-size: 17px !important;\n  }\n\n  .wi-hint {\n    display: flex;\n    align-items: center;\n    justify-content: center;\n    gap: 6px;\n    margin-top: 8px;\n    font-size: 14px;\n    font-weight: 500;\n    color: #94a3b8;\n  }\n</style>","storeOutMessages":true,"passthru":true,"resendOnRefresh":true,"templateScope":"widget:page","className":"","x":670,"y":780,"wires":[["c67ea1f6c0580816","effed3f3a008aef7"]]},{"id":"e51561215326fafd","type":"global-config","env":[],"modules":{"@flowfuse/node-red-dashboard":"1.30.2"}}]
```
::

![Placeholder: Work Instruction Widget showing a step with image, checklist, and navigation controls](https://flowfuse.com/blog/2026/07/images/instructions.png) &#x2A;The Instructions page: step image, checklist, target time, and Previous / Report Issue / Next controls.*

2. Add a `function` node named "Track step (save/load per user)":

```javascript
// Remembers the current step per user for the active work order.
// Handles two actions from the widget:
//   save_step - persist the step the operator is on
//   load_step - reply with the saved step so the widget can resume
const p = msg.payload || {};

// Identity comes from this message's own client data first. This is what
// keeps two operators using the widget at the same time from reading or
// writing each other's progress.
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;
if (!username) return null;

// Read the user's saved state
const userState = global.get(username, "persistent") || {
    workOrderId: null,
    stepIndex: 0
};

switch (p.action) {
    case "save_step":
        userState.stepIndex = p.stepIndex ?? 0;
        global.set(username, userState, "persistent");
        return null;

    case "load_step":
        msg.payload = {
            workOrderId: userState.workOrderId,
            stepIndex: userState.stepIndex ?? 0
        };
        return msg;

    default:
        return null;
}
```

3. Wire the "Work Instruction Widget" output into this node, and wire the node's output back into the widget so the `load_step` reply can jump it to the saved step.

Look at the store key: `global.get(username, ...)` and `global.set(username, ...)`. The operator's own username is the storage key, so two operators at the same station never overwrite each other, their progress lives under different keys, and because that key is now sourced from `msg._client.user` rather than a shared global, it's always the username of whoever's browser actually sent this particular `save_step` or `load_step` message.

Deploy, walk halfway through an operation, then reload the page. It reopens where you left off, because the step is filed under your name.

## Completing the Operation as the Logged-In User

When the operator completes the final instruction, the widget sends `{ action: "complete_operation" }`. The flow looks up the operator's stored work order and builds the payload that will be sent to the API.

1. Add a **link in** node and connect it to the **Work Instruction Widget** actions link.
2. Add a **switch** node named **Route by Action** and route messages where `msg.payload.action` equals `complete_operation`.
3. Add a **function** node named **Build Complete Payload** and paste in the following code.

```javascript
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

if (!username) {
    node.warn('No logged-in user found — cannot complete operation');
    return null;
}

const stored = global.get(username, 'persistent') || {};
const workOrderId = stored.workOrderId || null;

msg.payload = { workOrderId };
return msg;
```

4. Add an **http request** node, set the **Method** to **POST**, configure **Bearer** authentication using your access token, and set the URL to `https://your-instance.flowfuse.cloud/workorders/complete`. Replace `https://your-instance.flowfuse.cloud` with your own FlowFuse instance URL.
5. Add a **change** node that sets `msg.payload` to `Home`, then connect it to a **link out** node. This will be used in the next step to reset the operator's state and navigate the operator back to the Home page.

Because the payload is built from the logged-in operator's stored state, keyed off that same operator's per-message identity, the API always completes the correct work order, even when multiple operators are using the dashboard at the same time.

## Reporting a Defect as the Logged-In Operator

If an operator encounters a defect, they can report it from the **Work Instruction Widget**. The report is automatically linked to the work order they're currently performing, so there's no need to enter a work order ID manually.

The **Report Issue** button sends `{ action: "Report Issue" }`. Use that action to open the report form.

1. Add a **link in** node named **Widget Action In** and connect it to the **Work Instruction Widget** actions link.
2. Add a **switch** node named **Route by Action** and route messages where `msg.payload.action` equals `Report Issue`.
3. Add a **change** node that sets `msg.payload` to `Report Issue`, then connect it to a **ui-control** node to navigate to the **Report Issue** page.
4. Add a **ui-form** node named **Report Issue Form** to the **Report Issue** group with four required fields:
   - **Issue Type** (dropdown)
   - **Severity** (dropdown)
   - **Affected Part** (text)
   - **Description** (multiline)
   :brPopulate the dropdown fields with the issue types and severity levels used in your application.

![Screenshot: Report Issue form fields showing the Issue Type, Severity, Affected Part, and Description inputs](https://flowfuse.com/blog/2026/07/images/form-elements.png)&#x2A;The Report Issue form collects the defect details before submitting them against the current work order.*

![Screenshot: Configuring the dropdown options for the Issue Type and Severity fields in the ui-form node](https://flowfuse.com/blog/2026/07/images/form-dropdown.png)&#x2A;Configure the Issue Type and Severity dropdowns with the options used in your application.*

5. Add a **function** node named **Prepare Defect Payload** and paste in the following code.

```javascript id="vbv4m6"
const p = msg.payload || {};

const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

if (!username) {
    node.warn('No logged-in user found — cannot report defect');
    return null;
}

const stored = global.get(username, 'persistent') || {};
const workOrderId = stored.workOrderId || null;

const issueType = p.type;
const severity = p.severity;
const affectedPart = p['affected-part'];
const description = p.description || null;

if (!workOrderId || !issueType || !severity || !affectedPart) {
    node.warn('Missing required defect fields — defect not sent');
    return null;
}

msg.payload = {
    workOrderId,
    issueType,
    severity,
    affectedPart,
    description
};

return msg;
```

6. Add an **http request** node, set the **Method** to **POST**, configure **Bearer** authentication using your access token, and set the URL to `https://your-instance.flowfuse.cloud/workorders/defect`. Replace `https://your-instance.flowfuse.cloud` with your own FlowFuse instance URL, then connect the request to a **link out** node so the flow continues to the reset step.
7. Add a **ui-button** named **Back to Work Instructions** to the same group and connect it to a **ui-control** node that navigates back to the **Instructions** page. Since the operator's progress is stored against their username, they return to the same instruction they left.

![Screenshot: Completed Report Issue page showing the defect reporting form and Back to Work Instructions button](https://flowfuse.com/blog/2026/07/images/report-issue.png)&#x2A;The completed Report Issue page where operators can submit a defect or return to the work instructions.*

The work order ID is retrieved from the logged-in operator's stored state, ensuring every defect report is associated with the correct work order, and the lookup key for that state again comes from this message's own client data, not a value that could have been overwritten by someone else's login in the meantime.

## Clearing State When Work Ends

When an operation is completed or a defect is reported, clear the operator's saved progress so the next work order starts from **step 1** instead of resuming a finished one.

1. Add a **link in** node named **Complete / Defect Result In** and connect it to the **link out** nodes from the **Complete Operation** and **Report Defect** flows.
2. Add a **switch** node that checks `msg.statusCode` equals `200`, so the state is only cleared after a successful API response.
3. Add a **function** node named **Clear User Step State** and paste in the following code.

```javascript id="6ej1v5"
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

if (!username) return null;

global.set(username, {}, 'persistent');

msg.payload = "Home";
return msg;
```

4. Connect the function node to a **ui-control** node to navigate the operator back to the **Home** page.

Because the state is stored and cleared by username, and that username is read from the message that carried the successful API response rather than a shared global, resetting one operator's progress never affects anyone else, even if a second operator has logged in on another screen in between.

Deploy the flow and open the dashboard. After signing in, operators see only the work orders assigned to them. If they leave and return, they resume from the same instruction. Once they complete the operation or report a defect, their progress is cleared and they're returned to the Home page, ready for the next work order.

## Where to Go Next

You've built a personalized digital work instructions application that knows who the operator is, what work they're assigned, and where they left off, correctly, even when several operators are on the dashboard at once. Replacing the simulator with a real ERP or MES is simply a matter of pointing the HTTP Request nodes to your production `/workorders`, `/workorders/complete`, and `/workorders/defect` endpoints.

From there, you can extend the application with production history, quality tracking, role-based experiences, and the [OEE, downtime, and quality dashboards](https://flowfuse.com/blog/2026/08/manufacturing-dashboard-examples/) that run alongside it, all powered by the same operator identity. To see how FlowFuse fits into modern automotive manufacturing, explore the [Automotive solutions page](https://flowfuse.com/industries/automotive/).


# FlowFuse 2.32: Certified Redis, Git Pipelines for Any Server, Insights on Remote Instances, and Dark Mode

This release meets your stack where it already lives. Redis becomes a certified node. DevOps pipelines connect to any HTTPS Git server, not just GitHub. And the FlowFuse Expert can now read the live data on your remote instances and answer questions about it in plain language. Dark mode lands too, so the platform stops glaring at you through long sessions.

## Certified Redis Integration

Community nodes are code you have to vet, secure, and maintain yourself. Certified Nodes take that on with a defined quality, security, and support process.

### Redis Joins the Catalog

2.32 adds **Redis** as a certified node, so you can integrate with Redis using a node FlowFuse tests, secures, and supports, backed by the same trust contract as every certified node: vetted quality, a CVE response commitment, and a real path to support.

Certified Nodes belong to specific FlowFuse packages. Browse the full catalog on the [integrations page](https://flowfuse.com/integrations/?certified=1), and contact us to get them enabled for your team or instance.

## Pipelines Connect to Any Git Server

DevOps Pipeline Git stages only worked with GitHub or Azure DevOps, leaving self-hosted GitLab or on-prem Bitbucket out.

Git Repository stages now connect to any HTTPS Git server: GitLab, Bitbucket, Gitea, or a self-hosted instance. Point a pipeline at the repository and it pushes and pulls snapshots as before. For a server behind a private CA, paste in its certificate, no infrastructure changes needed. This means your team can integrate seamlessly with your existing Git workflow and its compliance setup.

## Do More With the FlowFuse Expert

### Ask about your machine or operational data in Plain Language

Your live machine data sits on your remote instances at the edge. Insights mode now reaches it directly. Point the FlowFuse Expert in "insights" mode, or any AI agent, at a remote instance and ask in plain language: "What was the average cycle time on line 3 today?" You get the answer from live data, with no dashboard to build and no query to write. The Expert can even help you build the MCP servers that feed it, right in Node-RED.

![The FlowFuse Expert answering a plain-language question about live machine data](https://flowfuse.com/blog/2026/07/images/insights-mode.png){dataZoomable="" style="border: 2px solid #E5E7EB;"}

### From Advice to Action

We are enabling the FlowFuse Expert to do things inside the platform, starting with setting up an instance and getting information about your fleet of instances for you. It is the first step toward building any application from beginning to end: you start with the Expert in the platform, it understands the context, provisions the instance, and leads you straight into the Node-RED editor to build it for you. Groundwork, with more to follow.

### Loose for Prototypes, Strict in Production

In support mode, you decide how freely the Expert acts, and you can fine-tune its permissions separately for building flows in Node-RED and for taking actions in the FlowFuse platform. Let it run without interruption while you stand up a first proof of concept, so it builds quickly. Then tighten those same tools for production flows, where you want to see and approve each change before it lands. When a tool is set to ask, an approval card shows exactly what the Expert intends to do and waits for your call.

![The FlowFuse Expert asking to run a tool, with Allow and Deny controls in the chat](https://flowfuse.com/blog/2026/07/images/hitl-approvals.png){dataZoomable="" style="border: 2px solid #E5E7EB;"}

### Plan Together, Build What You Expect

The Expert now understands your intent and plans with you. It asks clarifying questions before it starts implementing, so you get what you need built faster and closer to what you pictured. This is a solid step, and we'll keep improving the Expert from here.

## Dark Mode

FlowFuse has only ever had a light interface, and long sessions in a bright UI are tiring on the eyes. FlowFuse now has a dark mode. Turn it on and the platform switches to a dark theme, easier on the eyes and a better match for a dark desktop. Node-RED auto-switches along with you, which works especially well in combination with the new [Node-RED 5.0](https://flowfuse.com/blog/2026/06/node-red-5-on-flowfuse/)!

![FlowFuse in dark mode](https://flowfuse.com/blog/2026/07/images/dark-mode.png){dataZoomable="" style="border: 2px solid #E5E7EB;"}

*Note: the Node-RED editor only auto-switches with your FlowFuse theme on the latest Node-RED, 5.0.1 and newer, so you set it once.*

## Better Security with Device Agent 4

The Device Agent reaches a new major version. Its container now runs as an unprivileged user instead of root and on Node.js 22, a more secure, modern base that unlocks Insights, token auth, and Node-RED 5 on your devices.

### What This Means for You

Device Agent 4 is a breaking upgrade. When you move to it, make your bind-mounted state directories owned by the agent's user, then upgrade. The platform flags any device that needs v4 to use this release's features. Check the upgrade notes before upgrading.

## What else is new?

- **Real-time status over MQTT**: instance, device, and team status now stream over MQTT instead of HTTP polling, so changes show faster
- **Faster instance lists**: pagination and an N+1 fix on the Hosted and Remote Instances pages, plus sorting by status
- **Namespace-scoped RBAC**: role-based access scoped to a namespace for shared-cluster self-hosted deployments
- **Platform polish**: descriptive page titles, a login-page cookie-consent notice, and a fix for instances reporting suspended while still running

For detailed breakdowns of each feature with additional visuals, visit our [changelog](https://flowfuse.com/changelog/). For the complete list of everything included in FlowFuse 2.32, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases){rel="&#x22;nofollow&#x22;"}.

If something in this release improves your workflow, or if there is still friction we can remove, please [share feedback or report issues regarding this release](mailto\:contact@flowfuse.com?subject=Feedback%20on%202.32) to us.

## Try FlowFuse

### FlowFuse Cloud

The fastest way to get started is with FlowFuse Cloud.
[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in minutes.

### Self-Hosted

Run FlowFuse locally using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).


# FlowFuse 2.33: From Setting Up Plant Floor Hardware to Visualizing Your Data

Most releases sharpen one corner of the platform. 2.33 follows the whole journey your data takes — from the moment hardware powers on to the moment someone reads a dashboard built on it. Bringing a machine online no longer means starting in the platform and working backwards, a certified Modbus package speaks the factory floor's most common protocol, and dashboards finally have somewhere of their own to live. And as more of that journey gets automated, the release tightens the guardrails around the clients and AI agents touching your systems.

## Set Up Your Plant Floor Hardware Straight From the Terminal

Getting your own hardware into FlowFuse meant working backwards. You signed up, found the remote instance section, learned what the Device Agent was, created the instance in the platform, copied its connection details, and only then ran the installer with that code in hand.

Now you can start where the hardware already is. Run the installer from your terminal and it walks you through registering — including setting up an account if you need one — ending with your machine registered as a remote instance and ready to build on. If something's in the way — like port 1880 already being in use — the installer tells you up front instead of failing partway through.

::terminal-frame
---
width: 1000
alt: The installer running in a terminal, walking through sign-up and connection
  to FlowFuse
src: https://flowfuse.com/images/device-agent/terminal-install.gif
---
::

You can grab the install command for your platform on the [Device Agent page](https://flowfuse.com/platform/device-agent/) and have a machine online in a few minutes. More of the from-scratch onboarding experience lands in upcoming releases.

## Modbus Certified Node

FlowFuse Edge customers can now install a FlowFuse-certified Modbus node straight from the palette manager in their editor. It covers Modbus TCP and Serial — including RTU and ASCII — in a single package.

Modbus is one of the most common protocols on the factory floor, but the community package most teams rely on depends on volunteer maintainers. The FlowFuse-certified node is backed by our own testing, SLA-backed security patching, and a long-term maintenance commitment.

*This feature is available exclusively to FlowFuse Edge customers, on both FlowFuse Cloud and Self Hosted, from v2.33.*

## Ask the Expert About Your Tables

Until now, checking on your Tables data meant leaving the chat panel and opening the Tables view yourself. Now you can just ask the Expert: which tables exist, what a table's columns look like, or for a quick peek at the data, and it answers right there. For real analysis, like filtering, sorting, or making changes, the Expert can build that for you too, as a flow using the `tables-query` node.

This release also closes a rough edge in Tables itself: databases with tables outside the default schema now behave correctly throughout, and the UI shows you which schema each table belongs to.

![The Expert answering a question about a FlowFuse Tables database](https://flowfuse.com/blog/2026/07/images/chat.png){dataZoomable="" style="border: 2px solid #E5E7EB;"}

*Availability: This feature is available to FlowFuse Hub and Edge customers on FlowFuse Cloud and Self Hosted from v2.33.*

## Your Dashboards, All in One Place

Dashboards now have a home. A new **Dashboards** entry in your team navigation lists every dashboard across your hosted instances, and opens each one right inside FlowFuse instead of a separate browser tab. Each application also has its own **Dashboards** tab, showing just the dashboards from that application's instances. A drawer lets you switch between dashboards in a single click, without going back to a list.

Until now, dashboards were reachable only through an "Open Dashboard" button on individual instance pages: fine if you knew where to look, a dead end if you didn't. Dashboard-only users had it worst, landing on a bare list of instances with nowhere to go. Now dashboards are a first-class part of the product, with a home scoped to exactly what each user can access.

![An embedded dashboard with the switcher drawer open to move between dashboards](https://flowfuse.com/blog/2026/07/images/dashboard-drawer.png){dataZoomable="" style="border: 2px solid #E5E7EB;"}

*Availability: all users of FlowFuse Cloud and all Self Hosted users from v2.33.*

## Tighter Control Over Who and What Reaches Your Systems

The more of your platform that automated clients and AI agents can reach, the more the question shifts: not just what they are allowed to do, but what you can prove they did afterwards, and how narrowly you can scope their access up front. 2.33 adds three controls that answer it.

### Platform MCP Tools & API Actions Audit Trail

FlowFuse now logs actions performed through the supported platform MCP tools for AI agents such as our own first class AI agent the FlowFuse Expert. Each log entry records the action, when it occurred, and the user that performed it through it's dependency on the user's Personal Access Token. These logs do not capture activity related to MCP server nodes with which you can build your own MCP tooling and is part of our FlowFuse Expert Insights offering.

If you answer to an OT security team or an auditor, "the AI did it" is not an acceptable line in an incident report. The audit trail turns AI activity into the same kind of accountable, reviewable record you already expect from human operators.

*Availability: Hub and Edge from v2.33.*

### Scoped Personal Access Tokens

Personal Access Tokens can now be scoped to specific teams and include read or write permissions. Create a token that can do exactly what its integration needs and nothing more. This is especially important for AI use cases.

Previously a PAT carried the full permissions of the user who created it. If you generated a token for a read-only dashboard integration, that token could still modify your instances. Scoped tokens close that gap and follow the least-privilege pattern your security team already applies everywhere else.

You can easily navigate towards your [personal settings](https://app.flowfuse.com/account/security/tokens){rel="&#x22;nofollow&#x22;"} to setup a new personal access token and configure it with the right scope and permissions.

![The token creation dialog with individual permission scopes selected](https://flowfuse.com/blog/2026/07/images/scoped-pats.png){dataZoomable="" style="border: 2px solid #E5E7EB;"}

*Availability: Hub and Edge from v2.33.*

### Manage Granular RBAC Through Your Identity Provider

SSO admins can now map SAML groups to FlowFuse's granular roles. When someone joins the "Plant Floor Operators" group in your identity provider, they get the matching FlowFuse permissions automatically. No manual role assignment, no drift between your IdP and your platform.

*Availability: Hub and Edge from v2.33.*

## Also in This Release

- The Expert is better at telling when you want it to act versus when you want guidance.
- MCP server enumeration is much faster for teams with many instances.
- Fixed dropdown inputs rejecting values that matched the start of a suggestion.
- Plus dependency updates and smaller fixes.

For detailed breakdowns of each feature with additional visuals, visit our [changelog](https://flowfuse.com/changelog/). For the complete list of everything included in FlowFuse 2.33, check out the [release notes](https://github.com/FlowFuse/flowfuse/releases){rel="&#x22;nofollow&#x22;"}.

If something in this release improves your workflow, or if there is still friction we can remove, please [share feedback or report issues regarding this release](mailto\:contact@flowfuse.com?subject=Feedback%20on%202.33) to us.

## Try FlowFuse

### FlowFuse Cloud

The fastest way to get started is with FlowFuse Cloud.
[Get started for free](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and have your Node-RED instances running in minutes.

### Self-Hosted

Run FlowFuse locally using [Docker](https://flowfuse.com/docs/install/docker/) or [Kubernetes](https://flowfuse.com/docs/install/kubernetes/).

## What's Next

2.33 closes out the 2.x line. Something bigger arrives in August. 📈


# Why Manufacturing Needs GitOps

Manufacturing has always been good at managing change.

If a machine is modified, a production process is updated, or a new recipe is introduced, there's usually a clear process to follow. The change is reviewed, documented, approved, and recorded before it reaches production. That discipline exists because every change can affect quality, uptime, and safety.

Software is now part of that same production process.

A modern factory doesn't just rely on PLCs anymore. Industrial gateways connect machines to business systems, edge applications process production data close to the source, dashboards give operators real-time visibility, and integrations move information between OT systems, MES, ERP, and cloud platforms. These applications are updated regularly as production requirements evolve and operations improve.

The challenge isn't that software changes. It's managing those changes consistently across the factory.

A maintenance engineer updates an application on one gateway to resolve an issue. A new production line needs an additional machine connection, so another device gets a slightly different configuration. An operator requests a dashboard improvement, and the change is made directly on the running system because production can't wait. On an [automotive](https://flowfuse.com/industries/automotive/) line, it might be an updated torque spec pushed to fix one part number, with no clear record afterward of which stations actually received it.

Each change solves an immediate problem. Over time, though, those small updates create a bigger one: one production line starts behaving differently from another, even though they're supposed to be identical. A gateway runs a different application version than the rest of the fleet. During troubleshooting, nobody is completely certain which version is running where, or whether every site received the latest update.

Those aren't software development problems anymore. They're operational problems. As industrial software becomes a bigger part of manufacturing, it needs the same level of change management that manufacturers have applied to machines and processes for decades.

## Applying Change Management to Software

Managing software on a single gateway is straightforward. Managing it across dozens of production lines, multiple factories, or hundreds of edge devices is a very different challenge.

Without a consistent deployment process, software gradually drifts apart. A configuration is changed during troubleshooting but never documented. An engineer fixes an issue directly on a production device because it's the quickest way to restore operations. Each change makes sense in isolation, but over time identical production lines no longer run identical applications, and proving what was deployed, and when, means piecing together information from multiple systems or relying on people's memory.

Software engineering teams faced these same challenges years ago. Rather than treating running systems as the source of truth, they moved to a process where every change is made in a development environment, stored in a Git repository, reviewed before deployment, and promoted into production through a controlled workflow.

This approach is commonly known as GitOps. Despite the name, GitOps isn't really about Git. It's about making software deployments predictable, repeatable, and traceable. The Git repository becomes the record of the application versions that should be running. Every change has a history, every deployment follows the same approval process, and every production environment receives the version that was reviewed, not whatever happened to be changed directly on a device.

For manufacturers, GitOps extends the same principles they've always applied to physical process changes to the software running alongside them.

## Bringing GitOps to the Factory Floor

GitOps provides the process, but manufacturers also need a platform that can apply it to industrial edge infrastructure. That's where FlowFuse fits.

FlowFuse is an industrial application platform that helps manufacturers build, deploy, monitor, and manage applications running across industrial edge devices, centrally rather than gateway by gateway.

DevOps Pipelines extend that platform by bringing a GitOps workflow to industrial applications.

![FlowFuse DevOps Pipeline showing a development stage, staging stage, and Git stage for pushing changes, and a second pipeline with a Git stage pushing deployments through multiple edge device groups across different regions."](https://flowfuse.com/blog/2026/07/images/gitops-pipeline.png)&#x2A;FlowFuse DevOps Pipeline showing a development stage, staging stage, and Git stage for pushing changes, and a second pipeline with a Git stage pushing deployments through multiple edge device groups across different regions."*

Rather than making changes directly on production devices, engineers develop new application versions in a development environment and push them to their organization's Git repository, where changes can be reviewed using the team's existing approval process before deployment.

The Git repository becomes the source of truth for application deployments, while FlowFuse delivers those approved versions to the right devices consistently, whether updating a small pilot line or rolling out a new version across multiple factories.

## Supporting the Git Infrastructure You Already Use

Until now, adopting a GitOps workflow on the factory floor often meant compromising on Git infrastructure. Many manufacturers already host Git internally using platforms such as GitLab, Bitbucket, or Gitea, often for cybersecurity, compliance, or network-architecture reasons. Moving repositories to a cloud-hosted service just to support a deployment workflow isn't practical for many organizations.

[FlowFuse 2.32](https://flowfuse.com/blog/2026/07/flowfuse-release-2-32/#pipelines-connect-to-any-git-server) removes that limitation. DevOps Pipelines now support any Git server accessible over HTTPS, cloud-hosted or self-hosted, and organizations using a private certificate authority can configure their certificates so FlowFuse can communicate securely with internal Git servers.

Getting started is straightforward: create a pipeline, add a Git Repository stage, connect it using a Personal Access Token, choose your repository and branches, and you're ready to deploy through Git. See the [DevOps Pipelines documentation](https://flowfuse.com/docs/user/devops-pipelines/) for step-by-step instructions.

A typical deployment process looks like this:

1. An engineer develops and tests a new application version in a FlowFuse development instance.
2. They create a DevOps Pipeline, starting with the development instance as the source snapshot. Additional stages, such as a staging instance, can be added if required.
3. A Git Repository stage is added to push the application snapshot to the organization's Git repository.
4. The change is reviewed and approved using the team's existing Git workflow (for example, through a pull request).
5. For deployment, another DevOps Pipeline starts with the Git Repository stage as the source and deploys the approved version to the target Hosted instance, Edge Device, or Edge Group.

Every deployment comes from a reviewed version stored in Git, whether that's a handful of gateways on one production line or thousands of edge devices across multiple facilities.

## Software Change Management Is Becoming an Operational Requirement

Modern manufacturing depends on more software than ever before. Every new gateway, edge application, dashboard, and system integration adds another application that needs to be deployed, updated, and maintained throughout its lifecycle. Managing that through manual updates may work for a handful of devices, but it becomes increasingly difficult as deployments scale across production lines, factories, and distributed sites.

GitOps provides a practical way to bring manufacturing's existing discipline around change management to industrial software, by making deployments consistent, changes traceable, and application versions easy to manage.

FlowFuse builds on those principles by helping manufacturers manage industrial applications across fleets of edge devices while integrating with the Git infrastructure they already use, moving from manually updating individual devices to deploying reviewed application versions through a repeatable workflow.

As industrial software continues to grow in importance, knowing exactly which version is running across every production line is no longer just a software engineering concern. It's part of running a modern manufacturing operation.


# Ishikawa Fishbone Diagram: 6M, Manufacturing Example & Template

The most dangerous words in a root cause investigation are often the ones spoken with the most confidence: "We already know what caused it." That assumption sends teams straight to a fix before they've explored the system behind the failure. When the same issue returns a few weeks later, it becomes clear they fixed the symptom, not the cause.

Kaoru Ishikawa built a drawing in the 1960s to kill that exact reflex. It looks like a fish skeleton, which is why almost nobody calls it by his name. Sixty years and a dozen fancier root-cause tools later, engineers still reach for it first. Not because it's clever. Because it forces every theory in the room onto one wall, where the weak ones have nowhere to hide.

## What Is a Fishbone Diagram?

Strip away the terminology and a fishbone diagram is a structured way to brainstorm causes without letting the loudest person in the room decide the answer.

You write the problem, the effect you want to eliminate, on the right side. That's the fish's head. A horizontal line runs left into it: the spine. Off that spine you draw diagonal branches, the ribs, and each rib is a category of causes. Under each category you hang the specific things that might be going wrong. When you're done, you're looking at every plausible cause for one problem, sorted into groups, on a single page.

The naming gets confusing, so here it is plainly. Ishikawa diagram, fishbone diagram, and cause-and-effect diagram all refer to the same tool. The names are used interchangeably in practice, though purists will point out that not every cause-and-effect sketch follows the fishbone shape. It's one of the [seven basic quality tools](https://en.wikipedia.org/wiki/Seven_basic_tools_of_quality){rel="&#x22;nofollow&#x22;"}, the club of simple techniques quality engineers lean on before pulling out anything statistical.

What it does *not* do is prove anything. A fishbone diagram generates hypotheses. It tells you where to look, not what the answer is. That distinction is the whole difference between a diagram that helps and one that wastes an afternoon, and we'll come back to it.

## Who Invented the Ishikawa Diagram?

The diagram is named after [Kaoru Ishikawa](https://en.wikipedia.org/wiki/Kaoru_Ishikawa){rel="&#x22;nofollow&#x22;"} (1915–1989), a Japanese engineer, University of Tokyo professor, and one of the founding fathers of modern quality management. He popularized it in the 1960s while developing quality processes at the Kawasaki shipyards, and formalized it in his 1968 book *Guide to Quality Control*. His aim was democratic: he wanted quality improvement in the hands of ordinary workers, not locked inside a specialist team, so he built a diagram simple enough that anyone on the line could use it, which is a big part of why the [American Society for Quality](https://asq.org/quality-resources/fishbone){rel="&#x22;nofollow&#x22;"} still lists it among the seven basic tools sixty years on.

Its reach since has been broad. One famous case is Mazda, whose engineers reportedly used an Ishikawa diagram to map every factor behind the "Jinba Ittai" (horse and rider as one) feel of the original MX-5 Miata.

## What Are the 6Ms in a Fishbone Diagram?

Ishikawa suggested generic labels for the rib categories so teams would have somewhere to start instead of staring at a blank spine. In manufacturing, those defaults became the 6Ms:

- **Manpower** (people): training gaps, unclear responsibilities, communication breakdowns, fatigue.
- **Method** (process): missing standards, steps performed inconsistently, procedures that no longer match reality.
- **Machine** (equipment): worn parts, skipped maintenance, wrong tooling, calibration drift.
- **Material** (inputs): out-of-spec raw material, supplier variation, wrong batch, storage damage.
- **Measurement** (data): miscalibrated instruments, wrong gauge, inconsistent inspection, bad data collection.
- **Mother Nature** (environment): temperature, humidity, vibration, dust, anything the surroundings do to the process.

Here is the part most guides bury: Ishikawa himself told people to rename these categories to fit their problem. The 6Ms are training wheels, not scripture. They map cleanly onto a factory floor, but even there you'll often want to tweak them, and outside a production line they can fall apart entirely.

Some teams add a seventh M, Money, when cost drivers matter. Process industries sometimes swap in categories like Environment, Equipment, and Procedures. For a service or business problem, the 7Ps (Product, Price, Place, Promotion, People, Process, Physical Evidence) fit better than machinery and materials. The right categories are the ones that make your team say "oh, we haven't thought about that bucket yet." If a category sits empty because it doesn't apply, delete it. An empty rib is not a sign you missed something; it's a sign the label was wrong for your problem.

## How to Make a Fishbone Diagram

The mechanics take five minutes. Doing it well takes discipline. Here's the sequence.

**Write a problem statement, not a topic.** "Machine downtime" is a topic. "Line 3 filler stops an average of 4 times per shift, each stop lasting 6 to 12 minutes" is a problem statement. The second one gives the team something specific to explain. Vague heads produce vague ribs.

**Draw the spine and pick your categories.** Four to six is the sweet spot. Fewer and you're not really sorting; more and the diagram turns into a wall of branches nobody can read. Start from the 6Ms if you're in manufacturing, adapt hard if you're not.

**Brainstorm causes under each category.** This is where the tool earns its keep. Go category by category and ask what, under this heading, could produce the effect. Write everything down, even the theories you doubt. The point of sorting into buckets is that it triggers ideas you'd never reach with an open-ended "what's wrong?"

**Push each cause deeper with "why."** A first-level cause is rarely the root. Pair the fishbone with the [5 Whys](https://flowfuse.com/blog/2025/12/five-whys-root-cause-analysis-definition-examples/): for each rib entry, ask why that happens, and hang the answer as a sub-branch. "Bearing failed" becomes "bearing failed → lubrication skipped → PM schedule not followed → no one owns the schedule." Now you're looking at a root, not a symptom.

**Then stop drawing and start verifying.** This is the step that separates analysis from theater. A finished fishbone is a list of *suspects*, and every suspect is a hypothesis you can test against data. Circle the two or three most likely causes, then go check them: pull the maintenance log, measure the material, watch the operator. The diagram points the flashlight. It doesn't tell you what's in the dark.

## Fishbone Diagram Example

Abstract diagrams teach nothing, so here's the kind of case that plays out on a real line. A packaging line is rejecting cartons because the printed date code is smearing. That's the head of the fish. The team runs 6M categories:

- **Machine:** print head height drifted, print head overdue for cleaning, conveyor speed increased last month.
- **Material:** new ink supplier introduced two weeks ago, carton stock switched to a glossier finish.
- **Method:** no standard for print-head-to-carton distance, cleaning interval never written down.
- **Manpower:** night shift not trained on the new ink's dry time.
- **Measurement:** no check on ink cure before cartons stack.
- **Mother Nature:** plant humidity up since the HVAC repair.

Six categories, roughly a dozen suspects. Now the 5 Whys on the strongest lead: the glossier carton stock. Why does gloss smear? Ink doesn't absorb. Why not? The new stock is non-porous. Why did we switch? Purchasing found a cheaper supplier. Why didn't anyone flag the print impact? No one owns print-compatibility sign-off on material changes.

Notice what happened. The obvious fix, "clean the print head," would have bought a day of relief and then the smearing returns. The fishbone surfaced two causes that interacted, a material change and a missing sign-off process, that a single-thread investigation would have walked right past. That's the entire value of the tool: it makes interacting causes visible instead of letting you commit to the first plausible one.

## Fishbone vs. 5 Whys vs. Pareto: Which One, When

The fishbone rarely works alone, and it's easy to reach for the wrong tool. Here's how the three most common root-cause techniques divide the labor.

| Tool                                                                                               | What it does                                                                                                      | Use it when                                                                                      | Where it falls short                                                                                   |
| -------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ |
| **Fishbone diagram**                                                                               | Goes wide. Surfaces every plausible cause across several categories so nothing obvious gets missed.               | You don't yet know where the problem lives and want the team's collective knowledge on one page. | Treats every branch as equally worth investigating. Says nothing about which cause matters most.       |
| **[5 Whys](https://flowfuse.com/blog/2025/12/five-whys-root-cause-analysis-definition-examples/)** | Goes deep. Drills a single cause chain, asking "why" until you hit something fixable rather than another symptom. | After the fishbone, on the two or three branches you think are strongest.                        | It's a single thread. Drill the wrong cause and you'll reach a confident, well-reasoned, wrong answer. |
| **[Pareto chart](https://flowfuse.com/blog/2025/08/pareto-chart-manufacturing-guide/)**            | Ranks. Sorts candidate causes by frequency or impact so you fix the vital few, not the trivial many.              | You can count occurrences and need to decide where to act first.                                 | Needs data you may not have early on, and only ranks what you already thought to measure.              |

The sequence is: fishbone to find suspects, 5 Whys to reach the root of the best ones, Pareto to decide which roots are worth fixing first. They're not competitors. They're a pipeline.

## Fishbone Diagram Template

You don't need software. Here's a text skeleton you can drop into any doc and fill in:

```text
                    Method            Machine           Measurement
                       \                 |                  /
             cause ─────\        cause ──|        cause ───/
             cause ──────\       cause ──|        cause ──/
                          \              |               /
   ══════════════════════════════════════════════════════════►  [ PROBLEM ]
                          /              |               \
             cause ──────/       cause ──|        cause ──\
             cause ─────/        cause ──|        cause ───\
                       /                 |                  \
                   Manpower          Material           Mother Nature
```

Rules for using it: replace the six labels with categories that fit *your* problem, keep the problem statement specific, and treat every "cause" line as something you'll later verify with data. If you prefer digital, any diagramming tool works, but the paper-and-marker version on a wall is often better because it gets the whole team pointing at the same branch.

## Common Fishbone Diagram Mistakes

Most failed fishbone sessions fail the same handful of ways.

**Labeling empty branches and calling it done.** Six categories with two vague words under each is a brainstorming template, not root-cause analysis. If the diagram doesn't contain specific, checkable causes, you've drawn a fish, not found a problem.

**Confusing the diagram with the answer.** The single most common error. The fishbone lists suspects; it does not convict any of them. Teams that skip verification and just "fix" the most-discussed branch are gambling, not analyzing.

**Using the 6Ms where they don't fit.** Forcing every problem into the manufacturing 6Ms produces empty ribs and missed causes. Pick categories that match your failure surface, and drop the ones that don't apply.

**Vague problem statements.** A fuzzy head produces a fuzzy diagram. Spend the extra two minutes writing what actually happened, where, and how often.

**Stopping at the first level.** "Operator error" is where lazy analysis ends and real analysis begins. Ask why five times before you believe you've hit a root.

## Where the Fishbone Fits

The Ishikawa diagram survives because it does one job well: it gets a group of people to externalize their theories, sort them, and argue about them on paper before spending money. It's cheap, it's visual, and it needs no training to read. Those are the same reasons the simplest tools tend to outlast the sophisticated ones.

It has limits. It shows causes but not their relative weight or how they interact over time; for that you'd reach for a [Pareto chart](https://flowfuse.com/blog/2025/08/pareto-chart-manufacturing-guide/), fault tree, or statistical analysis. And it's only as good as the verification that follows it. Draw the fish, then go prove which bone is broken.

Used that way, as a hypothesis generator that hands off to real investigation, it remains one of the fastest ways to stop treating symptoms and start fixing causes. Sixty years in, that's still a rare thing for a tool to do.

The catch is that verification needs data the whiteboard can't give you: how often the machine actually stalls, whether the material batch really shifted, what the sensor logged when the defect appeared. That's the step where [FlowFuse](https://flowfuse.com) fits, connecting your PLCs, sensors, and quality systems into dashboards so you can test which suspected cause is real and confirm the fix held. It won't draw the fishbone for you, but it settles which bone was broken.


# Software-Defined Manufacturing: Improve Without Hardware Changes

For a long time, improving a manufacturing process meant touching the equipment itself. Need another inspection step? An engineer reprograms the PLC on-site. Need more production data? Install another system. Want a new workflow? That often meant modifying equipment, bringing in a vendor, or scheduling downtime.

That was simply how factories evolved.

Today, the machines are still there. PLCs still control equipment, robots still move products, sensors still collect data. But many improvements now happen in software instead. Manufacturers are connecting machines, production systems, enterprise software, and cloud services in ways that weren't common a few years ago, building dashboards, maintenance workflows, quality applications, and production reports without constantly changing the machines themselves.

That's the idea behind &#x2A;*software-defined manufacturing (SDM)**: separating control logic, process orchestration, and operational intelligence from any single piece of hardware, and running them instead in a software layer that sits above the equipment. The machines don't change. What changes is how quickly and easily they can be connected, coordinated, and improved, through software updates instead of rewiring cabinets or reprogramming individual PLCs.

Some in the industry, including analysts at [ARC Advisory Group](https://www.arcweb.com/glossary/what-software-defined-manufacturing-sdm){rel="&#x22;nofollow&#x22;"} and [Deloitte](https://www.deloitte.com/us/en/services/consulting/articles/software-defined-manufacturing.html){rel="&#x22;nofollow&#x22;"}, describe the fuller vision of SDM as extending all the way to AI-driven optimization and autonomous, agent-based production, where software doesn't just orchestrate equipment but continuously improves how it runs. That broader picture is real, but it starts with the same foundational shift: getting control logic and orchestration out of rigid, single-purpose implementations and into a software layer that can evolve. This article focuses on that foundational layer, the practical, incremental part of SDM that most manufacturers are building toward today.

## Manufacturing Is Becoming More Software-Centric

Manufacturing isn't the first industry to move this way. Networking became software-defined networking. Storage became software-defined storage. Instead of adding dedicated hardware every time a new capability was needed, software took on more responsibility for configuring, managing, and coordinating those systems.

Manufacturing follows a similar pattern, with one important difference: factories still depend on deterministic control, safety systems, and equipment that may stay in production for twenty years or longer. Those systems aren't going away, but what runs around them increasingly is software rather than hardware.

Software sits above those systems, connecting them, exchanging data between them, and coordinating what happens around the production process. That's increasingly important because factory data no longer stays inside the plant. Maintenance teams, quality systems, MES platforms, ERP software, historians, cloud services, and sometimes AI applications all need it. Adding a dashboard, connecting a new machine, or automating a maintenance process has become more of a software project than a hardware one. The equipment stays where it is; the software around it keeps evolving.

## Why Traditional Manufacturing Software Starts to Struggle

The problem is that much of today's manufacturing software wasn't designed to change this often. Many industrial systems were built around a single large implementation: install it, customize it, train everyone, then leave it running for years. That worked when production changed slowly. It becomes much harder when operations are constantly looking for new reports, additional integrations, better visibility, or another workflow. Even small requests, like adding a dashboard, connecting another PLC, or integrating a maintenance system, can turn into large projects.

Vendor lock-in makes this worse. Many industrial platforms depend on proprietary tools or tightly coupled software, so even straightforward improvements take longer than expected because every change runs through the same platform.

Most factories also aren't starting with a clean slate. A single production line might include PLCs installed fifteen years ago alongside modern robots, vision systems, industrial PCs, barcode scanners, cloud services, and enterprise software. The challenge usually isn't replacing those systems. It's getting them to work together reliably.

Software governance adds another layer. Manufacturing teams already have strict processes for changing production equipment; software needs the same discipline. Teams need to know what version is running, who changed it, when it was deployed, and how to roll back if something goes wrong. Without that, software becomes difficult to maintain as more applications get added across the factory. Large modernization projects don't really fix this either, since they often take months or years to deliver value, by which point the business has usually moved on to the next requirement.

## Building Applications That Can Grow

Software-defined manufacturing takes a different approach. Instead of one large application trying to handle everything, manufacturers build smaller applications that each solve a specific problem. Those applications work together, but they don't all have to change at the same time.

Imagine a packaging machine stops unexpectedly. One application records the downtime for OEE. Another updates the production dashboard. Another notifies the maintenance team. Later, the quality team adds an inspection step. Only the quality application needs to change. The downtime application keeps running. The dashboard doesn't need to be touched. Maintenance continues working the same way.

Each application evolves independently, which makes the whole system easier to understand, test, and improve over time. The PLC still controls the machine; the software extends what happens around it, connecting systems, sharing information, automating workflows, and giving different teams the information they need. It's the same decoupling principle behind software-defined networking and storage, applied to the factory floor: the hardware stays fixed, and the software layer above it is what keeps changing.

## From Software Projects to a Software Platform

Building an industrial application is no longer the difficult part.

The difficult part is what happens after that application proves its value.

It gets deployed to another production line. Another factory wants the same solution with a few changes. A new machine needs to be connected. Another dashboard is requested. Before long, what started as one successful application becomes dozens running across multiple lines, plants, and teams.

That's when software-defined manufacturing stops being a development challenge and becomes an operational one.

Manufacturers need more than a way to build applications. They need a consistent way to deploy them, manage them, update them, secure them, and scale them across the organization without every site becoming its own isolated software project.

This is the role FlowFuse plays.

Rather than being another manufacturing application, FlowFuse provides the platform that manufacturers use to build, deploy, and operate industrial applications throughout their lifecycle. It creates a common operating model for software running across the factory, whether that software connects equipment, collects production data, orchestrates workflows, or integrates with enterprise systems.

As more applications are introduced, that consistency becomes increasingly valuable. Teams can standardize how applications are developed, deploy them reliably to edge devices, manage changes through version control and GitOps, track every deployment with audit logs, control access through role-based permissions, and operate applications across multiple sites from a single platform.

The result is that software scales with the business instead of becoming another maintenance burden. Once an application proves its value, it can be reused, adapted, and continuously improved without rebuilding the entire solution for every production line or facility.

[Arch Systems](https://flowfuse.com/customer-stories/scaling-manufacturing-automation-with-flowfuse/) experienced this challenge as its manufacturing platform expanded across customer sites. Connecting more than 100 production databases and MES systems manually was slowing every deployment. By building reusable integration components and deploying them through FlowFuse, Arch standardized its rollout process and propagated changes across production environments from a single platform.

That same approach extends to existing development practices. FlowFuse DevOps Pipelines support GitHub, GitLab, Bitbucket, Gitea, and other Git servers, allowing manufacturers to adopt GitOps workflows without changing the infrastructure they already use.

Software-defined manufacturing isn't simply about writing software for factories. It's about creating a repeatable way to operate software as it becomes part of everyday manufacturing. FlowFuse provides the platform that turns individual software projects into a scalable software-defined manufacturing environment.

## Where Manufacturing Is Heading

The factories that adapt fastest over the next decade won't necessarily be the ones with the newest equipment. They'll be the ones that can turn one operational problem into one working application, then reuse and extend it the next time the same problem shows up on another line or at another site. That's the real shift behind software-defined manufacturing: not a single large modernization project, but a growing library of applications that connect existing equipment, adapt as requirements change, and compound in value over time. FlowFuse is the platform manufacturers use to build that library, one application, one production line, one factory at a time.


# Handling Clock Drift in Distributed Edge Devices

Industrial systems rely on accurate timestamps to understand what happened, when it happened, and how events across different systems relate to each other.

Edge devices, gateways, servers, and data collection systems maintain their own clocks, and those clocks drift over time. When these systems collect and process industrial data, inaccurate timestamps can lead to out-of-order events, unreliable historical records, and incorrect analysis.

In this article, we'll look at why clock drift happens, how to keep distributed industrial systems synchronized, and how to monitor clock health using FlowFuse.

## Why edge clocks drift

Every computer keeps time using a crystal oscillator. These crystals are accurate but not perfect: some run slightly fast, others slightly slow, and their accuracy changes with temperature and age. Two systems that start with the same time gradually drift apart.

That's the slow cause. In production, there are usually bigger reasons clocks become inaccurate.

### No real-time clock

Most servers and desktops include a battery-backed Real-Time Clock (RTC) that keeps time while the machine is powered off. Many low-cost edge devices don't.

The Raspberry Pi is the best-known example. After being powered off, it has no reliable way to remember the current time, so it must wait until it can reach a time server. Without network access, it may boot thinking it's days, months, or even years in the past.

The operating system doesn't know the time is wrong. Applications running on that system, such as data collectors, gateways, and logging services, will continue creating timestamps based on whatever time the operating system reports.

### No access to a time server

Most systems periodically synchronize with a time server to correct clock drift, but that isn't always possible in industrial environments. Many OT networks intentionally block internet access, and some are completely air-gapped.

If an edge device, gateway, or data collection system can't reach a trusted time source, it keeps relying on its own clock, drifting a little further each day. A few milliseconds won't matter. A few weeks or months usually will.

### Backup power doesn't last forever

Some industrial gateways include an RTC but use a supercapacitor instead of a battery to keep it running during power outages. That works well for short outages, but leave the device unpowered for several days or weeks and the capacitor eventually discharges, resetting the clock.

Some industrial Linux systems then fall back to the operating system build date or another fixed timestamp. That's why you'll occasionally find multiple systems reporting exactly the same incorrect date from years ago.

If several systems suddenly report the same incorrect date, it's usually a sign that the backup clock source has been lost.

Leave a fleet running long enough and the clocks won't agree anymore. Most systems will only be slightly off, while a few can end up completely wrong.

## What drift does to your data

Clock drift rarely causes obvious failures. Systems stay online, messages keep arriving, and dashboards still update. The timestamps just quietly become unreliable, and by the time anyone notices, the root cause can be difficult to trace.

The problem appears when data from multiple systems needs to be compared. SCADA platforms, HMIs, historians, and data collection systems rely on timestamps to understand event order, calculate production metrics, and investigate failures.

Events start appearing in the wrong order. If one system reports a motor stop, another an emergency stop, and a third a conveyor jam, but their clocks disagree, the sequence you see may not match what actually happened.

Data can also land in the wrong time bucket. A reading stamped a few seconds late can fall into the wrong aggregation window and quietly skew averages, production counts, and OEE calculations. The timestamp is not invalid, just inaccurate.

Cross-machine correlation suffers too. Comparing robot cycles with conveyor speed, or analyzing a production line failure across multiple systems, only works when those systems share a consistent timeline.

The impact is not usually that machines stop working. The problem is that the historical data used for analysis, troubleshooting, and reporting becomes harder to trust.

## Step one: keep system clocks synchronized

The best place to solve clock drift is at the systems that generate and store timestamps. For edge gateways, servers, and data collection systems, this usually means keeping the operating system clock synchronized. When these systems have an inaccurate clock, applications such as data collectors, SCADA connectors, historians, and logging services can create unreliable timestamps.

Before changing anything, check what's actually running on your systems. Industrial deployments are rarely uniform, since different hardware vendors, OS images, and software versions often ship with different defaults, so it's worth confirming rather than assuming:

```bash
which chronyc    # chrony present?
which ntpq       # classic ntpd present?
timedatectl show-timesync --all   # systemd-timesyncd, on many minimal images
```

Whichever client is present, the underlying goal is the same: keep it pointed at a reliable source and give it a way to maintain accurate time across reboots and network outages.

### Choose an NTP client deliberately

On many modern Linux distributions, **chrony** is the default and has largely replaced the older **ntpd** service. It tends to suit edge environments well: it synchronizes quickly after boot, keeps tracking clock drift while offline, and recovers cleanly when the network becomes available again.

But it isn't universal, since some minimal or vendor-specific images ship with `ntpd`, `systemd-timesyncd`, or nothing at all. Check first, and install or switch only if it makes sense for your deployment.

If you do use chrony, a basic configuration is enough for most deployments:

```bash
# /etc/chrony/chrony.conf

pool pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
```

### Use multiple time sources

Avoid relying on a single time server. If that server has the wrong time or becomes unavailable, every system depending on it inherits the problem.

Using several independent time sources lets the NTP client compare responses, ignore outliers, and maintain a more reliable clock.

### Air-gapped networks still need time synchronization

No internet does not mean industrial systems have to operate with independent clocks.

A common approach is to run a local time server inside the OT network and point edge gateways, servers, and data collection systems to it. The protocol does not change. Only the time source does.

For example:

```bash
server 10.0.5.10 iburst
```

Even if that local server is not synchronized with the internet, every system in the plant can maintain a consistent timeline. For many industrial applications, consistency between systems is more important than perfect UTC accuracy.

If accurate wall-clock time is required, the local server can be synchronized using GPS or another external reference.

### Add a real-time clock where possible

If your hardware does not include an RTC, consider adding one. For devices like the Raspberry Pi, an inexpensive battery-backed RTC module lets the system boot with the correct time even before the network is available.

This is especially useful for systems that power on, perform a task, and shut down again before NTP has a chance to synchronize.

Keeping the operating system synchronized solves most clock drift issues. The next step is making sure your applications preserve the correct timestamps and alert you when a system starts drifting.

## Monitoring drift from FlowFuse

If FlowFuse is already running on your edge devices, it is a convenient place to monitor whether the system clock used by data collection flow remains accurate.

This check applies to the edge computer running FlowFuse or the data collection node, not the PLC itself. The goal is to detect when timestamps generated by the industrial data collection layer may no longer be reliable.

The flow below works with chrony; if a device runs ntpd instead, swap the command in step 2 for `ntpq -p` and adjust the parsing in step 3 to match its output format.

1. Add an inject node to the canvas, name it "Check clock every 5 min", and set it to repeat on an interval of 5 minutes. Clock drift is a trend, not a single reading, so a one-off check will not show whether the offset is increasing.
2. Add an exec node after it, name it "Get chrony offset", and set the command to:

```bash
chronyc tracking
```

This pulls the actual offset from the operating system clock synchronization service rather than estimating it from application timestamps.

3. Add a function node after the exec node, name it "Parse offset", and set it to:

```javascript
const lines = msg.payload.split('\n');
const data = {};

lines.forEach(line => {
    const [key, ...rest] = line.split(':');
    if (key && rest.length) {
        data[key.trim()] = rest.join(':').trim();
    }
});

const parseOffset = (v) => v ? parseFloat(v) * 1000 : null; // to ms

msg.payload = {
    stratum: parseInt(data['Stratum']),
    lastOffsetMs: parseOffset(data['Last offset']),
    rmsOffsetMs: parseOffset(data['RMS offset']),
    leapStatus: data['Leap status'],
    timestamp: new Date().toISOString()
};

return msg;
```

`stratum` tells you how many hops this system is from a reference clock. A rising value can indicate that it has fallen back to a less reliable time source.

`leapStatus` should normally read `Normal`. Any other value should be treated as a synchronization problem rather than simply a small clock offset.

4. Add a switch node after the function node, name it "Over threshold?", checking `payload.lastOffsetMs`. Set the threshold based on how the timestamps are used:

| Use case                                                 | Alert threshold        |
| -------------------------------------------------------- | ---------------------- |
| Historian logging, dashboards, OEE, production reporting | 500ms–1s               |
| Cross-system event correlation and alarm ordering        | \~50–100ms             |
| Applications requiring sub-millisecond precision         | Use PTP instead of NTP |

5. Wire the failing branch to a function node, name it "Build alert", and create a message containing the affected system, clock offset, and stratum information.
6. Send the alert to your existing notification system, such as MQTT, email, or another monitoring platform.

After deployment, trigger the inject node manually once. You should see the parsed clock status in the debug sidebar.

## How accurate does your clock need to be?

Not every industrial application needs microsecond precision. For most use cases, such as historian logging, dashboards, OEE calculations, condition monitoring, and production reporting, NTP provides more than enough accuracy.

With a stable network, a well-configured NTP client can typically keep systems synchronized within a few milliseconds. That is already more accurate than many industrial applications that aggregate data into one-second or one-minute intervals require.

PTP (Precision Time Protocol) is a different story. It is designed for applications where events must be synchronized with sub-millisecond or even microsecond precision.

Examples include:

- motion control
- synchronized robotics
- high-speed sequence-of-events recording
- applications where timing is part of the control or measurement requirement

PTP requires compatible hardware and network infrastructure, making it more complex to deploy than NTP.

If your application does not have strict timing requirements, NTP is usually the simpler and more practical choice.

## Wrapping up

Clock drift is one of those problems that is easy to ignore until it starts affecting production data.

Machines continue running, dashboards continue updating, and messages still arrive, but inaccurate timestamps make troubleshooting, event correlation, and reporting increasingly difficult.

The challenge is not usually PLC control logic itself. PLCs typically operate using scan cycles, timers, and internal execution timing. The one exception is when the data changing on the PLC is faster than the protocol used to read it. In that case, the PLC has to buffer those fast-changing values in an array so nothing is lost between polls. That's a program design and memory concern, not a clock synchronization one; the PLC still isn't timestamping anything itself. The impact of clock drift appears when data from multiple systems needs to be collected, compared, and analyzed.

SCADA systems, historians, HMIs, edge gateways, and industrial data platforms depend on accurate timestamps to understand production events and maintain reliable historical records.

Preventing clock drift does not require complex infrastructure. A reliable NTP client, multiple or local time sources, and hardware with a real-time clock where appropriate can eliminate most clock synchronization issues.

Just as importantly, monitor system clock health so problems are detected before they affect operational data.

Clock drift monitoring is really just one small thing you can do with FlowFuse. At its core, it's a platform for collecting data from your PLCs and sensors, building applications and dashboards on top of that data, and deploying and managing all of it across your fleet from one place.


# What Is Instrument Calibration (Equipment Calibration)?

Instrument calibration is a documented comparison between a measuring instrument and a reference standard that is known to be more accurate. The comparison tells you how far the instrument deviates from the reference under specified conditions.

That sounds straightforward, and at the bench it usually is. Accredited calibration laboratories perform this work every day with well-established procedures.

The problems that create audit findings and production risk tend to appear elsewhere: an overdue gauge that stayed in service, a certificate that cannot be linked to a specific tool, a due date that was never updated, or a failed instrument whose previous measurements were never reviewed.

A caliper that reads **0.03 mm low** can pass parts that are actually oversize. Nothing on the line may look unusual while that caliper is being used. The risk appears later, when those parts are assembled, shipped, or returned.

This article explains what calibration is, how it differs from verification and adjustment, what a calibration record should contain, and how manufacturers can manage calibration status more effectively across the plant.

## What Is Instrument Calibration?

Calibration is the process of comparing an instrument with a reference standard and recording the difference between the two at defined test points.

A complete calibration involves five elements: the instrument under test, a reference standard with better accuracy, measurements taken at selected points across the instrument's range, the deviation between the instrument and the reference, and a documented record of the result.

Notice what is not included in that definition: repairing or adjusting the instrument. Calibration measures performance; it does not automatically correct it.

You will also see the terms **equipment calibration**, **instrument calibration**, and **gauge calibration**. In manufacturing they are generally used to describe the same activity.

## Calibration vs. Verification vs. Adjustment vs. Validation

These terms are often used interchangeably, but they describe different activities.

| Term                                                                                                      | Purpose                                                                        |
| --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| **[Calibration](https://en.wikipedia.org/wiki/Calibration){rel="&#x22;nofollow&#x22;"}**                  | Measure and record the instrument's deviation from a reference standard        |
| **[Verification](https://en.wikipedia.org/wiki/Verification_and_validation){rel="&#x22;nofollow&#x22;"}** | Check whether the measured deviation is within an acceptance limit             |
| **Adjustment**                                                                                            | Change the instrument to reduce its error                                      |
| **[Validation](https://en.wikipedia.org/wiki/Verification_and_validation){rel="&#x22;nofollow&#x22;"}**   | Demonstrate that a process or method consistently produces the intended result |

A calibration certificate may contain both calibration data and a verification statement such as **PASS** or **FAIL**. The pass/fail decision is based on a stated tolerance; it is not the same thing as the calibration itself.

An adjustment changes the instrument. After an adjustment, the instrument should be calibrated again so the final condition is documented.

Validation is broader than calibration. It addresses whether a process works reliably, not whether one instrument reads correctly.

## How Traceability Works

A calibration result is meaningful only when the reference standard is [traceable](https://en.wikipedia.org/wiki/Traceability#Metrology){rel="&#x22;nofollow&#x22;"} to recognized measurement standards.

The traceability chain runs from the [SI unit](https://en.wikipedia.org/wiki/International_System_of_Units){rel="&#x22;nofollow&#x22;"&#x7D;, through a national metrology institute such as &#x2A;*[NIST](https://www.nist.gov/){rel="&#x22;nofollow&#x22;"}*&#x2A;, &#x2A;*[NPL](https://www.npl.co.uk/){rel="&#x22;nofollow&#x22;"}*&#x2A;, or &#x2A;*[PTB](https://www.ptb.de/cms/en.html){rel="&#x22;nofollow&#x22;"}**, through an accredited calibration laboratory, through any working standards used in the plant, and finally to the instrument being calibrated.

Each link in that chain must be documented. The reference standard should have significantly better accuracy than the instrument it is checking.

When selecting an external laboratory, a practical check is accreditation to &#x2A;*[ISO/IEC 17025](https://www.iso.org/ISO-IEC-17025-testing-and-calibration-laboratories.html){rel="&#x22;nofollow&#x22;"}** with a scope that covers the measurement discipline you need, such as pressure, torque, temperature, dimensional measurement, or electrical measurement.

## What a Calibration Record Should Contain

Many organizations store only the certificate date and the pass/fail result. That is rarely enough for traceability, audits, or impact assessment.

A useful calibration record identifies the asset and serial number, records where the instrument is used, and stores the last calibration date, next due date, and interval. It should also preserve the as-found readings, any as-left readings after adjustment, the acceptance tolerance, the laboratory that performed the work, and the certificate number.

Those fields support different operational needs. The due date supports scheduling, the as-found readings support drift analysis, and the certificate number supports audit traceability.

## How Calibration Intervals Are Determined

Calibration intervals are not fixed by physics. They are management decisions based on risk and evidence.

The interval is influenced by manufacturer recommendations, measurement criticality, frequency of use, operating environment, and historical calibration results.

A torque wrench used continuously on an automotive assembly line may need a shorter interval than the same model used occasionally in a maintenance shop.

The most valuable evidence is the **as-found history**. If several consecutive calibrations show very small drift, the interval may be extended. If drift trends toward the tolerance limit, the interval should be shortened.

Without historical as-found data, interval decisions become difficult to justify.

## Why Overdue Instruments Matter

An overdue instrument is not simply an administrative issue. It may represent an active production risk.

If the instrument remained in service after the due date, parts may have been measured without current calibration evidence. If it was removed from service and no spare was available, production may have been affected.

Effective programs monitor instruments **before** they become overdue. The warning window should reflect the actual lead time, including laboratory turnaround, shipping, internal approvals, spare availability, and planned shutdown schedules.

A **30-day warning** is common, but it is not universally appropriate. Some calibrations require much longer planning windows, while others can be completed within a few days.

## What Happens When an Instrument Fails Calibration?

When an instrument is found out of tolerance, the first step is straightforward: remove it from service and prevent further use.

The more important question is what happened **before** the failure was discovered.

An impact assessment considers the last successful calibration date, the size and direction of the error, the characteristics measured with the instrument, the tolerances of those characteristics, and whether product reinspection is required.

This is one reason calibration records should preserve historical calibration events rather than overwriting the previous record.

The same principle applies to reference standards. If a working standard is later found out of tolerance, instruments calibrated against it may also require assessment.

## Which Standards Require Calibration?

Several quality management standards include calibration requirements.

- **[ISO 9001:2015](https://www.iso.org/standard/62085.html){rel="&#x22;nofollow&#x22;"} clause 7.1.5.2** — calibration or verification where measurement traceability is required.
- **[IATF 16949](https://en.wikipedia.org/wiki/IATF_16949){rel="&#x22;nofollow&#x22;"}** — automotive-specific calibration records and laboratory competence requirements.
- **[ISO 13485](https://www.iso.org/standard/59752.html){rel="&#x22;nofollow&#x22;"}** — calibration control for medical-device manufacturers.
- **[AS9100](https://en.wikipedia.org/wiki/AS9100){rel="&#x22;nofollow&#x22;"}** — aerospace calibration controls and record requirements.

Audit findings are frequently related to missing records, overdue equipment, unclear status identification, or inadequate impact assessment rather than to the calibration measurement itself. A shop-floor [layered process audit](https://flowfuse.com/blog/2026/08/layered-process-audit/) is one of the places these gaps get caught early, since checking whether a tool is within its calibration date is a standard item on that checklist.

## Where Calibration Data Should Be Managed

Calibration data is operational data. Production supervisors, maintenance teams, quality engineers, and auditors may all need access to current status information.

A spreadsheet can work for a small population of instruments, but it becomes difficult to maintain as the number of assets grows. Common problems include stale status fields, missed due dates, duplicate records, and limited visibility across departments.

A digital calibration register can derive status directly from due dates, generate due-soon alerts, filter by department or asset type, and provide live compliance metrics.

[FlowFuse](https://flowfuse.com) can connect to calibration records stored in a database, CMMS, or ERP system and present overdue and due-soon status in real time. It can also trigger alerts before an instrument becomes overdue.

We walk through that implementation in [Tracking Instrument Calibration with a Digital Dashboard](https://flowfuse.com/blog/2026/07/calibration-management-dashboard/).


# Automotive Traceability: How Production Data Gets Tied to a Part

A finished vehicle carries more than its physical components. It carries a production history: the materials used, processes performed, machines involved, and quality checks completed along the way.

Automotive traceability makes that history possible to reconstruct.

## What Is Automotive Traceability?

Automotive traceability is the ability to follow a vehicle, component, or individual part through manufacturing and connect it with the data that production generates along the way. At vehicle level the anchor identifier is the VIN. At component level it is a serial number that serialization applies at the start of the process, and the finished result is often called the as-built record: everything known about how that specific unit came together.

Take a manufacturer producing brake assemblies. Each assembly receives a unique identifier, and as it moves through production the manufacturer ties that identifier to the supplier who provided the components, the line that assembled the part, the machine that performed each operation, the torque values the tool recorded, the inspection results, the operator, the timestamp of each operation, the batch number, and whether the part passed its quality check.

Now suppose a quality issue surfaces several days later. Instead of searching through disconnected machine logs, spreadsheets, and production records, the manufacturer looks up the affected part and reads its production history. That is the real value of traceability: it turns production data into a history someone can follow.

## Why Traceability Matters in Automotive Manufacturing

Traceability matters more in [automotive manufacturing](https://flowfuse.com/industries/automotive/) than in most industries because a problem with one component can affect a large number of vehicles, and because the supply chain runs deep. An OEM depends on Tier 1 suppliers who depend on Tier 2 suppliers, and a defect can enter at any level. It is also expected rather than optional, since IATF 16949 requires manufacturers to define traceability so they can identify and contain suspect product.

The scale explains the pressure. NHTSA [processes over 1,000 new recalls each year](https://www.nhtsa.gov/sites/nhtsa.gov/files/2025-01/recall-completion-rates-report-update-01172025.pdf){rel="&#x22;nofollow&#x22;"}, and [completion rates for most component categories land between 60% and 75%](https://www.nhtsa.gov/document/report-congress-vehicle-safety-recall-completion-rates-report){rel="&#x22;nofollow&#x22;"}. A recall that covers more vehicles than it needs to therefore costs more and still leaves defective units on the road. Narrowing the scope is not only cheaper, it is more effective.

Consider a supplier discovering that a batch of components does not meet specification. The manufacturer needs to determine which parts from that batch entered production and which vehicles contain them. That is forward traceability: start with a suspect input and find everywhere it went. Backward traceability works the other way, starting from a returned vehicle and reconstructing what went into it. Without reliable records, either direction turns into a manual investigation across production logs, databases, and spreadsheets. With them, the manufacturer queries the relevant identifiers and gets the affected scope directly.

The same connected history speeds up root-cause analysis. When a component fails final test, a quality engineer starts at its identifier and works backward. Which material batch went into it? Which machine and station handled it? What were the process parameters, and did other parts from the same window show similar results? That makes traceability an engineering tool rather than a compliance checkbox.

It also works proactively. If failures start increasing on one assembly line, engineers compare failed parts against machine parameters, tooling changes, and operating conditions. When a process parameter drifts outside its normal range, teams catch the trend before it produces a large batch of defective parts.

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

## Where Traceability Starts: Incoming Material

Most traceability projects begin at the first production station, which is one station too late. The chain has to start at receiving, because that is where the plant takes custody of material whose history it did not record.

When a shipment arrives, the plant captures the supplier, the supplier's lot or batch number, the material certificate where one applies, the quantity, and the date. That record becomes the top of the genealogy chain, and every part built from that material inherits the link. Skip it, and forward traceability stops at the plant boundary: you can prove which vehicles used lot `B-184`, but not who supplied `B-184` or what else arrived alongside it.

This is the line between internal and external traceability. Internal covers everything inside the plant, from receiving through production and shipping. External extends the chain across organizational boundaries, so a Tier 1 supplier can answer questions about material that came from a Tier 2 supplier. Recall investigations almost always need both, which is why label and identification standards matter: a code applied at a Tier 2 plant has to stay readable at the Tier 1 plant and again at the OEM.

Incoming material also brings the batch-versus-unit question forward. A supplier may ship serialized components, or a lot of bulk material with one identifier covering thousands of pieces. Whatever granularity arrives at the dock sets the floor for how precisely the plant can trace anything built from it.

## What Data Needs to Be Tracked?

A traceability system is only as useful as the data connected to each part. Requirements vary, but a few categories show up almost everywhere.

Part identity is the starting point: a [serial number, Data Matrix code, or RFID tag](https://flowfuse.com/blog/2025/11/building-label-scanner-with-flowfuse/) that links a physical component to its digital record. Automotive commonly uses direct part marking, where a laser or dot-peen head cuts the code into the component itself so it survives washing, painting, and handling. Production information describes where and when the plant processed the part, covering line, workstation, machine, operator, and timestamp. Process data adds detail about the operation itself, which might mean torque, pressure, temperature, or cycle time. [Quality data](https://flowfuse.com/blog/2026/08/statistical-process-control/) records whether the part passed its inspections and tests. Material and batch information connects the finished component back to its source, which matters most when a supplier batch later turns out to have a problem.

Not every part warrants a serial number. Safety-critical and high-value components such as airbags, brake assemblies, and battery packs usually get unit-level identity, while fasteners, adhesives, and bulk materials stay at batch or lot level. Choosing the wrong granularity costs money in both directions: serializing everything adds marking and scanning time at every station, while batch-tracking a safety-critical part widens the containment scope when something goes wrong.

None of these datasets should sit in isolation. The goal is to establish relationships between them, so a vehicle connects to an assembly, which connects to a component, a production step, a machine, its process data, and the resulting quality result.

## Why Connecting the Factory Is the Hard Part

The information traceability requires comes from systems that nobody designed to work together. A PLC holds machine states and process values. A scanner identifies the part. A vision system produces an inspection result. An MES manages production information while a database holds historical records. Each works fine on its own.

A tightening controller may report that an operation finished at 10:42:13 with a torque value of 42 Nm. A scanner may have identified the part as `BRK-10482` moments earlier. The traceability system has to establish that those two events belong together, which means treating machine connectivity, timestamps, identifiers, and storage as one workflow rather than five separate projects.

The problem compounds because one line often includes equipment from several vendors, each exposing information differently. One machine speaks [OPC UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua), another communicates over [EtherNet/IP](https://flowfuse.com/blog/2025/10/using-ethernet-ip-with-flowfuse/), and other equipment publishes through [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/) or exposes a vendor interface of its own.

None of this requires replacing the existing [MES](https://flowfuse.com/blog/2025/06/what-is-mes/), [SCADA](https://flowfuse.com/use-cases/scada/), [PLCs](https://flowfuse.com/landing/plc/), or vendor systems. FlowFuse acts as a low-code [IT/OT integration layer](https://flowfuse.com/use-cases/it-ot-middleware/) between them, connecting machines, protocols, databases, and MES platforms without a rip-and-replace project. Rather than pushing every piece of machine data into a central system, workflows process and route information when relevant production events occur.

## Associating Production Data With Individual Parts

Collecting machine data is only half the problem. The system also needs to know which part that data belongs to, and a unique identifier provides the answer.

Take a simple assembly station. A scanner reads `PART-84721`, and the station opens an active context for that part. The identifier also selects the tightening program, so the tool runs the limits that belong to this specific assembly and stays locked until a valid scan arrives. When the operation finishes, the stored record shows part `PART-84721` at station `Assembly-04`, tightened under program 7, with a torque of 42.1 Nm, an angle of 87.4°, an `OK` result, and a timestamp of 10:42:13.

![Diagram showing a scanner sending part ID PART-84721 to a station PLC, which selects the program and enables a tightening controller over fieldbus and receives an OK or NOK status. FlowFuse reads the part ID from the PLC over OPC UA and exchanges the identifier and results with the tightening controller over Open Protocol, then writes one record to data storage, which an operational application uses for genealogy lookup and containment.](https://flowfuse.com/blog/2026/08/images/station-data-flow.png)&#x2A;A scan opens the context; the tightening result lands against the part that was scanned.*

Notice that the values arrive from two different systems. The identifier lives in the station controller, the torque and the verdict live in the tightening controller, and neither one means much without the other. That record is far more useful than an isolated 42.1 Nm reading, because the identifier supplies the context. A FlowFuse workflow handles the logic directly: take the identifier, collect the values from the relevant equipment, transform them into the required structure, and route the record to its destination.

The same identity check also enables error-proofing. If a part reaches station 5 without a passing record from station 4, the workflow blocks the operation instead of adding another entry to a history nobody reads until a recall. Traceability that only records is a reporting system. Traceability that interlocks stations stops defects from moving down the line.

## Building Part Genealogy

Once manufacturers connect production records, they can build part genealogy, which describes the relationships between a finished product and everything that contributed to it.

Vehicle A contains battery pack 1042, which contains module M-07, built from cell lot `B-184` supplied by cell supplier X. Line 3 and station 7 are not links in that chain. They belong to the point where one item was consumed into another, recorded alongside the timestamp, operator, and result.

![Vertical chain showing part genealogy: a vehicle identified by VIN contains battery pack serial 1042, which contains battery module M-07, which contains cells from lot B-184 supplied by an external cell supplier. Arrows show the chain can be read upward to find what went into a unit or downward to find where a lot was used.](https://flowfuse.com/blog/2026/08/images/part-genealogy.png)&#x2A;Genealogy links a finished vehicle to the components and suppliers behind it, and reads in both directions.*

The chain reads both ways. Trace back from a returned vehicle to find every component behind it, or forward from a defective cell lot to find which modules used it, which packs took those modules, and which vehicles received those packs. The same principle applies down to individual fastening operations, welds, and inspection points.

Notice also where the identifiers change type. The vehicle carries a VIN and the pack and module carry serial numbers, so each one is traceable as a single unit. The cells carry a lot number, so they are traceable as a batch. Where serialization stops is where containment scope widens.

## Structuring and Storing Traceability Data

Genealogy only works if the [underlying data has structure](https://flowfuse.com/blog/2025/06/structuring-storing-data-mes-integration/). A traceability database typically holds parts and serial numbers, production orders, workstations, machines, process steps, materials and batches, measurements, quality results, and timestamps, and the relationships between those records matter as much as the values themselves. A production event that references a part ID, station ID, process ID, and timestamp lets someone reconstruct the history later without duplicating information across systems.

FlowFuse transforms and routes production data into the platform a manufacturer already runs, so teams structure information to fit their existing architecture instead of forcing every production system into one storage technology.

High-volume environments usually separate real-time operational data from long-term historical data. Real-time data supports production monitoring and immediate decisions, while historical data stays available for quality analysis, audits, and investigations. Retention is worth settling early, because customer contracts and regulatory requirements often set it rather than leaving it to the plant.

## Scaling Traceability Across Production Lines

A solution that works at one station becomes hard to manage once it spreads across an entire factory. Different lines carry different equipment, protocols, and processes, while manufacturers still want one consistent approach to collecting production information.

Instead of running a separate integration project for every line, manufacturers can [establish reusable workflows and deployment patterns](https://flowfuse.com/landing/building-and-scaling-industrial-applications/). FlowFuse provides centralized management for industrial applications across production environments, which helps teams move past one-off integrations as applications reach multiple lines or plants. Workflows still adapt to the equipment at each site while following common patterns for deployment, management, and governance.

## Final Thoughts

Automotive traceability is about more than knowing where a part came from. It makes production observable enough that manufacturers understand what happened, when it happened, and how the events connect.

That takes more than collecting data. Manufacturers need to connect machines and assets, move information between protocols and systems, structure the result, and deliver it to the people and applications that depend on it. An event-driven integration layer like FlowFuse supplies that connective tissue without replacing the systems already running the factory.

The payoff is an architecture that grows with the operation, from one station to a full line and eventually across multiple plants. When every relevant production event connects to the part it belongs to, manufacturers gain a complete, searchable history of how their products were made. The next time a quality issue appears, they are no longer asking what happened. They can start answering it.


# VDA 5050 Tutorial: Connect AGVs to Factory Systems over MQTT

If you run AGVs from more than one vendor, you already know the problem. Each vendor ships its own fleet manager. Those fleet managers don't talk to each other.

Two fleets under separate control can't share an intersection. So you either accept deadlocks, or you split the floor into separate lanes and waste space. Each fleet manager also needs its own link to your ERP, MES, or WMS. Adding a vehicle from a new vendor means [another integration project](https://flowfuse.com/blog/2024/11/why-point-to-point-connection-is-dead/). And because no single system sees all the work, one vendor's AGVs sit idle while the other's are backed up.

VDA 5050 solves that. FlowFuse gives you somewhere to build the master control system that uses it.

:cta-image{alt="Walk through your FlowFuse setup with our team - book a demo" cta="demo" src="https://flowfuse.com/images/cta/book-a-demo.png"}

## Why VDA 5050?

VDA 5050 is an open communication standard. The VDA (the German automotive association) and the VDMA (the machinery association) publish it together. The Institute for Material Handling and Logistics (IFL) at KIT leads the technical work.

It first appeared in 2019. It sets out how a master control system sends transport orders to a vehicle, and how that vehicle reports back. Messages travel over MQTT as JSON.

Most AGVs and AMRs on factory floors today speak the 2.x version. Version 3.0 came out on 19 March 2026 and adds support for freely navigating robots.

### One interface, any vehicle

A master control system that speaks VDA 5050 can drive vehicles from different makers. You don't write a new integration for each one.

The standard fixes the message contract, not the vehicle. How an AGV avoids obstacles or plans its path is still up to the manufacturer. What you get is a shared order format and a shared status format.

If you already run [Sparkplug B](https://flowfuse.com/blog/2026/06/mqtt-vs-sparkplug-b/) on the same broker, the two solve different problems. Sparkplug standardizes telemetry from any device. VDA 5050 standardizes a command-and-report contract for one class of device, so it says what an order looks like as well as what a status message looks like.

Safety stays out of scope. Emergency stops and person detection live on the vehicle and follow standards like ISO 3691-4. VDA 5050 reports safety state. It does not implement it.

### Real detail, not just a heartbeat

The messages carry operational data. A `state` message includes position, battery charge, order progress, and any active errors. An `order` describes a route of nodes and edges with actions attached, such as pick, drop, wait, or charge.

That detail is what lets master control make dispatch decisions, instead of just knowing a vehicle is online.

### Built on MQTT

MQTT suits a fleet well. It is lightweight, it uses [publish and subscribe](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/), and it copes with devices that drop off the network. Vehicles report when something changes rather than waiting to be polled, which is [event-driven architecture](https://flowfuse.com/blog/2026/02/what-is-event-driven-architecture-in-manufacturing/) applied to a floor full of moving hardware.

Every VDA 5050 topic follows the same pattern. So one wildcard subscription hears from every vehicle on the floor, whoever built it.

## The six topics

| Topic            | Sent by                   | Read by        | What it carries                                              |
| ---------------- | ------------------------- | -------------- | ------------------------------------------------------------ |
| `order`          | Master control            | AGV            | A route of nodes and edges, with actions                     |
| `instantActions` | Master control            | AGV            | Immediate commands: pause, resume, cancel, start charging    |
| `state`          | AGV                       | Master control | Full status: position, battery, order progress, errors       |
| `visualization`  | AGV                       | Map displays   | Position and velocity only, sent more often than `state`     |
| `connection`     | AGV, or the broker for it | Master control | Online and offline at the MQTT level                         |
| `factsheet`      | AGV                       | Master control | What the vehicle can do: size, load types, supported actions |

Both `state` and `visualization` carry position. That is on purpose.

`state` is the full picture. A vehicle sends it when something changes, and at least once every 30 seconds. `visualization` is a small message with just position and velocity, so it can go out far more often, typically once a second or faster.

Use `state` for anything master control acts on. Use `visualization` only to draw a smooth live map. Note that `visualization` is optional in the standard, so some vehicles never send it. Version 3.0 widens its job: it now carries the planned path too, so traffic control can read it rather than just a map display.

### How topics are named

```text
<interfaceName>/<majorVersion>/<manufacturer>/<serialNumber>/<topic>
```

For example: `uagv/v2/AcmeRobotics/AGV-042/state`

`uagv` is the interface name the standard uses in its own examples, and most people read it as short for "universal AGV". The standard itself only calls it the name of the interface, and each site can set its own. But nearly every 2.x deployment uses `uagv`, including the vehicles you are likely to buy. Treat it as fixed unless the vehicle's manual says otherwise.

The same caveat applies to the levels around it. The standard mandates the topic names in the final segment, `order`, `state`, and so on. It calls the [five-level structure](https://flowfuse.com/blog/2025/01/designing-topic-hierarchy-for-your-uns/) a suggestion for a local broker, because cloud brokers impose their own topic rules. On-premise fleets follow it anyway, so build against it and adapt only if your broker forces you to.

The version segment is the major version only. So `v2`, not `v2.0.0`. The full version number goes in the `version` field inside the payload.

Because the maker and serial number sit in the topic, master control can subscribe once to `uagv/v2/+/+/state` and hear from every vehicle. Restrict each vehicle to its own topic path, using an allowlist on your broker.

### A note on version 3.0

This tutorial uses version 2.x names, because that is what most vehicles speak today. Version 3.0 renames a lot:

- The example topic prefix moves to `vda5050/v3/...`
- `agvPosition` becomes `mobileRobotPosition`
- `batteryState` becomes `powerSupply`, and `batteryCharge` becomes `stateOfCharge`
- `positionInitialized` becomes `localized`
- `safetyState.eStop` becomes `activeEmergencyStop`, and the `AUTOACK` value is gone
- `actionStates` splits into `actionStates`, `instantActionStates`, and `zoneActionStates`, each cleared by its own instant action
- Edges drop `startNodeId` and `endNodeId`. Position in the sequence alone now says which nodes an edge connects
- Errors gain two levels, `CRITICAL` and `URGENT`
- Every robot must support `startPause`, `stopPause`, and `cancelOrder`
- `timestamp` moves from hundredths of a second to milliseconds
- Version 3.0 adds two optional topics, `zoneSet` and `responses`, and a fourth blocking type, `SINGLE`
- `CONNECTIONBROKEN` becomes `CONNECTION_BROKEN`, and `HIBERNATING` is added
- It also adds the operating modes `STARTUP` and `INTERVENED`
- The wording changes from "AGV" to "mobile robot" throughout

Version 3.0 also strips abbreviations out of parameter names across the whole document, which is a breaking change. The [3.0.0 release notes](https://github.com/VDA5050/VDA5050/releases/tag/3.0.0){rel="&#x22;nofollow&#x22;"} link a [table of every rename](https://github.com/VDA5050/VDA5050/pull/465){rel="&#x22;nofollow&#x22;"}, so check that before you port a 2.x integration.

If your vehicle ships with 3.0 support, swap the names. The topic structure and the ideas below stay the same.

### What a state message looks like

```json
{
  "headerId": 42,
  "timestamp": "2026-08-10T09:15:00.000Z",
  "version": "2.1.0",
  "manufacturer": "AcmeRobotics",
  "serialNumber": "AGV-042",
  "orderId": "order-1001",
  "orderUpdateId": 0,
  "lastNodeId": "node7",
  "lastNodeSequenceId": 6,
  "nodeStates": [
    { "nodeId": "node8", "sequenceId": 8, "released": true }
  ],
  "edgeStates": [
    { "edgeId": "node7-8", "sequenceId": 7, "released": true }
  ],
  "agvPosition": {
    "x": 12.4,
    "y": 3.1,
    "theta": 0.0,
    "mapId": "floor1",
    "positionInitialized": true
  },
  "velocity": { "vx": 0.5, "vy": 0.0, "omega": 0.0 },
  "batteryState": { "batteryCharge": 76.5, "charging": false },
  "driving": true,
  "actionStates": [
    { "actionId": "drop-42", "actionStatus": "WAITING" }
  ],
  "operatingMode": "AUTOMATIC",
  "errors": [],
  "safetyState": { "eStop": "NONE", "fieldViolation": false }
}
```

That vehicle is driving from `node7` to `node8`, with a drop waiting at the end of it. Three things to know before you write code against this.

**Some fields are always there.** `orderId`, `orderUpdateId`, `lastNodeId`, `lastNodeSequenceId`, `nodeStates`, `edgeStates`, `driving`, `actionStates`, `batteryState`, `operatingMode`, `errors`, and `safetyState` are required. An idle vehicle sends empty `nodeStates` and `edgeStates` arrays. It does not drop the fields.

**Position is not, but read the exception carefully.** `agvPosition` and `velocity` are optional. The standard only lets a vehicle omit `agvPosition` if it cannot localize itself at all, such as a line-guided AGV. A vehicle that can localize but hasn't finished yet still sends the field, with `positionInitialized` set to `false`.

So master control needs two checks, not one. Confirm `agvPosition` is there, then confirm `positionInitialized` is `true` before you trust the numbers. Code like `msg.payload.agvPosition.x` crashes on a line-guided vehicle. Code that skips the second check will route a truck using coordinates the truck itself doesn't stand behind.

**Watch the [timestamp](https://flowfuse.com/blog/2026/07/time-synchronization-edge-devices/) precision.** 2.x writes `timestamp` with hundredths of a second, while JavaScript's `toISOString()` gives you milliseconds. Vehicles accept it in practice, and 3.0 moves to milliseconds officially, but a strict schema validator flags it.

The standard ships [JSON schemas](https://github.com/VDA5050/VDA5050/tree/main/json_schemas){rel="&#x22;nofollow&#x22;"} for all six topics. Point a validator at them and you can check a payload before you send it, rather than finding out from the vehicle.

## Build it

### What you need

- A running FlowFuse instance on your edge device. If you do not have an account, [sign up for a free trial](https://app.flowfuse.com/account/create){rel="&#x22;nofollow&#x22;"} and set up your instance following the instructions in this [guide](https://flowfuse.com/docs/device-agent/quickstart/).
- An MQTT broker your AGVs (or an AGV simulator) already publish to, or FlowFuse's [built-in team broker](https://flowfuse.com/docs/user/teambroker/) if you're prototyping. If you're still [choosing a broker](https://flowfuse.com/blog/2024/01/unified-namespace-what-broker/), any one with retained messages, last will, and per-client topic permissions will do.
- At least one vehicle or simulator publishing VDA 5050 topics, so you have real messages to work with.

### Step 1: Connect to your broker

1. Drag an **mqtt in** node onto the canvas. Double-click it.
2. Click the pencil icon next to **Server** to add a broker.
3. Enter your broker's host and port. [Use 8883 and tick **Use TLS**](https://flowfuse.com/blog/2024/11/getting-the-most-out-of-mqtt-for-industrial-iot/) on the **Connection** tab. Only use plain port 1883 on an isolated test network.
4. On the same tab, set **Keep alive** to 15 seconds. The standard suggests around that, because the keep alive decides how fast the broker notices a vehicle has vanished. Node-RED defaults to 60, which leaves a dead AGV looking alive for up to a minute and a half.
5. If your broker needs a login, open the **Security** tab and enter the username and password.
6. Leave the topic empty for now. You'll fill it in next.

The [FlowFuse MQTT nodes](https://flowfuse.com/docs/user/mqtt-nodes/) replace steps 2 to 5 if you're pointing at the [FlowFuse broker](https://flowfuse.com/docs/user/teambroker/). They create the client and fill in the credentials themselves.

### Step 2: Subscribe to fleet state

1. In the **mqtt in** node, set **Topic** to `uagv/v2/+/+/state`. Each `+` stands for one topic level. Here they cover manufacturer and serial number, so this one subscription picks up every vehicle.
2. Set **QoS** to 0. VDA 5050 asks for QoS 0 on `order`, `instantActions`, `state`, `factsheet`, and `visualization`, and QoS 1 only on `connection`. Setting a higher QoS on your side doesn't help anyway. MQTT delivers at the lower of the two values.
3. Set **Output** to "a parsed JSON object". You then get a JavaScript object instead of raw bytes. If a vehicle sends broken JSON, the node logs an error and drops the message.
4. Add a **function** node (the one from step 3 below) and a **debug** node after it.
5. Deploy. Check that the **mqtt in** node says "connected", then watch messages arrive in the debug sidebar.

```json
[{"id":"vda-mqtt-in","type":"mqtt in","z":"vda-flow","name":"Fleet state","topic":"uagv/v2/+/+/state","qos":"0","datatype":"json","broker":"vda-broker","nl":false,"rap":true,"rh":0,"inputs":0,"x":210,"y":160,"wires":[["vda-parse"]]},{"id":"vda-parse","type":"function","z":"vda-flow","name":"Identify vehicle","func":"const parts = msg.topic.split('/');\nif (parts.length !== 5) {\n    node.warn('Unexpected VDA 5050 topic: ' + msg.topic);\n    return null;\n}\n\nmsg.manufacturer = parts[2];\nmsg.serialNumber = parts[3];\n\nconst p = msg.payload;\nif (p.manufacturer !== msg.manufacturer || p.serialNumber !== msg.serialNumber) {\n    node.warn('Topic and payload disagree on ' + msg.topic);\n}\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":430,"y":160,"wires":[["vda-debug"]]},{"id":"vda-debug","type":"debug","z":"vda-flow","name":"State debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":650,"y":160,"wires":[]},{"id":"vda-broker","type":"mqtt-broker","name":"VDA 5050 broker","broker":"your-broker.example.com","port":"8883","clientid":"","autoConnect":true,"usetls":true,"verifyservercert":true,"protocolVersion":"4","keepalive":"15","cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"sessionExpiry":""}]
```

Flow exports never include passwords. After importing, open the broker node and enter your own host and login.

### Step 3: Tell the vehicles apart

The `state` message tells you what is happening. You also need to know who sent it.

`manufacturer` and `serialNumber` appear twice: in the payload, and in the topic. Read them from the topic. Here's why.

The topic is the message's address. It is what your broker rules are written against, so it's the right value to route and store by.

Comparing the two is also a free sanity check. If a vehicle's payload disagrees with its topic, it is misconfigured. Better to see that in a log line than to find out when an order goes to the wrong truck.

Put a **function** node between the **mqtt in** node and whatever comes next:

```javascript
const parts = msg.topic.split('/');
if (parts.length !== 5) {
    node.warn('Unexpected VDA 5050 topic: ' + msg.topic);
    return null;
}

msg.manufacturer = parts[2];
msg.serialNumber = parts[3];

const p = msg.payload;
if (p.manufacturer !== msg.manufacturer || p.serialNumber !== msg.serialNumber) {
    node.warn('Topic and payload disagree on ' + msg.topic);
}

return msg;
```

Now `msg.payload` holds the state object, and `msg.manufacturer` and `msg.serialNumber` tell you which AGV sent it.

### Step 4: Catch vehicles going offline

Repeat the same pattern for one more topic, pointing it at the broker you already set up.

Subscribe to &#x2A;*`uagv/v2/+/+/connection`** at QoS 1. This tells you when a vehicle drops off the broker. The payload has a `connectionState` field with one of three values in 2.x:

- `ONLINE`
- `OFFLINE` for a clean, deliberate disconnect
- `CONNECTIONBROKEN` for an unexpected drop

The vehicle registers that last value as its MQTT last will when it connects. So if it vanishes without saying goodbye, the broker publishes it for the vehicle. Vehicles publish every `connection` message with the retained flag set, so a new subscriber picks up each vehicle's last known status straight away.

This is where the keep alive from step 1 earns its place. The broker only fires the last will once the heartbeat lapses, so a 60-second keep alive can hide a dead vehicle for well over a minute.

One warning. `connection` is a network check, not a health check. Version 3.0 states that outright in its topic table, and 2.1 works the same way without saying it as plainly. It tells you the link dropped. It tells you nothing about a vehicle that is still connected but faulted, stuck, or lost. For that, watch `errors`, `operatingMode`, and `safetyState` in `state`. Also treat any `state` message older than 30 seconds as stale, since that is the longest gap the standard allows.

### Putting it on a screen

None of this is visible to anyone on the floor yet. You can build a screen from these same flows with [FlowFuse Dashboard](https://flowfuse.com/docs/user/dashboards/), [without writing any HTML](https://flowfuse.com/blog/2024/03/dashboard-getting-started/): a table of vehicles with battery level and current order, an alert when a vehicle drops off the network, and a live map of where everything is.

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

### Step 5: Send an order

Three rules decide whether the vehicle accepts your order at all. Get these wrong and it refuses.

**The first node must be where the vehicle already is.** The standard says the AGV has to be standing on the first node, or inside its deviation range. Send an order that starts anywhere else and the vehicle rejects it. A rejected order shows up as a `validationError` warning in the vehicle's `state`, and the warning stays there until it accepts a valid order. Read `lastNodeId` and `agvPosition` from the vehicle's current state, and build the order from there.

**`orderId` and `orderUpdateId` together must be new.** Use a fresh `orderId` for each job. Start `orderUpdateId` at 0, and only raise it when you extend that same order. A 2.x vehicle checks the incoming `orderUpdateId` against the one it already holds, treating a lower one as deprecated and an equal one as already received. Version 3.0 draws the line more precisely: resending an identical message is fine, but reusing an `orderUpdateId` with different content is an error.

**The vehicle must support the actions you send.** `pick` and `drop` are standard action types, but supporting them is optional. Ask for the vehicle's `factsheet` first, using the `factsheetRequest` instant action, and check its list of supported actions.

Then wire it up:

1. Add an **mqtt out** node pointing at your broker. Leave **Topic** empty so the flow can set `msg.topic` per vehicle. Leave **Retain** off. The broker re-delivers a retained order every time the vehicle reconnects, which is how you move a truck at 3am by accident.
2. Feed it a payload matching the order schema: a `nodes` array and an `edges` array.
3. Trigger it with a dashboard button for manual dispatch, or from an [**http in** endpoint](https://flowfuse.com/blog/2022/12/create-http-trigger-with-authentication/) if orders come from your WMS.

Here is a real pick-and-drop order:

```javascript
const manufacturer = 'AcmeRobotics';
const serialNumber = 'AGV-042';

msg.topic = `uagv/v2/${manufacturer}/${serialNumber}/order`;

// headerId counts per topic, so key the counter by topic and raise it
// by one for every message you send to that topic
const headerKey = `headerId:${msg.topic}`;
const headerId = (flow.get(headerKey) || 0) + 1;
flow.set(headerKey, headerId);

msg.payload = {
  headerId,
  timestamp: new Date().toISOString(),
  version: "2.1.0",
  manufacturer,
  serialNumber,
  orderId: `order-${Date.now()}`,
  orderUpdateId: 0,
  nodes: [
    {
      // The AGV must already be at this node, or within its deviation range
      nodeId: "station-1",
      sequenceId: 0,
      released: true,
      nodePosition: { x: 0, y: 0, mapId: "floor1" },
      actions: [{
        actionId: `pick-${headerId}`,
        actionType: "pick",
        blockingType: "HARD",
        actionParameters: [
          { key: "stationType", value: "floor" },
          { key: "loadType", value: "EPAL" }
        ]
      }]
    },
    {
      nodeId: "station-2",
      sequenceId: 2,
      released: true,
      nodePosition: { x: 12, y: 4, mapId: "floor1" },
      actions: [{
        actionId: `drop-${headerId}`,
        actionType: "drop",
        blockingType: "HARD",
        actionParameters: [
          { key: "stationType", value: "floor" },
          { key: "loadType", value: "EPAL" }
        ]
      }]
    }
  ],
  edges: [{
    edgeId: "station-1-2",
    sequenceId: 1,
    startNodeId: "station-1",
    endNodeId: "station-2",
    released: true,
    actions: []
  }]
};
return msg;
```

Set `version` to the version your vehicle actually runs. Its `factsheet` and its own `state` messages both tell you.

Note the counter keyed by topic. `headerId` is defined per topic and rises by one per message, so a single shared counter across two vehicles leaves gaps in both their sequences.

Four more details matter. `sequenceId` counts across nodes and edges together, which is why the edge is `1`, sitting between nodes `0` and `2`. `released: true` marks the base, the part of the plan the vehicle should run now, as opposed to the horizon, which is work it knows about but hasn't been told to start. And `actionId` has to be unique, because that is how the vehicle reports progress back to you in `actionStates`.

`blockingType` is the one worth reading twice. It decides whether the vehicle can drive, and whether other actions can run at the same time. `HARD` means the action runs alone, with no driving and no other actions. `SOFT` allows other actions but still stops the vehicle. `NONE` allows both. For a pick or drop you want `HARD`, and note that `SOFT` does not let the AGV keep driving, which is the one people get backwards. Version 3.0 adds a fourth, `SINGLE`, which allows driving but no other actions.

```json
[{"id":"vda-order-trigger","type":"inject","z":"vda-flow","name":"Dispatch order","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":210,"y":320,"wires":[["vda-order-build"]]},{"id":"vda-order-build","type":"function","z":"vda-flow","name":"Build order payload","func":"const manufacturer = 'AcmeRobotics';\nconst serialNumber = 'AGV-042';\n\nmsg.topic = `uagv/v2/${manufacturer}/${serialNumber}/order`;\n\n// headerId counts per topic, so key the counter by topic\nconst headerKey = `headerId:${msg.topic}`;\nconst headerId = (flow.get(headerKey) || 0) + 1;\nflow.set(headerKey, headerId);\n\nmsg.payload = {\n  headerId,\n  timestamp: new Date().toISOString(),\n  version: \"2.1.0\",\n  manufacturer,\n  serialNumber,\n  orderId: `order-${Date.now()}`,\n  orderUpdateId: 0,\n  nodes: [\n    { nodeId: \"station-1\", sequenceId: 0, released: true, nodePosition: { x: 0, y: 0, mapId: \"floor1\" }, actions: [{ actionId: `pick-${headerId}`, actionType: \"pick\", blockingType: \"HARD\", actionParameters: [{ key: \"stationType\", value: \"floor\" }, { key: \"loadType\", value: \"EPAL\" }] }] },\n    { nodeId: \"station-2\", sequenceId: 2, released: true, nodePosition: { x: 12, y: 4, mapId: \"floor1\" }, actions: [{ actionId: `drop-${headerId}`, actionType: \"drop\", blockingType: \"HARD\", actionParameters: [{ key: \"stationType\", value: \"floor\" }, { key: \"loadType\", value: \"EPAL\" }] }] }\n  ],\n  edges: [\n    { edgeId: \"station-1-2\", sequenceId: 1, startNodeId: \"station-1\", endNodeId: \"station-2\", released: true, actions: [] }\n  ]\n};\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":440,"y":320,"wires":[["vda-order-out"]]},{"id":"vda-order-out","type":"mqtt out","z":"vda-flow","name":"Send order","topic":"","qos":"0","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"vda-broker","x":680,"y":320,"wires":[]},{"id":"vda-broker","type":"mqtt-broker","name":"VDA 5050 broker","broker":"your-broker.example.com","port":"8883","clientid":"","autoConnect":true,"usetls":true,"verifyservercert":true,"protocolVersion":"4","keepalive":"15","cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"sessionExpiry":""}]
```

This snippet brings its own broker node so it imports on its own. If you paste it into the same tab as the flow from step 2, you'll end up with two. Point this flow at the one you already set up and delete the spare, or the two clients will fight over the same login.

The **inject** node keeps the import simple. Swap it for a **ui-button** once your dashboard exists.

## Before this touches real AGVs

A flow that works on a test rig is not a production system. Check these first.

- **Lock down the broker.** Restrict each AGV to its own topic path. Give the wildcard subscription to master control only. Use an allowlist, not a blocklist.
- **[Use TLS.](https://flowfuse.com/blog/2023/04/securing-node-red-in-production/)** Factory networks are shared. Fleet commands should not travel in clear text, and leave certificate checking on.
- **Never retain `order` or `instantActions`.** The broker replays retained commands to every vehicle that reconnects. `connection` and `factsheet` are the two topics that *should* be retained.
- **Match the standard's QoS levels.** QoS 0 for `order`, `instantActions`, `state`, `factsheet`, and `visualization`. QoS 1 for `connection`. If your site does something different, change it on both ends, since MQTT delivers at the lower of the two.
- **Set the keep alive to around 15 seconds.** It sets the floor on how fast you can detect a vehicle dropping off, so a long keep alive quietly undoes your offline alerting.
- **Watch state freshness, not just `connection`.** A vehicle can hold its connection open while stuck or faulted. Alert on `errors`, on `operatingMode` leaving `AUTOMATIC`, and on `state` messages older than 30 seconds.
- **[Validate orders before you send them.](https://flowfuse.com/blog/2025/11/industrial-data-validation-guide/)** Check the first node against the vehicle's current position, keep `orderId` and `orderUpdateId` unique, and check every action type against the factsheet.
- **Cap message size on the broker** to what VDA 5050 payloads actually need. It limits the damage a misbehaving client can do.

## What's next

You now have the basics: subscribe to fleet state, tell vehicles apart, spot vehicles going offline, and send orders. That's enough for a pilot with two or three AGVs.

The next thing most teams do is replace the button with [the WMS or ERP](https://flowfuse.com/blog/2025/06/connect-shop-floor-to-odoo-erp-flowfuse/), so orders arrive from whatever already decides what needs moving. After that comes order updates and cancellation, because a job that can't be extended or pulled back mid-route is not much use on a real floor. Both of those need the vehicle's `factsheet`, so it's worth requesting and storing it early. Master control can then check load capacity, size, and supported actions before it dispatches anything.

Two bigger pieces usually wait until the pilot has proved itself. [Logging state history](https://flowfuse.com/blog/2026/02/mqtt-influxdb-tutorial/) gives you throughput and utilization numbers, which is normally what makes the case for expanding. Publishing that state into a [Unified Namespace](https://flowfuse.com/blog/2024/11/building-uns-with-flowfuse/) puts it alongside the rest of your production data, so the systems that plan the work can see where the vehicles are. Traffic rules come last, and only once vehicles from different vendors start sharing aisles, because that is the point where a single master control system stops being a convenience and starts being the reason the floor works at all.

When the pilot becomes a deployment, FlowFuse adds the parts a real fleet system needs: remote device management for edge gateways, [snapshots and instant rollback](https://flowfuse.com/blog/2024/09/node-red-version-control-with-snapshots/), audit logs, [DevOps Pipelines](https://flowfuse.com/blog/2024/10/how-to-build-automate-devops-pipelines-node-red-deployments/), [team access control](https://flowfuse.com/blog/2024/04/role-based-access-control-rbac-for-node-red-with-flowfuse/), and high availability.


# Layered Process Audit (LPA): A Practical Guide + Checklist

Most plants discover process problems after the parts are made. A defect appears at final inspection, a customer reports an issue, and the plant begins sorting, rework, and investigation. So how do you catch those problems while the line is still running? This guide shows you how, using a Layered Process Audit. It includes a checklist template you can take straight to the shop floor.

A Layered Process Audit works earlier than that. Supervisors, engineers, and managers check the process while production is running and while they are standing at the workstation. These short, regular audits help catch problems before defects are produced, reinforce standard work, and keep communication active between shifts and departments.

This guide explains what an LPA is, how manufacturers use it, how to run one, and includes a practical checklist you can use on the shop floor.

## Layered Process Audit (LPA): Definition and Meaning

A Layered Process Audit (LPA) is a structured manufacturing audit used to verify that a process is being performed according to the defined standard. The audit focuses on how the work is done, not on inspecting finished parts.

In practice, an LPA is performed at the workstation. The auditor observes the operation, asks a small set of standard questions, and records whether each requirement is being followed. The same process is checked repeatedly by different levels of management, which is where the term layered comes from.

The layers are organizational levels, not stages of production. A typical program includes:

- **Layer 1:** Supervisor or team leader
- **Layer 2:** Area manager
- **Layer 3:** Plant leadership

All three may audit the same station, but at different frequencies.

A useful way to think about an LPA is as a routine health check for production. Final inspection tells you a part is bad; an LPA is intended to find the missing setup check, incorrect material, bypassed [error-proofing device](https://flowfuse.com/blog/2025/09/poka-yoke-mistake-proofing/), or [out-of-calibration tool](https://flowfuse.com/blog/2026/07/what-is-instrument-calibration/) before bad parts are made.

LPAs are common in [automotive manufacturing](https://flowfuse.com/industries/automotive/) and other industries with strict quality requirements. They do not replace product audits, process audits, or the plant's quality management system; they add a frequent, practical layer of process verification where the work happens.

:cta-image{alt="Power Workplace relies on FlowFuse for scalability, reliability and security audits - book a demo" cta="demo" src="https://flowfuse.com/images/cta/power-workplace-book-demo.png"}

## Why Manufacturers Run LPAs

Historically, LPAs spread through automotive manufacturing on the back of OEM supplier requirements. DaimlerChrysler and General Motors developed the common approach under the Automotive Industry Action Group, which published the first edition of the [CQI-8 Layered Process Audit Guideline](https://www.aiag.org/training-and-resources/manuals/details/CQI-8){rel="&#x22;nofollow&#x22;"} in 2005 and a second edition in 2014. Today those requirements reach suppliers through customer-specific documents from OEMs such as General Motors and Stellantis, and CQI-8 remains the guidance most plants reference.

The purpose is simple: verify that critical process controls are being followed while production is running. Finding a bypassed sensor today is far less expensive than sorting suspect parts weeks later.

LPAs support the intent of [IATF 16949](https://www.iatfglobaloversight.org/){rel="&#x22;nofollow&#x22;"}, but they do not replace the internal, process, or product audits required by the quality management system.

Manufacturers typically use LPAs to reinforce standard work, verify critical process settings, reduce repeat quality problems, improve accountability, and increase management presence on the shop floor.

The value of an LPA comes from consistent observation and quick correction, not from the checklist itself.

## How the Layers Work

The same process is checked by different levels of management at different frequencies. Lower layers audit more often and in greater detail; higher layers audit less often and across a broader area.

The table below is a common starting point rather than a rule. CQI-8 deliberately leaves audit frequency and question topics to each organization, so set yours based on process risk and expect them to change as you learn which stations need more attention.

| Layer   | Typical role             | Typical frequency |
| ------- | ------------------------ | ----------------- |
| Layer 1 | Supervisor / Team leader | Daily             |
| Layer 2 | Area manager             | Weekly            |
| Layer 3 | Plant manager / Director | Monthly           |

![Three layers of a layered process audit showing a supervisor auditing daily, an area manager weekly, and plant leadership monthly, all checking the same station](https://flowfuse.com/blog/2026/08/images/layered-process-audit-level.png)

### Layer 1: Supervisor Audit

The supervisor audits the station or line they manage. The focus is operator practice, standard work, tooling, materials, and immediate process controls. Simple problems are usually corrected immediately.

### Layer 2: Manager Audit

The area manager audits across several lines. In addition to the checklist itself, they verify that Layer 1 audits are being completed and that previous findings have been closed.

### Layer 3: Plant Leadership Audit

Plant leadership audits less often and across a wider scope. The focus is whether the LPA system is functioning: audits completed, repeat issues addressed, and no critical controls quietly abandoned.

A practical rule is: the higher the layer, the wider the scope and the lower the frequency. That overlap creates accountability across the organization.

## How to Run a Layered Process Audit

1. **Select the process.** Start with a high-risk operation such as one with customer complaints, scrap, rework, safety exposure, or critical process parameters. A [Pareto chart](https://flowfuse.com/blog/2025/08/pareto-chart-manufacturing-guide/) is a useful way to identify the stations causing the largest share of defects.
2. **Create the checklist.** Use the [PFMEA](https://www.aiag.org/quality/automotive-core-tools/fmea){rel="&#x22;nofollow&#x22;"}, control plan, work instructions, and recent quality issues. Ten to fifteen objective questions is usually enough.
3. **Define the schedule.** Decide which layer audits each area and how often.
4. **Train the auditors.** Auditors should observe the process, ask factual questions, and record evidence rather than opinions.
5. **Perform the audit at the station.** Watch the operation and record answers while standing at the workstation.
6. **Correct immediate issues.** Fix simple problems during the audit whenever possible.
7. **Assign corrective actions.** Give each finding an owner and a due date.
8. **Verify closure.** Confirm that the action was completed and remains effective during the next audit cycle.

Most LPAs take 5 to 15 minutes. If an audit takes much longer, the checklist is usually too large for a routine layered audit.

Many plants start LPAs with paper checklists or spreadsheets. As the program expands, they often [digitize the same workflow](https://flowfuse.com/#layered-process-audit-software-moving-lpas-off-paper) so audits can be scheduled automatically, findings can trigger alerts, and corrective actions can be tracked across shifts and plants.

## What to Put on the LPA Checklist

An LPA checklist should verify the few process controls that matter most. Keep it short and focused.

Good questions usually come from:

- PFMEA high-risk items
- Control plan checks
- Customer complaints
- Scrap and rework data
- Past audit findings

Write questions so they can be answered *Yes* or *No* by observing the process.

| Avoid                                    | Better question                                                      |
| ---------------------------------------- | -------------------------------------------------------------------- |
| "Is quality good?"                       | "Is the approved work instruction available at the station?"         |
| "Are tools OK?"                          | "Is the torque tool within calibration date?"                        |
| "Is the operator following the process?" | "Is the operator performing step 4 as defined in the standard work?" |

### Example LPA Questions

**Standard work**

- Is the latest work instruction displayed?
- Is the operator following the defined sequence?
- Is the correct revision of the process sheet in use?

**Materials**

- Is the material label correct and readable?
- Is [FIFO](https://en.wikipedia.org/wiki/FIFO_\(computing_and_electronics\)){rel="&#x22;nofollow&#x22;"} being followed?
- Is the approved material being used?

**Tooling and equipment**

- Is the torque tool within calibration date?
- Is the machine parameter within the approved range?
- Is the gauge identified and available at the station?

A calibration date on a checklist is only as good as the record behind it. For what that record should contain and how intervals are set, see [What Is Instrument Calibration (Equipment Calibration)?](https://flowfuse.com/blog/2026/07/what-is-instrument-calibration/); for turning that register into overdue and due-soon status the auditor can check in seconds, see [Tracking Instrument Calibration with a Digital Dashboard](https://flowfuse.com/blog/2026/07/calibration-management-dashboard/).

**Error-proofing**

- Is the poka-yoke device active and not bypassed?
- Does the sensor stop the process when a fault is introduced?

**Traceability**

- Is the batch or serial number recorded correctly?
- Can the current part be traced to its material lot?

A checklist answer of "yes" is only as good as the genealogy behind it. For what that record needs to capture and how forward and backward tracing work during a recall, see [Automotive Traceability: How Manufacturers Track Parts, Processes, and Data](https://flowfuse.com/blog/2026/08/automotive-traceability/).

**Safety and workplace condition**

- Are required PPE items being worn?
- Is the workstation free from oil, scrap, and obstructions?
- Are safety guards in place?

A useful checklist usually fits on one page and can be completed while standing at the station.

The workplace-condition questions overlap with [5S](https://flowfuse.com/blog/2025/09/what-is-5s-checklist/). Keep only the few conditions that affect the process directly and handle broader housekeeping through a separate 5S audit.

## Download the LPA Checklist Template

Download the [one-page Layered Process Audit checklist template](https://drive.google.com/file/d/19plwlUo8vKPunGl7LRF1TMFjqGBZoih4/view?usp=sharing){rel="&#x22;nofollow&#x22;"} and use it on the shop floor as a starting point for your LPA program. The sample questions can be adapted to your own PFMEA, control plan, and process requirements.

## Layered Process Audit Software: Moving LPAs Off Paper

Paper LPAs are easy to start, but they become difficult to manage as the program grows. Finding repeat issues, overdue actions, or missed audits usually means searching through forms or spreadsheets.

A digital LPA keeps the same audit process while making results immediately available. Auditors can complete checklists on a phone or tablet, attach photos, trigger alerts for failed checks, and assign corrective actions from the workstation.

The bigger advantage is connecting LPA results with **production data**. With FlowFuse, audit applications can connect to machines, PLCs, sensors, databases, and other industrial systems. This lets teams compare failed audit checks with downtime, scrap, machine states, or process parameters to understand what was happening on the line.

With [FlowFuse Dashboard](https://flowfuse.com/blog/2024/03/dashboard-getting-started/), plants can build LPA forms, track findings and corrective actions, and visualize audit results alongside production data.

![Process diagram showing the five steps after a failed layered process audit check: audit at the station, check fails, alert sent, action assigned, and closure verified, with the finding re-checked at the next audit](https://flowfuse.com/blog/2026/08/images/pa-escalation-loop.png)

A useful starting point is the [5S Checklist Blueprint](https://flowfuse.com/blueprints/manufacturing/5s-checklist/), which can be adapted for an LPA program by replacing the 5S questions with LPA questions.

## Where LPA Programs Break Down

Most LPA programs do not fail suddenly; they become mechanical.

A common problem is pencil-whipping, where audits are marked complete without anyone visiting the workstation. Another is that higher management layers gradually stop performing their scheduled audits, so the layered system weakens over time.

Plants also struggle with findings that remain open for too long and checklists that are not updated when the process changes.

A healthy LPA program stays short, focused, and regularly reviewed. If audits become long and repetitive, people will eventually rush through them or skip them.

## Measure the Program, Not Just the Audits

Treat the LPA as a managed program, not just a checklist activity. Review it monthly by checking whether each layer completed its audits, how quickly findings were closed, whether the same issue is appearing repeatedly at the same station, and whether corrective actions were documented and verified.

If a finding keeps returning, use a structured method such as a [Five Whys analysis](https://flowfuse.com/blog/2025/12/five-whys-root-cause-analysis-definition-examples/) to investigate the root cause rather than repeating the same corrective action.


# 5 Manufacturing Dashboard Examples for Production, OEE & Quality

A manufacturing dashboard brings machine data, production metrics, downtime, and quality information into one real-time view, so teams can understand what's happening on the shop floor and act on it.

This guide covers what manufacturing dashboards do, the metrics they should track, and five dashboard examples, for production, OEE, downtime, quality, and calibration, built with [FlowFuse](https://flowfuse.com).

## What Is a Manufacturing Dashboard?

A manufacturing dashboard is a visual interface for monitoring production performance in real time. It pulls data from factory equipment and business systems ([PLCs](https://flowfuse.com/blog/2025/12/what-is-plc/), [SCADA](https://flowfuse.com/use-cases/scada/), [MES](https://flowfuse.com/blog/2025/06/what-is-mes/), [ERP](https://flowfuse.com/blog/2025/06/connect-shop-floor-to-odoo-erp-flowfuse/), [databases](https://flowfuse.com/blog/2025/08/getting-started-with-flowfuse-tables/), sensors, or operator input) into a single view built around production output, machine status, downtime, OEE, quality, and targets. FlowFuse's own [Dashboard platform](https://flowfuse.com/platform/dashboard/) is built specifically for assembling these views without writing custom front-end code.

The key difference between a dashboard and a report is timing. A report tells you what happened after the shift ends. A dashboard shows you what's happening now, while there's still time to change the outcome.

That's also what separates a good dashboard from a cluttered one: it doesn't try to show everything. It shows the specific person using it what they need in order to act, which is exactly why dashboards have become so central to how manufacturers run production.

## Why Dashboards Matter in Manufacturing

Production problems get expensive when they stay invisible. A machine that stops, a line falling behind target, or a defect that goes unnoticed can quietly erode throughput, cost, and delivery schedules before anyone catches it.

A shared dashboard closes that gap. Operators see production status as it happens, supervisors track performance across the line, and maintenance teams spot equipment issues sooner. The value isn't the dashboard itself; it's the time saved between a problem occurring and someone responding to it. That's the shift FlowFuse is built to support: turning raw factory data into faster decisions on the floor, whether the source is an MES system or a SCADA historian.

Knowing dashboards matter is one thing. Knowing what belongs on them is another, and that comes down to the metrics behind the view.

## Key Metrics Every Manufacturing Dashboard Should Track

The right KPIs depend on the role and the goal, but most production dashboards center on [four categories: output, equipment performance, downtime, and quality](https://flowfuse.com/blog/2025/06/shop-floor-kpis-for-mes/).

- **Production output:** actual output against the planned target
- **OEE:** equipment effectiveness across availability, performance, and quality
- **Downtime:** lost production time and its biggest contributing causes
- **Cycle time:** whether machines and processes are running at expected speed
- **Quality performance:** defects, scrap, rework, and first-pass yield
- **WIP levels:** where bottlenecks are forming in the production flow

These metrics exist to answer a small set of operational questions: Are we producing at the required rate? Are machines running effectively? Where is time being lost? Are we producing quality parts? If a dashboard can't answer those quickly, it's showing too much, or the wrong things.

What that looks like in practice varies by where the metrics are applied. Here's how these same building blocks show up across five common manufacturing dashboards.

:cta-image{alt="Wenco deploys new dashboard pages in days with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/wenco-book-demo.png"}

## Manufacturing Dashboard Examples

Dashboards work best when they're designed around a specific decision, not a general audience. A production team needs visibility into output and downtime; quality and maintenance teams need a different lens entirely. The five examples below show common patterns, all built with FlowFuse using data from machines, production systems, databases, and industrial protocols, but for using it purpose it uses demo data

### 1. Production Dashboard (Andon Live)

A production dashboard answers one question in real time: is the line hitting its target? FlowFuse's **Andon Live Dashboard** gives operators and supervisors a shop-floor view of actual output against target, shift progress, and current line status, so a gap can be caught and addressed before it grows.

The same live data is useful during a [run at rate](https://flowfuse.com/blog/2026/08/run-at-rate/), when a team needs to verify that the line can sustain its required output before launch.

![FlowFuse Andon Live dashboard showing a target of 100 against an actual count of 84, a delta of 16, stoppage timers, and the current shift for Production Line 33](https://flowfuse.com/blog/2026/08/images/andon-live-dashboard.png)*FlowFuse Andon Live dashboard showing a target of 100 against an actual count of 84, a delta of 16, stoppage timers, and the current shift for Production Line 33*

It typically shows actual production count, target vs. actual output, shift progress, and stoppage information, the same building blocks behind FlowFuse's [Andon Task Manager](https://flowfuse.com/blog/2025/06/building-andon-task-manager-dashboard-with-ff/). Because every production environment is different, FlowFuse connects this same dashboard pattern to whatever data sources are already in place, including PLCs, MES systems, production counters, [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/), and [OPC UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/).

**Ready to deploy:** [Andon Live Dashboard](https://flowfuse.com/blueprints/manufacturing/andon-live/)

### 2. OEE Dashboard

Where a production dashboard tells you whether output is on target, an OEE dashboard explains *why* it isn't. FlowFuse's **OEE Dashboard** combines production and downtime data into one view covering OEE, availability losses, performance losses, quality losses, and trend data over time.

![FlowFuse OEE dashboard with gauges for OEE, performance, availability and quality above a downtime summary, production totals, and a table of underperforming machines](https://flowfuse.com/blog/2026/08/images/oee-dashboard--1-f77f847f.png)*FlowFuse OEE dashboard with gauges for OEE, performance, availability and quality above a downtime summary, production totals, and a table of underperforming machines*

That breakdown matters because a low OEE score can come from very different root causes, frequent stops, slow cycle times, or defect rates, and each one needs a different fix. Separating them lets teams target the actual source of the loss instead of [chasing a misleading number](https://flowfuse.com/blog/2026/05/fixing-oee-measurement-in-manufacturing/).

**Ready to deploy:** [OEE Dashboard](https://flowfuse.com/blueprints/manufacturing/oee-dashboard/)

### 3. Downtime Dashboard

Availability losses are usually the biggest piece of that OEE picture, which is why they tend to warrant a dedicated view of their own. Downtime is the single biggest drain on production capacity, and the real question isn't just *when* machines stop, it's *why*. FlowFuse's **Downtime Tracking Dashboard** captures stop events as they happen and turns them into a live view of downtime duration, causes, and impact on availability, rather than [something pieced together from manual spreadsheets after the fact](https://flowfuse.com/blog/2026/06/event-driven-downtime-escalation-workflow/).

![FlowFuse downtime tracking dashboard listing open stoppages by machine with start times, how long each has been open, and a button to close the event and log a reason](https://flowfuse.com/blog/2026/08/images/downtime-logger.png)*FlowFuse downtime tracking dashboard listing open stoppages by machine with start times, how long each has been open, and a button to close the event and log a reason*

That shift, from reviewing downtime after a shift to tracking it in real time, is what lets teams move from reacting to failures toward reducing what causes them.

**Build it:** [Build a Machine Downtime Tracking Application](https://flowfuse.com/blog/2026/07/build-downtime-logger/)

### 4. Quality Dashboard (Defect & Quality Monitoring)

Quality losses need the same treatment. A quality dashboard shows where defects are happening and what's driving them. FlowFuse's **Defect & Quality Monitoring Dashboard** combines defect data, production information, and quality KPIs, including defect trends, defect categories, first-pass yield, cost of poor quality, and a Pareto breakdown of causes, into one view.

![FlowFuse defect and quality monitoring dashboard with a Pareto chart of defect types, a root cause breakdown, severity and disposition splits, and SLA resolution times](https://flowfuse.com/blog/2026/08/images/flowfuse-defect-monitoring-dashboard.png)*FlowFuse defect and quality monitoring dashboard with a Pareto chart of defect types, a root cause breakdown, severity and disposition splits, and SLA resolution times*

The [Pareto view](https://flowfuse.com/blog/2025/09/creating-pareto-chart/) tends to be the most useful part: it isolates the small number of issues responsible for most of the quality loss, so improvement effort goes where it actually pays off, instead of spreading thin across every defect type. Pairing it with [statistical process control](https://flowfuse.com/blog/2025/07/quality-control-automation-spc-charts/) catches quality drift before it produces a defect at all.

**Build it:** [Build a Defect Tracking and Quality Monitoring Dashboard](https://flowfuse.com/blog/2026/07/defect-and-quality-monitoring/)

### 5. Calibration Dashboard

Defects aren't always caused by the process itself; sometimes the measurement equipment used to catch them is the problem. Where measurement accuracy affects product quality and compliance, [instrument calibration](https://flowfuse.com/blog/2026/07/what-is-instrument-calibration/) tracking can't run on spreadsheets. FlowFuse's **Calibration Management Dashboard** gives teams a live view of measurement equipment status (what's ready, what's due, what's overdue) along with calibration history and compliance status, cutting the risk of equipment running outside its required window.

![FlowFuse calibration management dashboard showing 120 instruments split into valid, due soon and overdue, a 73.3% compliance rate, and a table of overdue tools by department](https://flowfuse.com/blog/2026/08/images/calibration-management-dashboard.png)*FlowFuse calibration management dashboard showing 120 instruments split into valid, due soon and overdue, a 73.3% compliance rate, and a table of overdue tools by department*

**Build it:** [Tracking Instrument Calibration with a Digital Dashboard](https://flowfuse.com/blog/2026/07/calibration-management-dashboard/)

## Manufacturing Dashboard Design Best Practices

Having the right dashboard type for the job is only half the equation. How it's designed determines whether anyone actually uses it. A manufacturing dashboard should make decisions easier, not add more information to review, and the best dashboards are designed around the people using them and the actions they need to take.

Key principles include:

- **Design for the user:** operators, supervisors, and managers need different views based on their responsibilities
- **Focus on actionable metrics:** every KPI should help identify a problem, measure progress, or support a decision
- **Keep important information visible:** production status, downtime, and quality issues should be clear without searching through multiple screens
- **Avoid unnecessary complexity:** too many charts and metrics make important information harder to find
- **Support drill-downs:** start with a clear overview, then allow users to investigate the details behind an issue

A successful manufacturing dashboard is not the one with the most data. It is the one that helps the right person understand the situation and act quickly.

One design decision worth calling out on its own is timing: not every dashboard should show the same moment in time.

## Real-Time vs. Historical Manufacturing Dashboards

Not every manufacturing decision requires the same type of dashboard:

- **Real-time dashboards** are built for immediate action, showing what is happening on the shop floor right now, such as current production output, machine status, downtime events, and quality issues
- **Historical dashboards** are [built for analysis](https://flowfuse.com/blog/2025/08/time-series-dashboard-flowfuse-postgresql/), helping teams identify trends, compare performance over time, and understand recurring problems

Manufacturers often need both. Real-time dashboards keep production running today, while historical dashboards help improve how production runs tomorrow.

Timing is one axis a dashboard can vary on. Who it's built for is another, and that's a separate design decision entirely.

## Single Source of Truth vs. User-Specific Dashboards

Manufacturing dashboards can follow two common [design patterns](https://dashboard.flowfuse.com/getting-started#design-patterns){rel="&#x22;nofollow&#x22;"} depending on how they are used.

A **single source of truth dashboard** gives everyone the same operational view. This works well for Andon boards, production displays, and OEE dashboards, where teams need a shared understanding of factory performance.

![Single source of truth pattern: a device populates both a ui-chart and a database, and the chart displays the same dashboard to all clients](https://flowfuse.com/blog/2026/08/images/design-pattern-single.png)*Single source of truth pattern: a device populates both a ui-chart and a database, and the chart displays the same dashboard to all clients*

A **user-specific dashboard** provides different information based on the user's role or workflow. Operators, for example, may see production status and tasks, while maintenance teams see equipment issues and service information. This pattern relies on the dashboard knowing who's looking at it, which is what FlowFuse's [multi-user addon](https://flows.nodered.org/node/@flowfuse/node-red-dashboard-2-user-addon){rel="&#x22;nofollow&#x22;"} is built to support.

![User-specific pattern: opening the dashboard fires a ui-event that queries the database using the viewer's client ID, so the chart displays data for that user only](https://flowfuse.com/blog/2026/08/images/design-pattern-multi-user.png)*User-specific pattern: opening the dashboard fires a ui-event that queries the database using the viewer's client ID, so the chart displays data for that user only*

The right approach depends on the decision the dashboard needs to support. Some manufacturing applications use one shared view; others combine shared visibility with role-specific information. Either way, someone has to actually connect the underlying data and build the thing, which is where FlowFuse comes in.

## Building Manufacturing Dashboards with FlowFuse

The challenge in manufacturing is rarely a lack of data. Most factories already generate information from machines, PLCs, sensors, and business systems. The real challenge is connecting that data and turning it into something teams can use, whether that's a single shared view or a set of role-specific ones.

FlowFuse helps manufacturers build operational dashboards by connecting industrial data sources, processing production information, and creating applications for the shop floor. A typical workflow includes:

- **Connect data:** bring in data from PLCs, machines, databases, and protocols such as MQTT, OPC UA, and [Modbus](https://flowfuse.com/blog/2023/05/integrating-modbus-with-node-red/)
- **Process data:** convert production events, downtime, and quality records into useful metrics
- **Build dashboards:** create views for operators, supervisors, and managers

Once a dashboard is built, teams can manage and deploy it across multiple lines, or facilities without rebuilding it from scratch, to keep every deployment in sync. The goal is simple: turn factory data into [reusable applications that improve operational visibility](https://flowfuse.com/platform/features/).

## Conclusion

Manufacturing dashboards give teams a shared view of what is happening on the shop floor. They help operators respond faster, supervisors understand performance, and engineers identify opportunities for improvement.

From production tracking and OEE monitoring to downtime analysis, quality management, and calibration control, the right dashboard connects operational data with the decisions teams need to make, whether that decision needs a real-time or historical view, a shared display or a role-specific one.

The goal is not to create more screens. It is to create better visibility into production and give teams the information they need to keep improving. With [FlowFuse](https://flowfuse.com/platform/why-flowfuse/), manufacturers can connect existing factory data, build operational applications, and scale successful dashboards across machines, lines, and facilities.


# Run at Rate: Proving Production Capacity Before Launch

*Run at rate is a timed production run, performed at the actual target cycle time with production tooling and production staffing, meant to confirm a line can hold both quality and output over a real shift, not just a handful of closely watched parts.*

The distinction matters because process validation alone doesn't prove it. A supplier can pass validation with every checked part coming back within spec, launch, and still miss its shift target three weeks in, at which point it's a customer problem instead of an engineering one. Run at rate is the check meant to catch that before launch happens, not after.

:cta-image{alt="Need to prove production capacity before launch?" cta="demo" src="https://flowfuse.com/blog/2026/08/images/run-at-rate-cta2.png"}

## Where the requirement comes from

General Motors formalized the requirement in its [GM Global APQP Supplier Quality Manual (GM 1927)](https://www.scribd.com/document/572952029/GM-1927-35-Run-at-Rate-Procedure-Rev-2-EG){rel="&#x22;nofollow&#x22;"}, performed after PPAP approval as confirmation of the rate claimed on the supplier's warrant. Ford builds it into the PPAP submission itself, through the capacity evaluation section of the official [AIAG Production Part Approval Process (PPAP) Manual](https://www.aiag.org/training-and-resources/manuals){rel="&#x22;nofollow&#x22;"}. Stellantis standardizes its version via the [Stellantis Supplier Portal](https://www.google.com/search?q=https://www.supplier.stellantis.com){rel="&#x22;nofollow&#x22;"} Capacity Assessment Tool (CAT) framework. German OEMs execute a two-day trial called 2 Tagesproduktion (2TP), governed by the [VDA QMC Volume 2 PPA Standard](https://webshop.vda.de/qmc/volume-2-ppa){rel="&#x22;nofollow&#x22;"}.

The paperwork varies by customer. The question underneath it doesn't: can this line, with this tooling and these operators, actually produce at the rate that was quoted.

## Requirements for a valid run

A few conditions have to hold.

The setup has to match real production, not a demo. Production tooling, production gauges, trained operators, standard work as documented. Auditors specifically watch for stand-ins, an engineer hovering over a fixture, hand-picked material, extra staff who wouldn't be on the floor during a normal shift. Any of that and the result doesn't count.

The run has to cover enough time to mean something. A line can hold [takt time](https://flowfuse.com/blog/2025/09/what-is-takt-time/) for twenty minutes and still drift once fixtures heat up and operators settle into a real pace instead of a rehearsed one. That's why most programs require a full shift or a defined multi-hour window rather than a short burst at rate.

And everything counts against the result, not just the good parts. [Downtime](https://flowfuse.com/blog/2026/07/build-downtime-logger/), changeovers, scrap, and rework all subtract from the demonstrated rate.

## How to calculate run at rate

The math only needs two numbers: what the line was supposed to produce, and what it actually produced as good parts.

**Theoretical output** = run duration ÷ target cycle time

**Run at rate %** = (net good output ÷ theoretical output) × 100

Take an 8-hour shift, or 480 minutes, against a 60-second target cycle time. The theoretical output for that window is 480 units.

![Run at rate calculation diagram showing theoretical output, good parts produced, and resulting percentage](https://flowfuse.com/blog/2026/08/images/run-at-rate-calculation-image.png)

During the run, 45 minutes are lost to downtime, leaving 435 minutes of actual production time. At the target cycle time, the line produces 435 units, but 12 are scrapped, leaving 423 good parts.

**Run at rate = (423 ÷ 480) × 100 = 88.1%**

Downtime and scrap don't get calculated separately and added back in. They show up as fewer good parts against the theoretical output, which is why a line can be running most of the shift and still post a rate well under target..

:cta-image{alt="Tracking run-at-rate data manually?" cta="sign-up" src="https://flowfuse.com/blog/2026/08/images/run-at-rate-cta-1.png"}

## What Does Pass or Fail Look Like?

The customer or program team sets the required run-at-rate threshold before the test, based on the production capacity that was quoted or required. The threshold varies by customer and program, so 95% is an example rather than a universal requirement.

If the agreed threshold is 95%, a result of 95% or higher passes. In the example above, the line achieved &#x2A;*88.1%**, so it fails to demonstrate the required capacity. That restarts the clock rather than ending the program: trace the shortfall to downtime, scrap, or cycle drift, fix it, and run again. Until a run passes, the quoted capacity stays unproven, and launch approval waits with it.

**Pass:** ≥ required threshold :br&#x2A;*Fail:** < required threshold

## Run at rate vs. process validation vs. PPAP

Process validation confirms a process can hold tolerance, usually at reduced volume with an engineer watching each unit come off the line. That's a different test than holding tolerance for 400 consecutive cycles at full speed with nobody intervening, which is what runs at rate checks.

PPAP is the larger documentation package: control plans, measurement system analysis, part approval as a whole. Run at rate is one piece of that package, specific to volume. It isn't a substitute for the rest of the file, and the rest of the file isn't a substitute for it.

![Comparison diagram showing PPAP components and where run at rate fits within the approval process](https://flowfuse.com/blog/2026/08/images/pap-vs-run-rate.png)

## Why capacity gaps still show up after launch

Changeover time gets estimated instead of measured live, and the real changeover, with new operators and no rehearsal, runs longer than planned. A station that tested fine on its own turns out to be the actual bottleneck once the full line runs together, starved for parts or backed up behind a slower neighbor. [Quality](https://flowfuse.com/blog/2026/07/defect-and-quality-monitoring) that looked stable during a short trial drifts once tooling wears across a full shift, a failure mode a short run wouldn't catch.

Some of the challenge comes down to how run-at-rate data is collected. During a live run, cycle times, downtime, production counts, and rejects are often recorded manually, making it difficult to capture every event accurately. Much of this data is already available from the equipment through [PLC](https://flowfuse.com/landing/plc/) tags and machine states. A platform like [FlowFuse](https://flowfuse.com) can connect to that equipment to automatically collect the data, calculate the demonstrated production rate, and visualize the results as the run progresses, giving teams a clearer view of how the line is performing against its target.

## Why it matters

Process validation proves a line can make a good part. Run at rate proves it can make good parts fast enough, for long enough, to hit the number in the launch plan. With production data collected directly from your equipment, FlowFuse helps [automotive manufacturers](https://flowfuse.com/industries/automotive/) monitor production counts, cycle time, downtime, and quality in real time, making capacity gaps visible before they become launch problems.


# What Is Statistical Process Control in Manufacturing

A quality engineer flags a batch of parts three shifts after the process drifted. By then, the scrap is already built. The operational logic that drives throughput and quality still lives in custom code, isolated scripts, and one-off solutions, so problems often surface in a quality report long after they could have been caught.

FlowFuse is an industrial application platform that works with manufacturers who face this daily. Bosch, Cargill, Moderna, Worthington Steel, and 25+ other enterprise manufacturers use FlowFuse to build and standardize operational applications across sites, including the real-time monitoring that makes statistical process control practical at scale. Customers have documented a 50% reduction in scrap rate, and the platform is SOC 2 Type 1 and Type 2 certified.

This article covers what statistical process control is, how SPC charts and control charts work, how SPC applies across manufacturing sites, and where Six Sigma SPC and SPC software fit in.

![SPC control chart with a table of measurements](https://flowfuse.com/blog/2026/08/images/spc-chart-data-analysis-close-up.png)*SPC control chart with a table of measurements*

## How Statistical Process Control Works: SPC Charts And Control Charts Explained

Statistical process control is a method for monitoring a manufacturing process using data collected while it runs, rather than waiting to inspect the finished product. It works by plotting measurements from the process, such as part dimensions, temperature, or pressure, onto a control chart over time. That chart includes a center line at the process average and upper and lower control limits placed three sigma either side of it, derived from the short-term variation within the process itself rather than from a fixed specification. Control limits and specification limits are not the same thing: a process can run entirely inside its control limits and still make parts outside spec, which is why an SPC signal means the process changed, not that a given part is bad.

:cta-image{alt="Arch Systems scales automation across complex manufacturing environments with FlowFuse - book a demo" cta="demo" src="https://flowfuse.com/images/cta/arch-systems-book-demo.png"}

The right control chart depends on how the data is collected. X-bar R and X-bar S charts are built from sample subgroups, small batches of readings pulled close together in time, and plot the subgroup average alongside its range (R) or standard deviation (S). When it isn't practical to pull parts into subgroups, an I-MR chart plots individual readings and the moving range between consecutive points instead. Picking the chart that matches how the data is actually collected is one of the more common places SPC implementations go wrong.

SPC charts make it possible to see the difference between common cause variation, which is expected and should not be adjusted for point by point, and special cause variation, which signals something has changed and needs investigation. A single point falling outside the control limits is one signal to intervene, but a non-random pattern building up over several points, such as a run drifting steadily in one direction or a cluster of points hugging one side of the center line, is also a signal. Quality teams formalize these checks using the Western Electric Rules or Nelson Rules, which pair the out-of-limit test with additional tests for runs, trends, and points clustering in the outer bands of the chart. Most of those tests fire on a sequence of points that are each individually inside the limits, which is why charts running these rules divide the space into one and two sigma bands rather than just plotting the outer limits. This is the core discipline behind statistical process control: catching drift while it is still correctable, not after a batch has already failed inspection.

Building and reading control charts by hand across dozens of machines and lines is slow and does not scale well across multiple sites. For a deeper look at how these charts are typically built and interpreted in practice, see [Statistical Process Control (SPC): Benefits and Implementation Guide](https://flowfuse.com/blog/2025/07/quality-control-automation-spc-charts/).

![Manufacturing quality dashboard showing an SPC chart for bearing diameter and process capability metrics.](https://flowfuse.com/blog/2026/08/images/manufacturing-quality-dashboard-spc-chart.png)&#x2A;Manufacturing quality dashboard showing an SPC chart for bearing diameter and process capability metrics.*

## SPC In Manufacturing: Turning Shop Floor Data Into Process Control

Statistical process control only works if it has a steady stream of accurate data from the process it is monitoring. In most plants, that data lives across [PLCs](https://flowfuse.com/blog/2025/12/what-is-plc/), sensors, [MES systems](https://flowfuse.com/blog/2025/06/what-is-mes/), and manual entry points that were never designed to talk to each other. Getting SPC to work at scale depends on solving that connectivity problem.

### Where SPC Data Actually Comes From

Process data for SPC charts typically comes from PLCs, edge devices, and sensors tracking variables like temperature, torque, or dimensional tolerances. Pulling that data into a usable chart requires IT/OT connectivity that moves it securely from the shop floor to wherever it is analyzed, without brittle point-to-point integrations that break every time equipment changes. FlowFuse provides that layer. It reads from PLCs, sensors, and MES over OPC UA, MQTT, or Modbus, so the chart updates from live process data rather than from manual entry.

### Deploying SPC Across Multiple Sites Without Rebuilding

What works on one line will not scale to fifty unless the underlying logic can be standardized. FlowFuse customers deploy SPC monitoring using a build once, run everywhere approach, standardizing a proven workflow on one machine and rolling it out across 20+ manufacturing sites from a single platform, without rebuilding it at each new location.

### Working With Brownfield Systems Instead Of Replacing Them

Most plants run a mix of legacy PLCs, older MES installations, and newer edge hardware. Rather than requiring a full system replacement, SPC monitoring can extend a brownfield environment as-is. This staged approach avoids the all-or-nothing rollout risk described in [All-or-Nothing Manufacturing Software Is Killing Your Agility](https://flowfuse.com/blog/2026/05/manufacturing-software-built-in-stages/).

## Six Sigma SPC And Modern SPC Software: Choosing The Right Tools

Statistical process control does not exist in isolation. It works alongside broader quality methodologies and depends on the right software to make the data usable at scale. Choosing how SPC fits into your quality program and which tools support it are two separate decisions that shape how much value you get from the practice.

### SPC's Role In Six Sigma Methodology

Six Sigma SPC refers to using control charts within the Six Sigma framework, particularly during the Control phase of DMAIC. The chart provides the ongoing measurement that shows whether an improvement is holding, rather than a one-time check to declare the project complete.

### What To Look For In SPC Software

SPC software should connect directly to the data sources already on your shop floor rather than requiring manual data entry. Look for real-time monitoring, support for brownfield environments with existing PLCs and MES systems, and a way to deploy the same setup across multiple sites without reconfiguring it at each one. FlowFuse covers all three: connect the measurement over [OPC UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/), [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/), or [Modbus](https://flowfuse.com/blog/2025/09/using-modbus-with-flowfuse/), chart it with calculated limits and alerts on a dashboard at the line, then roll that same setup out everywhere else.

### SPC Alongside Other Root Cause Tools

Control charts show you when a process has drifted, but they do not always explain why. Pairing SPC with other root cause analysis tools helps close that gap. For a breakdown of one commonly used tool for identifying the biggest contributors to a quality issue, see [Pareto Chart & Diagram for Manufacturing](https://flowfuse.com/blog/2025/08/pareto-chart-manufacturing-guide/).

## Final Thoughts

Statistical process control gives manufacturers a way to catch problems while they are still cheap to fix, but only if the underlying data actually reaches the people and systems that need it. That is often the harder part. Most plants already have the sensors and PLCs generating the right signals; what is missing is a reliable way to move that data from the shop floor into a usable chart, consistently, across every line and every site.

This is where an industrial application platform like FlowFuse fits. It connects the equipment, and your team builds the chart and the alerts on top of that data by dragging nodes, not writing code. It runs on the line, and you deploy the same setup at the next plant instead of rebuilding it. For manufacturers managing quality across dozens of sites, that difference determines whether SPC becomes a routine part of operations or another initiative that never quite scales past the pilot line.

## Sources

- American Society for Quality (ASQ). ["What Is Statistical Process Control? SPC Quality Tools."](https://asq.org/quality-resources/statistical-process-control){rel="&#x22;nofollow&#x22;"}
- American Society for Quality (ASQ). ["Understanding Variation."](https://asq.org/quality-progress/articles/understanding-variation?id=3415f81b6f9444c4a30e6bb03aff7903){rel="&#x22;nofollow&#x22;"}
- American Society for Quality (ASQ). ["Control Chart – Statistical Process Control Charts."](https://asq.org/quality-resources/control-chart){rel="&#x22;nofollow&#x22;"}
- International Organization for Standardization. ["ISO 7870-2:2023 — Control Charts, Part 2: Shewhart Control Charts."](https://www.iso.org/standard/78859.html){rel="&#x22;nofollow&#x22;"}
- NIST/SEMATECH e-Handbook of Statistical Methods. ["Shewhart X-bar and R and S Control Charts."](https://www.itl.nist.gov/div898/handbook/pmc/section3/pmc321.htm){rel="&#x22;nofollow&#x22;"}
- NIST/SEMATECH e-Handbook of Statistical Methods. ["Individuals Control Charts."](https://www.itl.nist.gov/div898/handbook/pmc/section3/pmc312.htm){rel="&#x22;nofollow&#x22;"}


# What Is SCADA? Supervisory Control and Data Acquisition

A production line goes down and the first alarm appears on a screen minutes before anyone on the floor notices. For teams managing multiple plants, that screen is often the only real-time view into what is happening across PLCs, sensors, and equipment scattered across dozens of sites. Understanding what SCADA is matters more than ever, especially with unplanned downtime costing industrial manufacturers an estimated [$50 billion](https://www.eng.auburn.edu/~szm0001/papers/GC23-technology.pdf){rel="&#x22;nofollow&#x22;"} a year.

FlowFuse, an industrial application platform, works directly inside the environments where SCADA systems operate, connecting to PLCs, sensors, and edge devices as part of building operational applications across plants and production lines. The platform is SOC 2 Type 1 and Type 2 certified and is trusted by manufacturers including Bosch, Cargill, Moderna, and 25 or more other enterprise customers to standardize workflows across hundreds of sites without rebuilding from scratch.

This article breaks down what SCADA is, how it works, how it compares to related systems like PLCs and HMIs, and why it still matters in brownfield environments today.

:cta-image{alt="Extend your SCADA, don't replace it — connect to a PLC over OPC UA or Modbus and build a view on top" cta="sign-up" src="https://flowfuse.com/blog/2026/08/images/scada-article-cta.png"}

## How Does SCADA Work? The Core Components

SCADA, which stands for Supervisory Control and Data Acquisition, is a system that collects data from equipment across a plant and gives operators a centralized view to monitor and control that equipment in real time. A simple definition covers what the system does, while the SCADA meaning points to its core function beyond just the acronym, supervising and gathering data across distributed equipment. Any basic SCADA system definition includes four layers working together: field devices, controllers, communication networks, and the software that displays and stores the data. Each of these layers works together as follows:

![SCADA architecture diagram showing sensors and manual inputs feeding data to PLCs or RTUs, which pass it to server infrastructure, connected over a LAN or WAN network to an HMI or SCADA operator view.](https://flowfuse.com/blog/2026/08/images/scada-basic-diagram.png)&#x2A;The four layers of a SCADA system: field devices, controllers, communication networks, and the software operators use to monitor and control equipment.*

### Field Devices And Sensors

Sensors and field devices sit closest to the physical process, measuring variables like temperature, pressure, flow rate, and machine status. These devices generate the raw data that everything else in the system depends on. Without accurate field-level data, supervisory dashboards and historical trends built on top of a [SCADA](https://flowfuse.com/use-cases/scada/) system lose their value almost immediately.

### PLCs And RTUs

Programmable Logic Controllers and Remote Terminal Units take the raw signals from field devices and convert them into structured data. PLCs typically run more complex local control logic and keep equipment operating safely between supervisory updates, while RTUs are more common in geographically spread-out environments, like pipelines or remote wellheads, where they focus more on data acquisition and communication over long distances. Most industrial environments rely on PLCs as the layer directly beneath SCADA, translating physical inputs into a format the rest of the system can use.

### Communication Networks

Communication networks carry data between field devices, controllers, and the central SCADA software, using protocols like [Modbus](https://flowfuse.com/node-red/protocol/modbus/), [OPC UA](https://flowfuse.com/blog/2025/07/reading-and-writing-plc-data-using-opc-ua), [MQTT](https://flowfuse.com/blog/2024/06/how-to-use-mqtt-in-node-red/), or [Ethernet/IP](https://flowfuse.com/blog/2025/10/using-ethernet-ip-with-flowfuse/) depending on the equipment and environment. This layer determines how reliably and securely data moves across a facility, and it becomes especially important when connecting older equipment to newer IT/OT platforms.

### HMI And Central Monitoring Software

The Human-Machine Interface, or HMI, is where operators view live data, alarms, and trends pulled from PLCs and RTUs. Central SCADA software aggregates this information across multiple lines or sites, storing historical data for reporting and analysis. This layer is what turns raw signals into the visibility manufacturers depend on to catch problems early.

## SCADA vs. PLC, HMI, And MES: Where It Fits In The Stack

Anyone asking what is SCADA usually runs into overlapping terminology almost immediately, since PLCs, HMIs, and MES platforms all touch the same data at different points. Each system serves a distinct purpose, and confusing them leads to gaps in coverage or duplicated effort across sites. Getting the distinctions right matters for anyone responsible for architecture decisions across multiple plants:

### SCADA vs. PLC

A PLC executes control logic directly on the equipment it is connected to, reacting to inputs in real time without needing a central system. SCADA, by contrast, supervises multiple PLCs at once, pulling their data into a single view for monitoring and historical analysis, and sending supervisory commands like setpoint changes back down to the equipment. For a full breakdown of how PLCs function on their own, see [What Is PLC](https://flowfuse.com/blog/2025/12/what-is-plc/).

### SCADA vs. HMI

An HMI is the interface operators interact with directly, usually tied to a single machine or line. SCADA software aggregates data from many HMIs and PLCs across a facility or multiple sites, giving a broader operational picture than any single interface can provide. Guidance on setting up interfaces at the equipment level is covered in [Building HMI for Equipment Control](https://flowfuse.com/blog/2025/11/building-hmi-for-equipment-control/).

### SCADA vs. MES

MES platforms manage production scheduling, quality records, and traceability at a business process level, while SCADA focuses on real-time equipment data and control. These systems are meant to work together, not replace each other, though many manufacturers still rely on tools like [Kepware](https://flowfuse.com/vs/kepware/) to bridge the gap between SCADA data and [MES](https://flowfuse.com/blog/2025/06/what-is-mes/) or [ERP](https://flowfuse.com/blog/2025/06/connect-shop-floor-to-odoo-erp-flowfuse/) systems. This is a core part of what SCADA is often used for in practice.

## Why SCADA Still Matters In Modern Brownfield Environments

SCADA systems are not going anywhere in most industrial facilities, and understanding why requires looking at how much infrastructure is built around them. Many plants run SCADA installations that are ten or twenty years old, tied directly to equipment that still works fine and would be expensive or risky to replace. Ripping out a functioning brownfield environment rarely makes sense when the goal is better visibility, not a full overhaul.

The real challenge is connecting older SCADA systems to newer IT and OT tools without breaking what already works. Protocol choice plays a large role here, and manufacturers evaluating how to move data between legacy equipment and modern platforms often need SCADA explained in the context of specific protocols like OPC UA and MQTT. The comparison in [OPCUA vs MQTT](https://flowfuse.com/blog/2026/01/opcua-vs-mqtt/) covers how each protocol handles that kind of connectivity differently.

![Diagram showing a SCADA chain of field devices, PLCs or RTUs, server infrastructure, and an HMI or SCADA view, with a FlowFuse IT/OT connectivity and application layer exchanging data with the PLC and server tiers and feeding FlowFuse operational applications and MES, ERP, or cloud systems.](https://flowfuse.com/blog/2026/08/images/scada-flowfuse-extension.png)&#x2A;Extending a brownfield SCADA system with an IT/OT layer rather than replacing it.*

Extending a brownfield SCADA system, rather than replacing it, lets manufacturers keep proven equipment logic in place while adding the [IT/OT connectivity](https://flowfuse.com/use-cases/it-ot-middleware/) needed for enterprise-wide visibility. That approach protects existing investment and reduces the operational risk that comes with large-scale system replacement.

## Final Thoughts

SCADA remains one of the most important systems on any plant floor, giving operators and engineers the visibility needed to catch issues before they turn into costly downtime. Knowing how the pieces fit together, from field devices up through PLCs, HMIs, and central monitoring software, makes it easier to spot where gaps exist and where legacy equipment can be extended rather than replaced.

For manufacturers managing SCADA across multiple sites, the harder problem is often not the system itself but everything built around it: custom scripts, one-off integrations, and workflows that get rebuilt at every new plant. An industrial application platform like FlowFuse addresses that layer directly, letting teams take a proven operational workflow and deploy it across every site instead of starting over each time. Build once, run everywhere is not just a convenience. It is what breaks the rebuild cycle for good.


# Custom Node Support

An often requested feature is support for custom nodes. Although Node-RED instances today connect automatically to the official Node-RED catalogue, which boasts over 4,400 custom nodes, we understand that specific use cases may require access to additional or different NPM registries and catalogues.

Starting today, you can extend your Node-RED environment by adding custom Node Catalogues. We have introduced the capability to modify the .npmrc file, allowing you to install modules that are not hosted in the official registry.

![Settings Custom Node Support](https://flowfuse.com/changelog/2023/09/images/custom-node-support.png)


# DevOps Pipeline with action selection

Starting today, you can configure a deployment stage to create a new snapshot, always copy the latest snapshot, or prompt you for an action. This provides a more flexible approach to managing snapshots, enabling you to directly push created snapshots through the pipeline rather than being limited to the current image on Node-RED instances.

![Action selection DevOps pipelines](https://flowfuse.com/changelog/2023/09/images/select-action.png)


# Introducing the Enterprise Tier

:product-update-note

We are excited to officially announce the implementation and introduction of our new Enterprise Tier. Starting today, all FlowFuse Cloud customers have the option to upgrade their tier directly through **Team Settings** -> **Danger** -> **Change Team Type**. For those who self-host FlowFuse, the differentiation between the Enterprise and Teams Tiers is now available as well, via license type.

Comprehensive details about the features included in each tier can be found on our [pricing page](https://flowfuse.com/pricing/).


# API Endpoint for DevOps Pipeline

The execution of DevOps Pipelines is now an official API endpoint. Therefore, automation and integration, for example via Node-RED, are now possible. For more details, see our [API Documentation](https://flowfuse.com/docs/api/).


# Usability improvements to Device Management

Four weeks ago, we began working on several [usability improvements to our Device Management](https://flowfuse.com/blog/2023/08/flowfuse-1-11-release/#usability-improvements-to-device-management-2294). This included the ability to associate devices at the application level, allowing for easier editing of Node-RED instances on edge devices.

Starting today, it will also be possible to create and manage snapshots for those standalone devices.

![Menu Snapshots for Devices](https://flowfuse.com/changelog/2023/09/images/snapshots-devices.png)


# Blueprints

FlowFuse Blueprints are now available on FlowFuse Cloud and, upon request, for Teams and Enterprise Self-Hosted customers. Blueprints simplify Node-RED deployments by offering pre-built, customizable flows for specific use cases, thereby accelerating both new user onboarding and solution development for our seasoned users.

[Click here](https://flowfuse.com/blog/2023/10/blueprints/) to learn more about Blueprints.

When creating a new instance, you can now also select a Blueprint.

![Blueprint Screenshot](https://flowfuse.com/changelog/2023/10/images/Screenshot-Blueprints.png)


# Certified Nodes

:product-update-note

Teams Tier customers can now leverage a curated selection of certfied Node-RED nodes, enhancing workflow efficiency and security.

- Quality Assurance: Each certified node undergoes testing, ensuring it's free from harmful components, aligning with our commitment to reliability.
- Proactive Security Measures: While prioritizing immediate resolutions for detected vulnerabilities, we maintain the discretion to revoke a node's certified status, ensuring system integrity. Affected customers will receive prompt notifications.
- Support: Assistance for certified nodes is provided, aiming for, but not promising, issue resolution.

How? You can find all certified nodes in your Node-RED palette manager or on the
[dedicated page](https://flowfuse.com/integrations/?certified=1) on our website.

![Certified Nodes Screenshot](https://flowfuse.com/changelog/2023/10/images/certified-nodes.png)


# Enhanced Snapshot Selection

Users can now effortlessly deploy snapshots for devices assigned to an application through a new "Deploy Snapshot" button, available in the device's "snapshots" tab, thereby enhancing the workflow with the option to set either instance-owned or device-owned snapshots as the target.

![Snapshot selection](https://flowfuse.com/changelog/2023/10/images/Snapshot-Selection.png)


# Device Agent path bug fix

The Device Agent now passes the PATH environment variable to the Node-RED instances. Erroneously, the agent didn't capture it to expose to Node-RED again for usage. This prevented some nodes from being installed, like `node-red-serial-port` when assigned to an application.


# Resource Monitoring in Audit Log

In the FlowFuse Audit Log (see [Documentation](https://flowfuse.com/docs/user/logs/#audit-log))of an instance, it will now display when the resource utilization of CPU or memory exceeds 75% over a period of five minutes. This should provide transparency regarding resource utilization and serve as an indicator for choosing the appropriate instance size.

![Audit Log Screenshot](https://flowfuse.com/changelog/2023/10/images/Screenshot-alert.png)


# Two-Factor Authentication

In our ongoing commitment to strengthen security, we're excited to announce the addition of two-factor authentication (2FA) for FlowFuse. This enhancement ensures an extra layer of security for your account. Setting up 2FA is straightforward, and the system supports all commonly used TOTP (Time-Based One-Time Password) tools, such as Google Authenticator. To enable 2FA, simply navigate to your User Settings and follow the easy setup process.

![Config 2FA](https://flowfuse.com/changelog/2023/11/images/2fa.png)

For more Details see our [Documentation](https://flowfuse.com/docs/user/user-settings/)
2FA is available for all FlowFuse Cloud users and for Enterprise Self-Hosted customers.


# Device Editor enabled by default

With the latest update, devices operating in `Developer Mode` will now have the `Open Editor` feature enabled by default. This enhancement is designed to improve the User Experience.


# Devices in DevOps Pipelines

:product-update-note

Building on our [previous release](https://flowfuse.com/blog/2023/08/flowfuse-1-11-release/#usability-improvements-to-device-management-2294) that enabled the management of devices independently of instances. Now, the integration of individual devices into DevOps Pipelines is possible. This update marks a significant step towards more flexible and efficient device management within FlowFuse. In our ongoing efforts, we are also developing features to group devices, aiming to streamline and improve the overall device management experience.

![Devices in DevOps Pipelines](https://flowfuse.com/changelog/2023/11/images/devices-in-pipelines.png)

Devices in DevOps Pipelines are available for every customer who has access to DevOps Pipelines. This includes all Cloud customers and those from the Pro Tier onwards for our self-hosted version.


# Project Nodes for Devices

From today onwards, Project Nodes will now be available for devices assigned to an application. Previously, it was necessary for devices to be bound to an instance to utilize this functionality.

- [Learn more about the Project nodes](https://flowfuse.com/docs/user/projectnodes/#flowfuse-project-nodes)
- [learn more about the difference between Instances, Devices, and Applications.](https://flowfuse.com/docs/user/concepts/#application)


# No Credit Card required for billing

We now have more flexible billing options in FlowFuse Cloud for customers that wish to purchase an annual subscription or where entering credit card details is not appropriate. We're committed to accommodating your specific billing preferences and can set up a process that aligns with your organizational needs.

If you are interested in this new option or have any questions, please don't hesitate to [contact us](https://flowfuse.com/contact-us/). We're here to help you with your billing and subscription needs.


# Blueprint Selection Update

We have updated the blueprint selection interface to enhance the user experience by offering a clearer and more comprehensive overview. This improvement aims to facilitate easier navigation and selection of blueprints. Additionally, we are excited to announce that our blueprint library will be expanding in the coming days, with the addition of new blueprints to FlowFuse.

!["FlowFuse Blueprint Selection"](https://flowfuse.com/changelog/2023/12/images/blueprints-selection.png "FlowFuse Blueprint Selection")

For more detailed information about our blueprints and how to utilize them effectively, please refer to our dedicated [article](https://flowfuse.com/blog/2023/10/blueprints/).


# Device Groups

We are pleased to announce the introduction of Device Groups for Enterprise Tier customers. This new feature enables users to logically group their devices assigned to an application. Additionally, Device Groups can be integrated into the DevOps Pipeline. This integration facilitates more streamlined and efficient deployments across your fleet of devices.

![](https://flowfuse.com/changelog/2023/12/images/device-groups.png)![](https://flowfuse.com/changelog/2023/12/images/device-group-pipeline.png)


# Email Alerts for Audit Log Events

:product-update-note

The newly introduced feature offers email notifications tied to particular Audit log events, available to all users with Pro Tier access or higher. This feature is designed to facilitate immediate notification and action in response to Node-RED Instance crashes. For detailed information and guidance on this functionality, please refer to our [documentation](https://flowfuse.com/docs/user/instance-settings/#alerts).

![](https://flowfuse.com/changelog/2023/12/images/alerts.png)


# Node-RED 3.1.3 now available

With Node-RED 3.1.3 being released this week, we've updated our stacks to ensure it's available to everyone in FlowFuse Cloud. We have also made it the default version you'll get when creating new instances.

If you want to update your existing instances to this new stack you can follow the [guide here](https://flowfuse.com/docs/user/changestack/).

For more information about the changes in Node-RED 3.1.3, check the [release's changelog](https://github.com/node-red/node-red/blob/7fd0ecf721fc78e8415dca3106bc71b461e6554d/CHANGELOG.md){rel="&#x22;nofollow&#x22;"}.


# Introducing the Device Auditlog Feature

The introduction of the Device Auditlog brings an enhanced level of monitoring and tracking for device-related activities, available to all FlowFuse users.

Events Recorded in the Device Auditlog:

- Fleet mode / Developer mode enabled/disabled
- Remote access enabled/disabled
- Credentials re-generated
- Device assigned

![Device Audit log](https://flowfuse.com/changelog/2024/01/images/Device-Auditlog.png)


# Device Groups - Automatic snapshot assignment

Four weeks ago, we launched the [Device Groups](https://flowfuse.com/changelog/2023/12/device-groups/) feature, for our Enterprise customers. This innovation marked a significant step in simplifying device management within DevOps Pipelines. Now we enhacent the Device Groups functionality.

With this update, the behavior of Device Groups has been refined to further streamline your workflow. Now, whenever a Snapshot is assigned to a Device Group, any newly added devices to that group will automatically receive the update. This ensures that all devices within the group are consistently synchronized with the latest changes, eliminating the need for manual updates. This improvement not only saves time but also enhances the consistency and reliability of device management across your fleet.


# Renaming "Default Device Mode" to "Fleet Mode"

In our continuous effort to enhance user experience and clarity, we are pleased to announce an update to our device mode terminology. Previously known as "Default Device" mode, we have now rebranded it as "Fleet Mode." This change aims to establish a clearer distinction from "Developer Mode," thereby streamlining the understanding of operational modes for our devices.

- **Fleet Mode**: Runs any target Snapshots defined. Blocks remote editing of device.
- **Developer Mode**: Blocks any new Target Snapshots running, but allows for remote editing on the Device.


# Helm Chart v2.0

The v2.0 release of the FlowFuse Helm Chart includes a breaking change for deployments making use of the `forge.localPostgresql` setting when upgrading. This is where the helm chart installs a dedicated PostgreSQL database instance.

With v2.0 we have updated the version of the Bitnami PostgreSQL Helm sub-chart we bundle and the upgrade process will require some manual intervention to ensure things work correctly. A fresh install should not require any extra steps.

The steps are documented on the [Upgrade instructions](https://flowfuse.com/docs/install/kubernetes/#upgrade) page, please read them carefully before upgrading

Also included in this release is the ability to set resource constraints and Pod Security Context on the FlowFuse application, File-Server Application and MQTT broker containers if required. Details of how to set those can be found in the Helm Chart [README.md](https://github.com/FlowFuse/helm/tree/main/helm/flowforge#readme){rel="&#x22;nofollow&#x22;"}


# New Blueprints added

We have added some new blueprints to FlowFuse Cloud to help users get started with a range of common manufacturing scenarios.

They are available to all users on FlowFuse Cloud. Additionally, upon request, all our Teams and Enterprise Self-Hosted customers gain access to this collection.

List of new Blueprints:

- [Andon Live](https://flowfuse.com/blueprints/manufacturing/andon-live/)
- [CRUD for Mongo DB](https://flowfuse.com/blueprints/getting-started/crud/)
- [5S Manufacturing checklist](https://flowfuse.com/blueprints/manufacturing/5s-checklist/)
- [Performance Operator Terminal](https://flowfuse.com/blueprints/manufacturing/performance-overview/)

Curious about what Blueprints are? Read our recent blog post that [introduced Blueprints to FlowFuse](https://flowfuse.com/blog/2023/10/blueprints/).

For an overview of all available Blueprints check out our [Blueprint Library](https://flowfuse.com/blueprints/).


# Security Updates

As part of our dedication to providing a secure platform for our customers, we
operate a [Bug Bounty programme](https://flowfuse.com/handbook/engineering/security/)
to encourage responsible disclosure of potential issues.

With all disclosures we evaluate their severity in terms of their direct impact,
the nature of the issue and overall risk.

We have received a number of reports recently that we have been evaluating. Whilst
none of the recent disclosures has been deemed high severity, we have applied a number
of updates to the platform.

These include:

- Tougher rate limiting on routes that manage user information including email addresses
- Better handling of the password-reset flow to prevent stale links being reused
- Avoiding disclosure of a user's email address to other members of a team

This last item is one I wanted to say a bit more about. As you would expect, a
user's email address is sensitive information that we do not disclose to unauthorised
users. However, we also consider a Team as having a higher level of trust between its
members. On review, we have decided there is not a technical reason for this higher
level of trust to include a member's email address, so we have removed it from
the relevant API responses.

We value the effort people put into making responsible disclosures to us and look
to reward the work where it meets our criteria.

Find out more about our [Bug Bounty programme](https://flowfuse.com/handbook/engineering/security/).


# Managing Team Membership via SSO

For organizations using Single Sign-On with FlowFuse, we have now added the ability
to manage their user's team memberships and roles via their Identity Provider.

This makes it easier to control access to the FlowFuse Platform from providers such
as Okta and Microsoft Entra. For example, you can create a group of Team Owners
and a separate group of Team Viewers.

Whenever a user logs in via SSO, the platform will update their roles to match
the groups they are in.

More information on configuring groups can be found in [our Single Sign-on](https://flowfuse.com/docs/admin/sso/)
documentation.

This feature is available to Enterprise Tier teams on FlowFuse Cloud, as well as
self-hosted Enterprise instances.


# Streamlined Device assignment

To start editing flows on a device, it needs to be assigned to an application
in your team. Up until now this has been a two step process; creating the device
and then assigning it. This wasn't as intuitive as it needed to be.

To help streamline the user experience, you can now assign a device to an application
when you create it. It's a small update, but it helps users get to where they want
to be much quicker.

![](https://flowfuse.com/changelog/2024/01/images/device-assignment.png)


# Device Auto Snapshots

FlowFuse V2.1 introduces Auto Snapshots for your Application Assigned Devices.

When you deploy a change to the device flows, a snapshot will be taken automatically.

The last 10 Auto Snapshots will be kept on a first in first out basis. Older Auto Snapshots will be automatically cleaned up for you.

![](https://flowfuse.com/changelog/2024/02/images/Device-auto-snapshot1.png)

![](https://flowfuse.com/changelog/2024/02/images/Device-auto-snapshot2.png)

Click the following links to learn more about [devices](https://flowfuse.com/docs/device-agent/) and [snapshots](https://flowfuse.com/docs/user/snapshots/#snapshots).


# Device Instance Audit Logging

With the recent introduction of the Device audit log, we've now updated the Device Agent to start logging events from the Node-RED instance running on your device.

This brings closer parity with the logging you get from a hosted instance.

The audit log events include details of the flows being updated, nodes being added or removed from the palette and other changes to the configuration.

Update to Device Agent v2.2 to start receiving the events.

![Device Audit log](https://flowfuse.com/changelog/2024/02/images/device-auditlog.png)


# Device Onboarding Improvements

Hot on the heals of our recent onboarding improvements and streamlining, we
have now introduced a new, simpler and faster way of getting your devices
configured and connected to the FlowFuse platform.

Now, when you create a device on the platform, you will be offered a simple
"Setup command". Run this command in a terminal and the let the Device
Agent do all the hard work for you.

![](https://flowfuse.com/changelog/2024/02/images/device-onboarding-improvements-1.png)

![](https://flowfuse.com/changelog/2024/02/images/device-onboarding-improvements-2.png)

To learn more about this, head to the [FlowFuse Device Agent](https://flowfuse.com/docs/device-agent/) documentation.


# Pricing change for Devices

:product-update-note

Starting today, we have introduced a simplification of the pricing structure for devices on FlowFuse Cloud, effective immediately. All information is available on our [pricing page](https://flowfuse.com/pricing/).
The new pricing scheme is as follows:

- Starter Tier: No change
- Teams Tier: Devices are now priced at $25 each.
- Enterprise Tier: Devices are priced at $50 each.

We are also pleased to offer volume discounts. For more details, please [contact us](https://flowfuse.com/contact-us/).

## Important Note for Existing Teams

If a team currently in either tier already has devices (or has had devices in the past), any additions or removals of devices will be billed according to the previous pricing structure.
For teams without any prior device history, the addition of devices will be billed at the new rates.


# Instance Auto Snapshots

Two weeks ago, we introduced [auto snapshots for devices](https://flowfuse.com/changelog/2024/02/device-auto-snapshot/) to help ensure you can always rollback to a previous version of your Node-RED flows. We're extended that ability to the hosted Node-RED instances as well.

Whenever you deploy a change to the flows, a snapshot will be taken automatically. We'll keep the last 10 auto-generated snapshots on a first-in, first-out basis. Older auto-generated snapshots will be automatically cleaned up for you - unless
they are marked as a target snapshot for your devices.

Click the following links to learn more about [instances](https://flowfuse.com/docs/user/concepts/#instance) and [snapshots](https://flowfuse.com/docs/user/snapshots/#snapshots).


# PostgreSQL Version update

Included in the v2.1.0 release the Helm Chart now uses `14.10.0-debian-11-r30` tag of the Bitnami PostgreSQL container.

This container tag includes images for both AMD64 and ARM64 allowing FlowFuse to be deployed to now fully ARM64 based Kubernetes clusters when using local PostgreSQL database.


# Bearer Token Authentication for Node-RED Instances

Bearer Token Authentication for Node-RED Instances, allows FlowFuse users to securely access their Node-RED HTTP endpoints, ensuring enhanced security and ease of implementation. Now, you can confidently manage your HTTP endpoints with the assurance that your connections are protected using FlowFuse's robust authentication mechanism.

![Screenshot Instance Setting Bearer Token](https://flowfuse.com/changelog/2024/03/images/bearer-token-authentication.png)

![Screenshot of New Bearer Token](https://flowfuse.com/changelog/2024/03/images/bearer-token-exampe.png)

```bash
$ curl -H "Authorization: Bearer ffhttp_FKc_S4qlTBV1H411hmhneHcSJ6F_FGNQLPYbnoD3-B0" https://healthy-rook-4329.flowforge.cloud/test
HelloWorld
$
```

This feature is available for our Teams and Enterprise Tier customers. You can find the configuration under the Security tab in your instance settings.


# Instance Protection Mode

We're excited to announce the introduction of the Instance Protection Mode, an enhancement in our efforts to provide a secure and controlled environment for managing production instances on FlowFuse. This feature empowers Team Owners with the exclusive ability to restrict modifications to production instances, ensuring that any changes are made with careful oversight and authorization.

A key aspect of Instance Protection Mode is the exclusive control it grants Owners over the execution of DevOps pipelines targeting protected instances. This means: Only Owners can initiate and execute pipelines.

The Instance Protection option can be found under the Instance settings view for all our Teams and Enterprise Tier customers.


# Configure HTTP Payload and Debug Message size

We've introduced new configuration options to enhance the control of your HTTP requests and debugging process. These updates allow you to configure limits on the sizes of incoming HTTP messages and how many characters of a message are included in debug messages in the editor sidebar.

This feature is available to all our Teams and Enterprise Tier customers. You can access these new configuration options in the Instance Settings under the "Editor" menu.

![Screenshot Settings](https://flowfuse.com/changelog/2024/03/images/limits-payload-debug.png)


# Remote Device Restart

The latest version of the FlowFuse device agent now supports remotely restarting your Node-RED flows from the FlowFuse platform. This brings it more inline with what the platform lets you do with your hosted Node-RED instances.

This removes the need to manually connect to your device to restart Node-RED, streamlining your workflow and offering a more seamless and efficient user experience.

![Remote Device Restart](https://flowfuse.com/changelog/2024/03/images/restart-devices-remotly.png)


# Custom Nodes Support on Devices

We have supported the ability to configure your Node-RED instances with [custom node catalogues](https://flowfuse.com/changelog/2023/09/custom-node-support/) for some time now. This feature allows you to access alternative NPM registries to use nodes that have not been made publicly available.

We have now extended this to work with your Node-RED devices, giving them the same ability to access private node catalogues, and deploy them across your fleet of devices.

![Custom Node Catalog Support for Devices](https://flowfuse.com/changelog/2024/04/images/device-npmrc-config.png)

Custom Node Catalog Support for Devices


# Direct Dashboard Access

We have added quick access buttons to help you navigate to your Dashboard 2.0 UI in a single click.

![](https://flowfuse.com/changelog/2024/04/images/Dashboard-Link.png)&#x2A;Dashboard button is displayed alongside the Open Editor button when an instance has `@flowfuse/node-red-dashboard` installed.*

Click the link to learn more about [Flowfuse Dashboard 2.0](https://dashboard.flowfuse.com/){rel="&#x22;nofollow&#x22;"}


# Improving Device Groups

Device Groups make it really simple to deploy a snapshot across multiple devices using our Pipelines feature.
When the pipeline stage is triggered, you can watch as the snapshot is rolled out across all of target devices.

We've updated the Device Group view to include more information about what snapshot is currently deployed to the group, and the deployment status of individual devices in the group.

![Summary details of all Device Groups in an application](https://flowfuse.com/changelog/2024/04/images/device-group-summary.png)

Summary details of all Device Groups in an application

![Details of all devices within a Device Group](https://flowfuse.com/changelog/2024/04/images/device-group-details.png)

Details of all devices within a Device Group


# Pricing change Enterprise & Teams Tier

:product-update-note

We're updating our pricing model for the Enterprise and Teams tiers on FlowFuse Cloud, with changes taking effect immediately. All information is available on our [pricing page](https://flowfuse.com/pricing/).

The new pricing scheme is as follows:

- Starter Tier: Remains unchanged
- Teams Tier: Availability limited to Small [[]{.katex-mathml}[[[]{.strut style="height:0.6944em;"}[25]{.mord}[an]{.mord.mathnormal}[d]{.mord.mathnormal}[M]{.mord.mathnormal style="margin-right:0.109em;"}[e]{.mord.mathnormal}[d]{.mord.mathnormal}[i]{.mord.mathnormal}[u]{.mord.mathnormal}[m]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 50 Instances
- Enterprise Tier: Availability limited to Medium [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"}[50]{.mord}[an]{.mord.mathnormal}[d]{.mord.mathnormal}[L]{.mord.mathnormal}[a]{.mord.mathnormal}[r]{.mord.mathnormal style="margin-right:0.0278em;"}[g]{.mord.mathnormal style="margin-right:0.0359em;"}[e]{.mord.mathnormal}]{.base}]{.katex-html ariaHidden="true"}]{.katex} 250 Instances

We are also pleased to offer volume discounts. For more details, please [contact us](https://flowfuse.com/contact-us/).

## Important Note for Existing Teams

Teams that are currently subscribed to any tier and are using Instances will continue to be billed according to the previous pricing structure. Customers who have separate contracts with us will not be affected by these changes.


# Tougher Rate Limiting on Public Routes

Running any service on the internet requires constant vigilence on security issues. One feature
we've had in place for some time on FlowFuse Cloud is rate-limiting on our API. This limits how
often someone can repeatedly call the API within a certain time frame.

We want to make sure we deter any misbehaviour, without getting in the way of genuine access.

For example, it would be entirely legitimate for a customer to use our [API]() and automate some tasks via script. These API calls would arrive faster than if they were manually clicking around the FlowFuse UI, but that doesn't mean they should be restricted.

We also look to areas of the API that could be misused - for example, anything that can trigger an email to be sent, such as the "I forgot my password" API.

Tuning the rate-limiting is a continual process, and in that spirit we've recently made the rate limiting on certain routes to be much tougher and improved the feedback in the UI just in case a legitimate user accidentally hits it.

The tougher limits act as a better deterent, which in turn makes the platform more secure.


# Customizing instance health-check settings

When running Node-RED within FlowFuse, the platform actively monitors the instances
to make sure they are running smoothly and automatically restarts them if it detects
a problem. It does this by regularly polling Node-RED to make sure it is still responsive.

This provides protection for the case where a user's flows accidentally creates a tight
loop in its code and locks up the runtime.

We have to do this with care; it is entirely possible that a user's flows are intentionally
doing some hard work that causes our health check to temporarily fail. For that reason,
we only restart Node-RED if it fails a number of health-check polls in a row.

But even with that in place, there are still edge cases where a user's flows need to
do some *really* hard work that can exceed what the default health-check polling is
configured to handle.

We have now added the ability to customize how often we check the instance health. By default
this is done every 7.5 seconds, but can now be extended via the instance settings.

This will require the instance to be updated to the latest stack to enable the option.

![Health check interval in Instance settings](https://flowfuse.com/changelog/2024/05/images/healthcheck.png)


# Blueprints added to Library

Back in [October 2023](https://flowfuse.com/changelog/2023/10/blueprints/), we introduced Blueprints to help you get started with your new Node-RED applications. We've now made them accessible directly from the Library sidebar, where you can explore the available Blueprints and use them to kick-start your new flows.


# Team Library - Flow Viewer

The Library feature allows you to save and share common functionality and flows across your team on FlowFuse. We've just added the ability to preview any flows saved here, making it easier to understand what they do and explore your collections of flows before importing them into your workspace.

This new feature will better help you maintain and manage your team's shared flows, and give better visibility on flows that your fellow Team members are building.

![Example entry being visualized from the Team Library](https://flowfuse.com/changelog/2024/05/images/library-flowviewer.png)


# Managing Node-RED versions on Devices

We have added the ability to manage the Node-RED version running on application-assigned
Devices within FlowFuse.

Ordinarily, a device will get its Node-RED version from the snapshot deployed to it. However,
for an Application-assigned device, you may not yet have a snapshot to deploy.

The new option, available under Device/Settings/Editor lets you pick what version
of Node-RED the device should use - overriding what is in the active snapshot.

For devices running v2.4.1 or later of the Device Agent, Node-RED will get updated
when the setting is saved. For older versions of the Device Agent, it will require
a new snapshot to be deployed to trigger the update.


# Snapshot Improvements

[Snapshots](https://flowfuse.com/docs/user/snapshots/#snapshots) are a point-in-time backup of Node-RED
that can be used to easily revert back to previous version, or to push out to other
instances and devices as part of our Pipelines feature.

We have lots planned to improve the overall workflow with snapshots, and have a couple
updates to share that are available today.

### Viewing snapshot contents

Following the work done to [enable viewing flows in the Team Library](https://flowfuse.com/changelog/2024/05/library-flowviewer), we've added
the same capability to snapshots.

Each snapshot now has a 'View Snapshot' option that will display the flows without having to open up
the full Node-RED editor.

### Downloading snapshots

We've also added the ability to download snapshots locally - allowing you to take
your own offline backups of your flows.

The 'Download Snapshot' option is currently available on Instance Snapshots, but we'll be rolling
it out to all snapshot types in the near future. We are also working on an Import feature
that will let you upload a snapshot back into the platform.

![Download snapshot](https://flowfuse.com/changelog/2024/05/images/snapshot-download.png)


# Snapshot Upload

[Snapshots](https://flowfuse.com/docs/user/snapshots/#snapshots) are a point-in-time backup of Node-RED
that can be used to easily revert back to previous version, or to push out to other
instances and devices as part of our Pipelines feature.

Following on from the recent work around snapshots to permit [Instance Snapshot Downloads](https://flowfuse.com/changelog/2024/05/snapshot-improvements) and [Snapshot Uploads](https://flowfuse.com/changelog/2024/05/snapshot-upload),
we have now added the ability to download application device snapshots.

This means you can download a snapshot from any device or instance and upload it to any
device or instance on any FlowFuse instance.

Also, to improve access to these actions, we have also updated the application
and device snapshot table items menu to present all relevant snapshot actions.

#### Application Snapshots

![Application Snapshots Table Menu](https://flowfuse.com/changelog/2024/05/images/application-snapshots-menu.png)

#### Instance Snapshots

![Instance Snapshots Table Menu](https://flowfuse.com/changelog/2024/05/images/instance-snapshots-menu.png)

#### Device Snapshots

![Device Snapshots Table Menu](https://flowfuse.com/changelog/2024/05/images/device-snapshots-menu.png)


# Snapshot Upload

[Snapshots](https://flowfuse.com/docs/user/snapshots/#snapshots) are a point-in-time backup of Node-RED
that can be used to easily revert back to previous version, or to push out to other
instances and devices as part of our Pipelines feature.

As promised we have now provided a way for you to upload your locally downloaded snapshots.

![Upload snapshot](https://flowfuse.com/changelog/2024/05/images/snapshot-upload.png)

This means you can now easily take a snapshot and move it between FlowFuse platforms or,
if you prefer, automate it via the APIs it is built on.

We hope you like this nifty little feature.

Stay tuned as we expect the final peices in the overall [Snapshot Improvements](https://flowfuse.com/changelog/2024/05/snapshot-improvements)
to be delivered in the coming days.


# Running the Device Agent behind an HTTP proxy

The FlowFuse Device Agent allows you to manage your Node-RED instances wherever you want them to run.
It connects back to the platform over a secure https connection.

For some enterprise customers, that has posed a challenge as they protect their network with an HTTP proxy that all traffic
has to be directed to.

With the `2.5.0` release of the Device Agent, we now support running the Device Agent behind a proxy - letting it run in even more locations.

Support comes using the industry standard set of `http_proxy` environment variables - familiar to anyone running services behind a proxy.

Full details are available in our [http proxy documentation](https://flowfuse.com/docs/device-agent/running/#running-behind-a-http-proxy).


# Custom hostnames for your instances

Enterprise teams on FlowFuse Cloud can now configure their own subdomain to point
at their Node-RED application.

Within FlowFuse Cloud, Node-RED instances are reached by their provided url: `<name>.flowfuse.cloud`.

With this new option, it is possible to add a custom hostname for the instance that works alongside
the provided url.

For example, if you have built a [dashboard](https://dashboard.flowfuse.com){rel="&#x22;nofollow&#x22;"} you can now configure your instance to make that available via `dashboard.example.com` or any other subdomain you own.

We only support subdomains at this time, but adding support for top-level domains is [on the roadmap](https://github.com/FlowFuse/flowfuse/issues/3982){rel="&#x22;nofollow&#x22;"}.

Read more on [how to setup custom hostnames](https://flowfuse.com/docs/user/custom-hostnames).


# Multi-line Environment Variables

FlowFuse now supports the input of multi-line environment variables for your Node-RED instances running on FlowFuse.

This unlocks the ability to store certs or multi-line values like JSON as environment variables.

We've also improved the `.env` file import to support the use of multi-line values too.

![multiline environment variables](https://flowfuse.com/changelog/2024/06/images/snapshot-compare-flows.png)


# Compare Snapshots flows

We have now added the ability to select a snapshot and compare it to other snapshots making it easier to understand what is in the current snapshot and what has changed in relation to the 2nd snapshot.

Both snapshots are overlayed and you can step through the differences or use the new slider to visualise the differences.

![Selecting a snapshot for comparison](https://flowfuse.com/changelog/2024/06/images/snapshot-compare-kebab-menu.png)

![Comparing selected snapshot with another](https://flowfuse.com/changelog/2024/06/images/snapshot-compare-flows.png)


# Applications Search

With hundreds of devices and instances running in FlowFuse, it can be very difficult to find the resource you're looking for. That's why we've introduced a new search feature that allows you to search across all of your FlowFuse instances, devices and applications from a single place.

![Screenshot showing the new Notifications Inbox in FlowFuse](https://flowfuse.com/changelog/2024/07/images/applications-search.png){dataZoomable=""}*Screenshot showing the new Notifications Inbox in FlowFuse*

The view will automatically filter as you type making it easy to find the resource you're looking for, it will keep reference to any applications and or child instances/devices where appropriate.


# Device Groups Snapshots

An update to let you know you can now clear the target snapshot of a device group. This is small but useful feature that can help you manage your device groups more effectively.

For those unfamiliar with FlowFuse device groups, essentially, they permit you to deploy a snapshot to one or many devices via a pipeline in a single action. This is great for managing changes across a fleet of devices.

See the [device groups documentation](https://flowfuse.com/docs/user/device-groups) for more information on how to make use of device groups.


# Managing devices

We have added bulk operations for managing devices.

In this first iteration we have added the ability to delete multiple devices at once.

To use this feature, navigate to the devices page, application devices or instance devices and place a check in the box next to the devices you wish to delete.
Once you have selected the devices you wish to delete, click the trash can button above the table & confirm the deletion.

We will be adding more bulk operations in the future, so keep an eye out for more updates.

![Deleting multiple devices](https://flowfuse.com/changelog/2024/07/images/bulk-delete-1.png)


# Managing devices

Having recently added the ability to delete multiple devices at once, we have now added the ability to move multiple devices at once.

To use this feature, navigate to the devices page, application devices or instance devices and place a check in the box next to the devices you wish to move.
Once you have selected the devices you wish to move, click the new menu button above the table & select the new location for the devices.

We are are sure this will make managing your devices a good deal easier.

![New menu for managing multiple devices](https://flowfuse.com/changelog/2024/07/images/bulk-menu.png)

![Moving multiple devices](https://flowfuse.com/changelog/2024/07/images/bulk-move.png)

You can read up on the new feature in our [documentation](https://flowfuse.com/docs/device-agent/register/#assign-the-remote-instance).


# Edit Snapshots

Snapshots can now be renamed and their descriptions updated, even after they're created.

![Screenshot showing the new Edit Snapshots feature in FlowFuse](https://flowfuse.com/changelog/2024/07/images/edit-snapshots.png){dataZoomable=""}*Screenshot showing the new Edit Snapshots feature in FlowFuse*

This is particularly useful for the snapshots that are automatically generated each time your deploy your flows, making it easier to track back your changes and revert to a previous state if needed.


# The FlowFuse Expert

We are excited to announce the first release of The FlowFuse Expert, a new plugin for your Node-RED instances designed to enhance your development experience.

In this initial release, The FlowFuse Expert can help you create function nodes for those times when a no-code solution is either not feasible or not possible.
Additionally, it works directly inside the Function Node editor right where you need it.

This is just the beginning. The FlowFuse Expert will continue to evolve, with future updates bringing even more powerful features and enhancements.

Starting from today, FlowFuse Expert is available on FlowFuse Cloud. Users will need to update their instances to the latest stack to enable it.

![Node-RED Editor toolbar button for the assistant](https://flowfuse.com/changelog/2024/07/images/assistant-toolbar.png)

![FlowFuse Expert Input Dialog](https://flowfuse.com/changelog/2024/07/images/assistant-dialog-function-node-builder.png)

![FlowFuse Expert Code Lens](https://flowfuse.com/changelog/2024/07/images/assistant-function-node-inline-code-lens.png)


# FlowFuse Expert Writes JSON

The FlowFuse Expert can now assist you by generating JSON.

Wherever you edit JSON in the Rich Monaco Editor you will see the "Ask the FlowFuse Expert 🪄" code lens.
That includes the Inject Node, the Template Node and any contrib node that uses the built-in editor for writing JSON.

We think you will find this to be a great time saver and a good helper when you are unsure of the syntax.

Just ask for what you want and it does a decent job of figuring it out.

Here are some examples:

### Asking the Assistant to generate JSON from within the `template` node

![Prompting from within the Template Node](https://flowfuse.com/changelog/2024/07/images/ask-assistant-json-1a.png)![Resulting JSON](https://flowfuse.com/changelog/2024/07/images/ask-assistant-json-1b.png)

### Asking the Assistant to generate JSON from within the `inject` node for the `payload` value

![Prompting from within the Inject Nodes Typed Input](https://flowfuse.com/changelog/2024/07/images/ask-assistant-json-2a.png)![Resulting JSON](https://flowfuse.com/changelog/2024/07/images/ask-assistant-json-2b.png)

This is just the beginning of the FlowFuse Expert's capabilities. Stay tuned!

#### Updating the Assistant to get these new features

If you are running Node-RED v4.x, head over to the Palette Manager, update the plugin and restart your instance.

![Updating assistant on Node-RED 4](https://flowfuse.com/changelog/2024/07/images/assistant-update-nr4.png)

If you are still running Node-RED v3.x, you can update the plugin by adding `@flowfuse/nr-assistant` to the instance settings then restart it.

![Updating assistant on Node-RED 3](https://flowfuse.com/changelog/2024/07/images/assistant-update-nr3.png)


# Immersive Editor Experience

We found out that many users have to frequently switch between the Node-RED Editor and FlowFuse UI. This back-and-forth movement was often necessary to view logs, save snapshots, restart the Editor after updates, and perform other tasks.

We're always seeking to reduce friction in the FlowFuse user experience, and as such, we've introduced a large overhaul of the developer experience for Node-RED when running in FlowFuse, in what we're calling the "Immersive Editor".

![Node-RED Editor toolbar button for the assistant](https://flowfuse.com/blog/2024/07/images/immersive-editor.png){dataZoomable=""}

Now, the instances tabs are all available in the same view as the Editor, and you can manage your instance, watch logs, capture snapshots and event restart it, all without leaving the Node-RED Editor.

The new Immersive Editor is available for instances running Node-RED 4.0.2 or later - older versions of Node-RED will still use the separate views.


# Notifications Inbox

We've made some changes to the way notifications are displayed and handled in FlowFuse to make it easier to see what's going on in your system, with a new, dedicated, "Notifications Inbox".

![Screenshot showing the new Notifications Inbox in FlowFuse](https://flowfuse.com/changelog/2024/07/images/notifications-inbox.png){dataZoomable=""}*Screenshot showing the new Notifications Inbox in FlowFuse*

Whilst the only notifications we're supporting right now are team invites, this groundwork will allow us to expand the types of notifications we can send in the future to give better visibility of what's happening in your FlowFuse environment.


# Notifications Inbox

To keep you focused, we have added a "Hide Read" checkbox that is checked by default so that you only see active notifications.

Not only that, we've added some new notifications so that members and owners get fast feedback for important events in your system.

![Screenshot showing unread Notifications Inbox in FlowFuse](https://flowfuse.com/changelog/2024/07/images/notifications-inbox-unread.png){dataZoomable=""}*Screenshot showing unread Notifications Inbox in FlowFuse*

![Screenshot showing read Notifications Inbox in FlowFuse](https://flowfuse.com/changelog/2024/07/images/notifications-inbox-read.png){dataZoomable=""}*Screenshot showing read Notifications Inbox in FlowFuse*


# Persistent Storage on FlowFuse Cloud

Users of FlowFuse Cloud and self-hosted users on Kubernetes can now make use of a
new persistent storage solution.

Starting with the v2.6.0 release the Pods running the Node-RED Instances will have
a Persistent Volume mounted on `/data/storage` in which files can be written. These
files will persist for the lifetime of the Instance including across Susspend/Resume
and Stack upgrades.

This update means nodes like [node-red-node-sqlite](https://flows.nodered.org/node/node-red-node-sqlite){rel="&#x22;nofollow&#x22;"} can be used to store data safely.

This capability replaces the current FlowFuse FileServer which made use of custom
versions of the Node-RED code File nodes to store and read files from a remote network
store. However this didn't allow 3rd party nodes to also benefit from the storage provided.

New instances created will default to use the new Persistent Storage volumes. If you want to upgrade an existing instance that uses the FileServer storage, get in touch with [Support](https://flowfuse.com/contact-us/) and we can help migrate your data over.

Similar support for Docker will be available in later releases.


# Single Sign On Updates

In the v2.7.0 release we have included some new SSO features

## User creation on first log in

Before v2.7.0 users needed to be created before they could use SSO to
log in to FlowFuse. Now if enabled in the SSO configuration users will
be created when they first sign in. If team membership is controlled by
SSO Groups (SAML only) then they will be added to the relevant teams, otherwise if the system is configured to create a Team for a new user it will do so.

FlowFuse Cloud customers should contact support to discuss enabling this
feature for their teams.

## Managing FlowFuse Admins with SSO Groups

It is now possible to configure a group to manage which users are granted
administration privileges. The name of the group can be added to the SSO
configuration (SAML only).

NOTE: It is advised to maintain a backup admin user that does not
authenticate via SSO so ensure access can be maintained if the SSO
provider is unavailable. Also the system will not remove the admin flag
from a user if that would leave the platform with no admins even if they
removed from the group.

This feature is not available to FlowFuse Cloud customers.


# Bill of Materials

Starting with the v2.9.0 release FlowFuse a new Application Dependencies tab will be available for Enterprise self-hosted
and Enterprise Tier FlowFuse Cloud users where a complete list of dependencies belonging to every Instance associated to the application can be found.

![bom.png](https://flowfuse.com/changelog/2024/08/images/bom.png)

The intent is to give users a birds eye view of an application's dependencies and track dependency changes.

Users can search by package name, version, instance or device name.


# Enforcing Enterprise Restrictions

Starting with the v2.8.0 release FlowFuse will be taking a slightly stricter
approach to License enforcement outside of FlowFuse Cloud. Previously
when a license expired the platform would continue to run with the same
capabilities as when the license was valid.

If you are currently running with older version with an expired license
please [contact the Sales team](https://flowfuse.com/contact-us/) to discuss renewing your
license before upgrading. You can check your current license on the
Admin Settings -> Overview page.

## Notifications

Starting 30 days before the license expires:

- Admin users will see a banner showing the number of days left. :br![expiring banner](https://flowfuse.com/changelog/2024/08/images/expiring-banner.png)
- A email will be sent to all Admin users.

The email will be sent again every Sunday evening in the 30 days.

## After Expiry

- All running instances will be suspended.
- Instances will not be started.
- No new Instances or Devices can be created.
- A email will be sent to all Admin users saying the license has expired.
- A banner showing the license as expired will be shown to all users. :br![expired banner](https://flowfuse.com/changelog/2024/08/images/expired-banner.png)
- All connections to the MQTT broker will be refused (This will impact
  Project Nodes and Device control).

## Applying a New License

A new license can be applied in the Admin Settings -> Settings section.

Once applied you will be able to restart all existing Instances and
create new Instances and Devices. The MQTT will accept new connections.


# LDAP Single Sign On Updates

In the v2.8.0 release we have updated the LDAP SSO feature to allow group
membership to be managed by LDAP groups.

## Configuring

Building on the SAML based SSO configuration there is now a `Manage roles using group assertions` check box on the LDAP SSO configuration page. This allows a base LDAP DN for groups to be set. This will used to look up which groups a user is a member of when they login to the platform.

![screen shot showing new LDAP group management settings](https://flowfuse.com/changelog/2024/08/images/ldap-group.png)

Groups can be `groupOfNames` or `groupOfUniqueNames` and membership will be checked against `memberOf` or `uniqueMemberOf` fields respectively.

### Group Naming

Group names must follow the this pattern `ff-<team slug>-role`

The valid roles for a user in a team are:

- `owner`
- `member`
- `viewer`
- `dashboard`

*Note*: this uses the team slug property to identify the team. This has been chosen to simplify managing
the groups in the LDAP Provider - rather than using the team's id. However, a team's slug can be changed
by a team owner. Doing so will break the link between the group and the team membership - so should only
be done with care.

More details can be found in the [SSO LDAP documentation](https://flowfuse.com/docs/admin/sso/ldap).

## Managing FlowFuse Admins

In the previous release we added support for managing FlowFuse Admin users by group membership to SAML SSO, this is now available to LDAP as well.

*Note*: It is advised to maintain a backup admin user that does not
authenticate via SSO so ensure access can be maintained if the SSO
provider is unavailable. Also the system will not remove the admin flag
from a user if that would leave the platform with no admins even if they
removed from the group.

This feature is only available to FlowFuse self-hosted customers.


# Static File Service Navigation and Visibility

Users of FlowFuse Cloud can now make use of an enhanced navigation tool and visibility selector when using the [static file service feature](https://flowfuse.com/blog/2024/08/flowfuse-2-8-release/#static-assets-service).

By settings the visibility of a folder to 'public', their Node-RED instance will automatically make any files in that folder publicly available - on a path of the user's choosing.

This makes it very simple to serve up additional assets such as images or libraries that can be used in your Node-RED Dashboards.

The visibility settings apply to the folder; you cannot make individual files public. Any changes to the visibility settings will require the instance to be restarted for the changes to take effect.

![static-file-service-navigation-visibility](https://flowfuse.com/changelog/2024/08/images/static-file-service-navigation-visibility/1-selector.png)![static-file-service-navigation-visibility](https://flowfuse.com/changelog/2024/08/images/static-file-service-navigation-visibility/2-select-static-path.png)![static-file-service-navigation-visibility](https://flowfuse.com/changelog/2024/08/images/static-file-service-navigation-visibility/3-public-visibility.png)


# Environment Variables for your Device Groups

We have added the ability to set Environment Variables on a Device Group.
This allows you to set common values that all member devices can make use of.

![Screenshot showing Device Group Environment Variables](https://flowfuse.com/changelog/2024/10/images/device-group--with-env-vars.png){dataZoomable=""}*Screenshot showing Device Group Environment Variables*

We hope this feature will make it easier to manage your devices and keep your configuration in one place.

See the [Device Group](https://flowfuse.com/docs/user/device-groups) documentation for more information on how to set environment variables for your device groups.


# MQTT Broker Service

To celebrate 25 years since the first release of the MQTT Specification we are happy announce a new MQTT Broker Service as part of FlowFuse Cloud.

The initial deployment is available to Enterprise Teams and allows up to 20 clients to connect to the broker. Each team has their own independent topic space and can set their own topic ACLs to control what clients can access.

From today, this feature is available to FlowFuse Cloud Enterprise Teams. We'll be bringing it to Self-Hosted customers in the near future, as well as adding the ability to purchase additional packs of clients.

See the [broker documentation](https://flowfuse.com/docs/cloud/introduction/#enterprise-team-broker) for more details.


# Managing Notifications

We have now added the ability to manage notifications in bulk. This allows users to select more than one notification so that they can be marked as read, or marked as unread, all in one go.

We hope this small improvement saves you bundle of clicks and streamlines your operations.

![bulk-notifications.png](https://flowfuse.com/changelog/2024/10/images/bulk-notifications.png)


# Snapshot Upload and Download Improvements

We have added the ability to select which components of a snapshot you want to keep when downloading or uploading a snapshot.

The options available are:

- Flows: Include the flows of the snapshot
- Credentials: Include the credentials of the snapshots flows
- Environment Variables
  - Keys and Values: Include the keys and values of the environment variables
  - Keys Only: Include only the keys of the environment variables

![Screenshot showing snapshot download component options](https://flowfuse.com/changelog/2024/10/images/snapshot-download--with-options.png){dataZoomable=""}*Screenshot showing snapshot download component options*

![Screenshot showing snapshot upload component options](https://flowfuse.com/changelog/2024/10/images/snapshot-upload--with-options.png){dataZoomable=""}*Screenshot showing snapshot upload component options*

This feature can help you be specific about what you want to include in a downloaded snapshot. This is especially useful when
you want to share a snapshot with others, but don't want to include sensitive information like credentials. Also,
when you receive a snapshot that needs importing into a different FlowFuse platform or team, you can can now be selective
about what to keep and what to exclude.

See the [Snapshots](https://flowfuse.com/docs/user/snapshots) documentation for more information.


# Version History Timeline

Instances can now make use of the new Timeline feature, providing a concise, chronological view of key activities within your Node-RED instance.

The Timeline tracks important events such as pipeline stage deployments, snapshot restorations, flow deployments, snapshot creations, and updates to instance settings, offering clear insight into when and what changes have been made.

The Timeline and Snapshots are now grouped together under the Version History tab, simplifying the navigation of your instance's history.

This feature is only available to Enterprise license and Cloud Team users. Note that the Timeline can only be accessed at the instance level.

![Screenshot showing the version history Timeline](https://flowfuse.com/changelog/2024/10/images/version-history-timeline.png){dataZoomable=""}*Screenshot showing the new version history timeline*

![version-history-snapshots.png](https://flowfuse.com/changelog/2024/10/images/version-history-snapshots.png){dataZoomable=""}*Screenshot showing the relocated snapshot page under the version history tab*


# Audit logs show hierarchical events

In FlowFuse V2.11, we have updated the Audit Log views to let you see more of the events happening within your team. Previously, the Audit Log view would only show you top-level events happening to the application or team. With this release, it now provides an aggregated view of all of your resources.
Additionally, each row contains an icon and name of the item raised the event that you can click to navigate straight to it making your workflow more streamlined.

![Screenshot showing Audit Log with hierarchical events](https://flowfuse.com/changelog/2024/11/images/audit-log-child-events.png)*Screenshot showing Audit Log with hierarchical events*

We hope this feature will help you better understand and navigate your FlowFuse applications.


# Device Agent 3.0 released

The FlowFuse Device Agent is the piece of software we provide to manage Node-RED instances running anywhere outside of the FlowFuse platform.

Today we have released the latest version of the agent that now requires at least Node.js 18 to run. To reflect this change, we are releasing this as a new major version - 3.0.

We recognize that software update lifecycles can be a challenge in some environments. This is why we've held off dropping support for older Node.js versions for as long as we could. However, we have to balance that against ensuring we continue to keep the Device Agent up to date with the latest security fixes.

If your devices cannot be updated to the latest Node.js versions, then please ensure you stay on the 2.x release of the Device Agent until a time that you are able to update Node.js.

Details for upgrading to this release are available [in the documentation](https://flowfuse.com/docs/device-agent/install/manual/#upgrading-the-agent).


# MQTT Topic Hierarchy view

Having recently added [our very own MQTT Service](https://flowfuse.com/blog/2024/10/announcement-mqtt-broker) to the platform, we're continuing to expand on the features and tools we provide to help teams build their solutions.

We have added a view that shows you what MQTT topics are being used on the Team Broker. This helps give you clarity on the structure of your topic-space, whether you're using the MQTT Broker for a unified namespace (UNS) or any other use case.

This is a small iteration of the feature but we'll have lots more to come.

![Screenshot of the UI to explore your MQTT topic hierarchy](https://flowfuse.com/changelog/2024/11/images/screenshot-mqtt-hierarchy.png){dataZoomable=""}*Screenshot of the UI to explore your MQTT topic hierarchy*


# Team-wide search

A new search bar has been added that makes it quick and easy to find resources within your team.

This expands on the search available on the Applications summary view - but by moving to the top header, it's now available on all pages.

For this release, it searches your Applications, Instances and Devices. We'll be expanding its coverage in future iterations to include other resources in the team.

![Screenshot of the team-wide search](https://flowfuse.com/changelog/2024/11/images/screenshot-search.png){dataZoomable=""}*Screenshot of the team-wide search*


# Allow Dashboards to be embedded in iFrames

With the 2.12.0 release the correct HTTP Headers can now be set to allow Dashboards hosted in Node-RED Instances on FlowFuse to be embedded into other pages as iFrames.

This option is under the Instance Settings on the Editor section.

![Enable iFrame Support](https://flowfuse.com/changelog/2024/12/images/enable-iframe.png){dataZoomable=""}*Enabled iFrame Support*

This feature will require the latest Stack version, you will be prompted to upgrade if required.

![Upgrade Stack to Enable](https://flowfuse.com/changelog/2024/12/images/upgrade-iframe-dashboard.png){dataZoomable=""}*Upgrade Stack to Enable*


# Device Editor Access Speed Up

With the 2.12 release we have included some improvements to the Device Editor experience.

For Devices running with Node-RED 4.0.x and newer, there should be significant performance improvements when loading the editor, especially when the device is on a slow network link.


# Team BOM and Pipeline Views

Team-level views of all Pipelines and Bill of Materials have been added to provide a complete overview.

The Bill of Materials view shows which components and their versions across all Node-RED Devices & Instances in the whole Team rather than at an Application level.

![Team BOM view](https://flowfuse.com/changelog/2024/12/images/team-bom.png){dataZoomable=""}*Team BOM view*

Similarly the Team Pipeline view shows all CI delivery pipelines in all the Applications in the Team, giving team members a quicker way to jump to a specific Pipeline.

![Team Pipelines](https://flowfuse.com/changelog/2024/12/images/team-pipeline.png){dataZoomable=""}*Team Pipelines*


# New Onboarding Tour for Free Tier Users

:product-update-note

![Screenshot from the new onboarding tour for "Free" tier FlowFuse Cloud users](https://flowfuse.com/changelog/2025/01/images/free-tier-onboarding.png){dataZoomable=""}*Screenshot from the new onboarding tour for "Free" tier FlowFuse Cloud users*

Following from our new "Free" tier on FlowFuse Cloud, we've also published a new onboarding tour to help users get started with their new team.

This tour will guide you through the process of setting up your first Remote Instance, and show you how to access your Node-RED instance through FlowFuse Cloud, using the remote access tools.


# Hidden Environment Variables

We’ve expanded the functionality of managing Node-RED environment variables by introducing the ability to hide their values in the UI.

### What’s new?

This feature is supported by both hosted and remote Node-RED instances.

- Users can now designate values as 'hidden' when creating or editing them.
- Hidden values are concealed in the UI for enhanced privacy and security.
- Once marked as hidden and saved:
  - the **name** cannot be changed.
  - the value can only be updated - its existing value cannot be seen.
- To make a value visible again, users must delete the entry and recreate it as a visible one.

This feature enhances security and allows for more control over sensitive configuration data, ensuring better management in your Node-RED workflows.

![Screenshot of the new hidden environment variables feature - Hosted Instances](https://flowfuse.com/changelog/2025/01/images/hidden-env-var-instances.png){dataZoomable=""}*Screenshot of the new hidden environment variables feature - Hosted Instances*

![Screenshot of the new hidden environment variables feature - Remote Instances](https://flowfuse.com/changelog/2025/01/images/hidden-env-var-devices.png){dataZoomable=""}*Screenshot of the new hidden environment variables feature - Remote Instances*


# Improved Diagnostics

It happens! Sometimes things go wrong, but don't worry, we have you covered.

For Team and Enterprise customers on FlowFuse Cloud, we've improved the emails we send notifying you that something has gone wrong with one of your instances.

The emails now include more information about what has happened, including the most recent logs from Node-RED. We also include some tips as to what to do next, whether it was a code bug or a memory issue that triggered the problem.

We hope you never need to see these emails, but if you do, we hope they help you get back on track quickly.


# Team level view of Groups

![Screenshot from the new team level groups](https://flowfuse.com/changelog/2025/01/images/team-level-groups.png){dataZoomable=""}*Screenshot from the new team level groups*

Managing remote instances is easier with the new Team-level view of Groups.

Groups let you organize your Remote Instances by application. They can then be used as a Target in DevOps pipelines for seamless updates across
multiple instances in one operation.

This simplifies deployments, enhances collaboration, and streamlines infrastructure management for faster, more
efficient workflows.


# New Remote Instances Version History Events

Users can now get better visibility of the state of their Remote Instances with additional events in the Version History timeline. This enhancement improves traceability and provides deeper insights into remote instance state changes over time.

## New Trackable Events

- **Deploying Snapshots to Remote Instance via a Pipeline**
- **Deploying Snapshots through a Hosted Instance**
- **Snapshot Rollback**
- **Snapshot Create**

These events will be automatically recorded in the version history, allowing users to review and audit changes more effectively.


# Improved Broker Connection Feedback

![Improved feedback displayed to a user when a third-party broker does nto connect as expected](https://flowfuse.com/changelog/2025/02/images/broker-error-feedback.png){dataZoomable=""}*Improved feedback displayed to a user when a third-party broker does nto connect as expected*

We've improved the feedback displayed to a user when a third-party broker does not connect as expected. This will help users to diagnose and resolve issues with their broker connections more easily, extending on the "error" status pill that was initially implemented alongside the broker's name.


# FlowFuse User Authentication on Remote Instances

With the 3.1.1 release of the FlowFuse Device Agent, we've added two important pieces of new functionality.

### FlowFuse User Authentication

It is now possible to enable end-point security on the instance. In the same way you can for Hosted Instances,
you can now configure Basic Username/Password authentication or the more powerful FlowFuse User Authentication.

This means you can serve up your dashboards on remote Instances confident that only users in your FlowFuse team can access them.

### Modifying settings in Developer Mode

Whilst a remote instance is in developer mode, you can access the Node-RED editor through the FlowFuse platform. This
is a great way to develop your flows on real hardware through the platform.

A common developer task is to want to modify environment variables, or change device settings (such as enabling the new
FlowFuse User authentication option).

Previously this would require taking the device out of developer mode in order to apply the changes. From a workflow, this required lots of additional steps for not a lot of benefit.

With the new release of the Device Agent, the agent will pick up any settings changes when it is restarted via the action menu in the FlowFuse UI. A small change, but a big improvement to the developer workflow.


# Version History Timeline

**Remote instances** can now make use of the new Timeline feature, providing a concise, chronological view of key activities within your Node-RED remote setup.

The Timeline and Snapshots are now grouped together under the Version History tab, simplifying the navigation of your remote instance's history.

This feature is only available to Enterprise license and Cloud Team users. Note that the Timeline can only be accessed at the remote instance level.

![Screenshot showing the version history Timeline](https://flowfuse.com/changelog/2025/02/images/device-version-history-timeline.png){dataZoomable=""}:br*Screenshot showing the new version history timeline*

![version-history-snapshots.png](https://flowfuse.com/changelog/2025/02/images/device-version-history-snapshots.png){dataZoomable=""}:br*Screenshot showing the relocated snapshot page under the version history tab*


# External MQTT Brokers

In a previous release, we introduced the FlowFuse Team Broker; an MQTT broker available to all instances running in your team. Whilst the Team Broker is a great addition, we are aware that many of our customers already have their own existing MQTT brokers and infrastructure.

We have now made it possible to connect the FlowFuse platform to your existing external MQTT broker. With that you'll get access to the same great features to help you gain a clear understanding of the activity on your broker, and the structure of the data and topics that are being used.

![Screenshot from creating new external broker](https://flowfuse.com/changelog/2025/02/images/new-external-broker.png){dataZoomable=""}*Screenhot from creating new external broker*

As well as building a topic schema, the message payloads will also be
inspected to infer their format to help you understand your data.

![Screenshot of topic and inferred payload schema](https://flowfuse.com/changelog/2025/02/images/topic-and-payload-schema.png){dataZoomable=""}*Screenshot of topic and inferred payload schema*

Whilst connected, the FlowFuse platform will monitor the messages being published on the broker and update the information every few minutes. This means there will be a short delay between a message being published to a topic and that topic being shown in the hierarchy.

This is available on FlowFuse Cloud and for Self Hosting users with an Enterprise License on Kubernetes and LocalFS. Docker support will follow shortly.


# MQTT Smart Schema Suggestions

FlowFuse's new "Smart Suggestions" feature will help you get your full UNS and MQTT Broker documented with ease.

Our agent will monitor traffic through the Broker, and make calculate the schema of any payloads passed through. This assessment is turned into a "Suggestion" within the FlowFuse Platform, and can quickly be added to the formal schema for your Broker.

:lite-youtube{params="rel=0" style="width: 100%; aspect-ratio: 16/9;" videoid="bNeTDJUZ1So"}


# Re-send Team Invitations

We have added the ability to **re-send team invitations**, which also extends the expiration date of the invitation. This improvement ensures that invitations remain valid for a longer period and allows team administrators to easily re-invite users who may have missed their initial invitation.

This update enhances user management and simplifies the process of maintaining team memberships within FlowFuse.

![Screenshot of the member invitation page](https://flowfuse.com/changelog/2025/02/images/resend-invitation.png){dataZoomable=""}*Screenshot of the member invitation page*


# Personalized Schema Documentation

![Screenshot of the new MQTT Broker schema documentation view available in FlowFuse](https://flowfuse.com/changelog/2025/02/images/schema-documentation.png){dataZoomable=""}*Screenshot of the new MQTT Broker schema documentation view available in FlowFuse*

This new view for your MQTT Broker focusses on clarity, and collaboration. It provides a single, easy to read window that provides the relevant information any member of your team or organization would need in order to understand what your MQTT broker is used for.

The underlying schema is generated automatically by FlowFuse, using the industry-standard, open-sourced, [AsyncAPI](https://www.asyncapi.com/){rel="&#x22;nofollow&#x22;"}, saving your months of resource in manually documenting payload and topic structures yourself.

The documentation provides a comprehensive view of the topics published to on your Broker, as well as crafted descriptions to help users understand each topic's purpose. This feature is available for both the in-built FlowFuse Broker, and any third-party broker that you choose to connect to.


# Search & Filter for Topic Hierarchy List

![Search and filter functionality in the topic hierarchy list](https://flowfuse.com/changelog/2025/02/images/topic-hierarchy-search.png){dataZoomable=""}:br*Search and filter functionality in the topic hierarchy list*

We've introduced search and filter capabilities to the topic hierarchy list. This allows users to quickly find specific topics, making navigation more efficient and improving usability when working with large topic trees.


# Changes to tags for flowfuse/node-red

As part of the upcoming FlowFuse 2.16.0 release we will be updating which
version the `latest` tag points to for the `flowfuse/node-red` containers.

This change will impact self-hosted Docker and Kubernetes installs that have not changed the default stack.

The `latest` tag currently points to the latest version of the FlowFuse Stack container but contains Node-RED version 3.0.2 and NodeJS 16. After the update it will contain Node-RED version 4.0.9 and NodeJS 20.

It will then continue to track the latest stable Node-RED version as they are released.

You can update the tag by creating a new version of the Stack under the Admin Settings -> Stacks page as a FlowFuse Admin user.

We make the following tags available which track the latest version of FlowFuse:

- `flowfuse/node-red:latest` as described above
- `flowfuse/node-red:latest-2.2.x` which contains Node-RED 2.2.2 NodeJS 16
- `flowfuse/node-red:latest-3.0.x` which contains Node-RED 3.0.2 NodeJS 16
- `flowfuse/node-red:latest-3.1.x` which contains Node-RED 3.1.15 NodeJS 18
- `flowfuse/node-red:latest-4.0.x` which contains Node-RED 4.0.9 NodeJS 20 (same as `flowfuse/node-red:latest`)

We also publish tags explicitly pinned to a FlowFuse version with the following format `<version>-<node-red-version>` e.g. `flowfuse/node-red:2.15.0-4.0.x` which would be FlowFuse 2.15.0 and Node-RED 4.0.x.


# Multiple Device Groups in a pipeline

Last year, we announced the introduction of Device Groups. For those that are not familiar with Device Groups, this feature enables users to logically group their Remote Instances so that they can be targeted in a DevOps Pipeline facilitating streamlined and efficient deployments across your fleet of devices.

Previously, you could only use a Group as the last stage in a pipeline. With this update, you can now have Groups at other stages in a pipeline. For example, you may have a group of test devices that you want to push updates to before pushing them out to your larger group of production devices.

This improvement not only saves time but also enhances the consistency and reliability of remote instance management across your fleet.


# Local Login for Remote Instances

With the new 3.2.0 release of the FlowFuse Device Agent, we have introduced a new Local Login option for Remote Instances.

This feature allows you to enable a local login for your Remote Instance, which is particularly useful in air-gapped environments or times when the instance cannot reach the FlowFuse platform.

When local login is enabled, users can log in to Node-RED directly using the specified credentials.

For day-to-day activity, we still recommending accessing the editor through the FlowFuse Platform for the best user experience. However, for those times when that isn't possible, this option provides a fall-back to allow continued access to the device.

You can configure this option in your Remote Instance Settings tab under the Security section.
![Screenshot of local login options](https://flowfuse.com/changelog/2025/03/images/device-agent-local-login-settings.png){dataZoomable=""}*Screenshot of local login options*

Additionally, you can enable or disable local login for in the Device Agents YAML configuration file. For more information, refer to the [Node-RED Settings](https://flowfuse.com/docs/device-agent/register/#node-red-settings) in our documentation.


# Free Tier now more accessible to all

:product-update-note

We introduced the Free tier on FlowFuse Cloud [back in December](https://flowfuse.com/blog/2024/12/flowfuse-release-2-12/). This allows you to manage two remote instances using the FlowFuse Device Agent completely free of charge.

Since its launch we had many users sign-up and start connecting their remote instances to the platform. We've also had feedback on the fact it required you to enter credit card details to get fully set up.

We're please to announce that, as of today, you no longer need a credit card to sign-up to our Free tier - you can jump straight into getting your remote instances connected.

Check out the [original announcement blog post](https://flowfuse.com/blog/2024/12/flowfuse-release-2-12/) on how to get started with the Free tier.


# Resource Alerts

To help you manage resource utilization more effectively, we’ve introduced notifications to alert you when you’re nearing critical thresholds.

The new CPU and Memory notifications will notify you when usage exceeds 75% of capacity. This proactive alerting gives you the opportunity to take action before experiencing downtime or performance issues.

We hope this feature helps you avoid unexpected resource-related challenges with your applications.

![Screenshot of the new resource notifications](https://flowfuse.com/changelog/2025/03/images/resource-notifications.png){dataZoomable=""}*Screenshot of the new resource notifications*

### How to Enable or Disable Notifications

You can manage these notifications in your Hosted Instance **Settings** tab under the **Alerts** section.

![Screenshot of the new resource notifications settings](https://flowfuse.com/changelog/2025/03/images/resource-notifications-settings.png){dataZoomable=""}*Screenshot of the new resource notifications settings*


# Filtering Snapshots

To simplify management of Snapshots, they can now be filtered to "All Snapshots", "User Snapshots" or "Auto Snapshots"

![Screenshot of the new Snapshot filter](https://flowfuse.com/changelog/2025/03/images/snapshot-filter.png){dataZoomable=""}*Screenshot of the new Snapshot filter*


# NPM Package Hosting

For Team and Enterprise tier Teams on FlowFuse Cloud we are introducing a NPM package repository giving you a place to host custom Node-RED nodes.

These Node-RED nodes can be used in both Hosted and Remote Instances and will show up in a custom catalogue with the name "FlowFuse Team [team name] Catalogue" in the Node-RED editor.

![Custom Catalogue](https://flowfuse.com/changelog/2025/03/images/custom-catalogue.png){dataZoomable=""}*Custom Catalogue*

A list of NPM Packages published to the Team's repository can be seen under the Team's Library section in the "Custom Nodes" tab

![Custom Nodes list](https://flowfuse.com/changelog/2025/03/images/custom-node-library.png){dataZoomable=""}*Custom Nodes list*

This feature is also available to self hosting Enterprise customers on Kubernetes with Docker following shortly.


# MQTT Topic Management

We are always looking for ways to improve FlowFuse and today, we have made a small but notable addition: the ability to delete old topics from your hierarchy.

This helps you keep things tidy and not clutter your hierarchy with old topics. Note that if the topic is published to again and detected by the platform, it will get added back.

![Screenshot of the new Topic Delete feature](https://flowfuse.com/changelog/2025/03/images/topic-deletion.png){dataZoomable=""}*Screenshot of the new Topic Delete feature*


# Remote Instance Provisioning

FlowFuse has had the ability to provision remote instances at scale for some time now, but assigning remote instances to an application has, until now, been a manual process.

In this update, we have added the ability to have your bulk provisioned remote instances automatically assign themselves to an application upon creation.

This will save you a lot of time if you have a large number of remote instances to provision.

![Screenshot of creating a provisioning token](https://flowfuse.com/changelog/2025/04/images/create-provisioning-token.png){dataZoomable=""}*Screenshot of creating a provisioning token*

Checkout the Bulk Registration section in the [Device Agent Registration](https://flowfuse.com/docs/device-agent/register) documentation for more information on how to use this feature.


# Git Integration with Pipelines

From today, Enterprise tier teams on FlowFuse Cloud are able to add a Git Repository stage to their deployment pipelines. When the pipeline is triggered, the latest snapshot will get pushed to the configured repository.

This has been one of those features that has come up a number of times with our users; we knew we wanted to have Git integration in the platform, but we also wanted it to fit in a natural way with the developer workflows we provide.

This is very much a "first-iteration" of the feature that will allow us to get feedback early and continue to iterate.

With this release, the following restrictions apply:

- Only GitHub.com hosted repostories are supported
- Users must create a GitHub Personal Access Token and add to their Team Settings
- We currently only support pushing snapshots to a Git repository

This last point is important; this release lets you backup your flows to git, but we haven't yet enabled the return journey of pulling a snapshot from a Git repository back to your Node-RED instance. That'll come in the near future and will unlock a full git-based review workflow within the pipelines.

We'll also look at enabling other Git hosting providers - let us know which you'd like to see on the list.

![Screenshot of a Git Pipeline Stage](https://flowfuse.com/changelog/2025/04/images/git-pipeline-stage.png){dataZoomable=""}*Screenshot of a Git Pipeline Stage*


# Better Node-RED log handling

We've improved the log handling within our Hosted Node-RED instances. Previously we were using a fix sized buffer in memory; meaning the noiser your Node-RED instance was, the less history you'd have. The UI for browsing the logs was also awkward when you wanted to jump back to an earlier section of the logs.

With this release, once you update your instances to the latest version, we will
now store the last 7 days worth of logs for each hosted Node-RED instance.

To go along side this, we've added the ability to jump to a specific time/date in the logs without having to endlessly scroll.

To start benefiting from the extended logs, make sure you update the latest version via your Instance Settings page.

![Screenshot of browsing Node-RED logs by timestamp](https://flowfuse.com/changelog/2025/04/images/browse-logs.png){dataZoomable=""}*Screenshot of browsing Node-RED logs by timestamp*


# Import Node-RED Flows During Remote Instance Setup

FlowFuse Device Agent now supports importing Node-RED flows during the setup process. This feature streamlines the configuration of your Remote Instance by allowing you to:

- Select an existing Node-RED flows directory from your device.
- Choose a specific flows file to import.
- Automatically import associated credentials and package files.

### How it works

1. **Setup Command**: Run the setup command provided in the FlowFuse interface.
2. **Flow Selection**: During setup, you will be prompted to import existing Node-RED flows. Options include:
   - Skipping the import.
   - Selecting a default Node-RED directory (e.g., `.node-red`).
   - Specifying a custom path.
3. **File Selection**: If a directory is selected, you can choose a specific flows file to import.
4. **Automatic Import**: The Device Agent will handle importing credentials, package files, and generate a snapshot to the FlowFuse Platform, setting it as the "Target Snapshot" for the device.

### Notes

- When your Remote Instance is started, it will install all the necessary pieces and run your new Snapshot.
- The Remote Instance must be assigned to an application before running the **Setup Command**
- Requires Device Agent v3.3.1
- Available on FlowFuse Cloud today. For self-hosted customers, you'll need FlowFuse version 2.17

### Screenshots

![Screenshot of the FlowFuse interface for configuring a Remote Instance](https://flowfuse.com/changelog/2025/05/images/device-setup-dialog.png){dataZoomable=""}*Screenshot of the FlowFuse interface for configuring a Remote Instance*

![Screenshot of the new import options in the Device Agent during setup](https://flowfuse.com/changelog/2025/05/images/device-agent-import.png){dataZoomable=""}*Screenshot of the new import options in the Device Agent during setup*

We hope this enhancement simplifies the process of migrating existing Node-RED flows to FlowFuse.


# FlowFuse Expert just got smarter

Last year, we introduced the FlowFuse Expert, a Node-RED plugin designed to assist FlowFuse users with tools for developing their Node-RED instances. Today, we are excited to announce that the Assistant has been updated with a new feature powered by AI: the Flows Explainer. This feature uses AI to analyze your Node-RED flows and provide a detailed explanation of what they do, making it easier for you to understand and manage your flows.

Stay tuned; this is just a taste of what is to come.

#### Flows Explainer

![flowfuse-assistant-flow-explainer](https://flowfuse.com/changelog/2025/06/images/flowfuse-assistant-flow-explainer.gif){dataZoomable=""}*Screenshot of the FlowFuse Expert Flow Explainer*

#### Updating the Assistant

If you are running Node-RED v4.x, head over to the Palette Manager, update the plugin and restart your instance.

![Updating assistant on Node-RED 4](https://flowfuse.com/changelog/2025/06/images/assistant-update-nr4.png){dataZoomable=""}*Screenshot of Updating assistant on Node-RED 4*

If you are still running Node-RED v3.x we strogly recommend you update your stack to use Node-RED v4.x but you can still manually update the plugin by adding `@flowfuse/nr-assistant` to the instance settings then restart it.

![Updating assistant on Node-RED 3](https://flowfuse.com/changelog/2025/06/images/assistant-update-nr3.png){dataZoomable=""}*Screenshot of Updating assistant on Node-RED 3*


# FlowFuse Expert just got smarter

Following on from the recent improvements we made earlier this month, we have added even more goodness to the FlowFuse Expert:

We have:

- Added a menu for quick access to the new features
- Improved the look and feel of the Flow Explainer
- Added a codelens to assist you creating HTML, VUE, Vuetify & CSS in FlowFuse Node-RED Dashboard templates

And there more to come in the next week - stay tuned!

#### New Menu

![Screenshot of the new Assistant Menu](https://flowfuse.com/changelog/2025/06/images/assistant-new-menu.png){dataZoomable=""}*Screenshot of the new Assistant Menu*

#### Flow Explainer updated look & feel

![Animated GIF showing the Flow Explainer Updated Layout](https://flowfuse.com/changelog/2025/06/images/assistant-0-3-0-flow-explainer.gif){dataZoomable=""}*Animated GIF showing the Flow Explainer Updated Layout*

#### New Codelens for building ui-templates

![Animated GIF showing the Assistant building HTML & VUE template code](https://flowfuse.com/changelog/2025/06/images/assistant-0-3-0-ui-template-vue.gif){dataZoomable=""}*Animated GIF showing the Assistant building HTML & VUE template code*

![Animated GIF showing the Assistant building CSS styles](https://flowfuse.com/changelog/2025/06/images/assistant-0-3-0-ui-template-css.gif){dataZoomable=""}*Animated GIF showing the Assistant building CSS styles*

#### Updating the Assistant

If you are running Node-RED v4.x, head over to the Palette Manager, update the plugin and restart your instance.

![Updating assistant on Node-RED 4](https://flowfuse.com/changelog/2025/06/images/assistant-0-3-0-update-nr4.png){dataZoomable=""}*Screenshot of Updating the Assistant for a Node-RED 4 instance*

If you are still running Node-RED v3.x we strogly recommend you update your stack to use Node-RED v4.x but you can
still manually update the plugin by adding `@flowfuse/nr-assistant` to the instance settings then restart it.

![Updating assistant on Node-RED 3](https://flowfuse.com/changelog/2025/06/images/assistant-update-nr3.png){dataZoomable=""}*Screenshot of Updating Assistant for a Node-RED 3 instance*


# Pulling snapshots from Git with Pipelines

We released support for [pushing snapshots to a Git repository](https://flowfuse.com/changelog/2025/04/git-integration/) as part of the DevOps Pipelines feature last month. As promised, we've now added the ability to pull snapshots back from the repository.

This unlocks a number of powerful workflows with the Pipelines.

**Review-based Pipelines**

The Git Pipeline stage can be configured to push and pull from different branches of the Git Repostory. By making use of a GitHub Pull Request, you can create a workflow where the snapshot is reviewed and merged before the pipeline can deploy the snapshot to the later stages.

**Deploying snapshots across Teams**

By using an external Git Repository, it is simple to create a workflow that enables moving snapshots between two different Teams on the platform whilst maintaining the security and auditability of the individual Teams.

This feature is available today for Enterprise tier teams on FlowFuse Cloud and will be available for self-hosted Enterprise customers as part of the 2.18 release later this week.

We still only support GitHub.com hosted repositories, but we're looking at support for Azure hosted repos in the near future.

![Screenshot of a Git Pipeline Stage](https://flowfuse.com/changelog/2025/04/images/git-pipeline-stage.png){dataZoomable=""}*Screenshot of a Git Pipeline Stage*


# Memory Metrics in Instance Performance View

We're excited to announce an enhancement to the existing Performance view for Hosted Instances in FlowFuse. We've expanded the view to include a new Memory Utilization chart.

![Screenshot of the expanded Performance view with Memory Utilization](https://flowfuse.com/changelog/2025/06/images/instance-performance-memory.png){dataZoomable=""}*Screenshot of the Performance view with Memory Utilization*

This update provides additional insight, allowing you to monitor not only CPU usage but also memory consumption over time. The inclusion of memory metrics makes it easier than ever to detect performance issues and optimize your Node-RED Flows.


# Introducing the New Home Page Experience

We’re excited to announce the release of the all-new **Home Page**, designed to simplify navigation and provide relevant information at a glance.

### Key Features

- A more intuitive and **dedicated landing page**, replacing the dual-purpose "Applications" view.
- **Recently Modified Instances**: The Home page highlights **recently modified hosted and remote instances**, providing key statistics at a glance:
  - Number of **running**, **error**, and **not running** instances.
  - Each tile is **clickable** for direct access.
- **Recent Activity Section**: A comprehensive view of the latest 50 changes made within the current team is now integrated, enabling better tracking of team activities and updates.

These enhancements are intended to make managing your instances and reviewing activity smoother and more effective.

![Screenshot of the New Home Page](https://flowfuse.com/changelog/2025/06/images/new-home-page.png){dataZoomable=""}*Screenshot of the new home/landing page in FlowFuse*

This improvement aligns with the feedback we received from the community, aimed at delivering a more user-friendly and focused experience.


# Team Performance Feature

We've expanded the **Performance** feature with an exciting new addition: Team Performance metrics.

**Team-Wide CPU Monitoring**: Get a complete overview of CPU usage across all hosted instances in your team,
helping you track and analyze resource allocation efficiently.

These enhancements are designed to improve operational visibility and resource management based on user feedback from
our community.

![Illustration of the New Feature](https://flowfuse.com/changelog/2025/06/images/team-performance.png){dataZoomable=""}*Overview of CPU Usage in the Team Performance Feature*


# Instance Performance View

We've added a new view for every Hosted Instance in FlowFuse, Performance.

![Screenshot of the Performance view for a Hosted Instance](https://flowfuse.com/changelog/2025/06/images/instance-performance.png){dataZoomable=""}*Screenshot of the Performance view for a Hosted Instance*

This view provides a comprehensive insight into the performance of your hosted Node-RED instances, focussing on CPU usage over time, better enabling you to detect performance issues within your Node-RED Flows.

This feature is available today for Enterprise tier teams on FlowFuse Cloud and will be available for self-hosted Enterprise customers as part of the 2.18 release later this week.


# Navigation UI Refresh

We’ve given the top navigation in FlowFuse a visual refresh as part of our effort to constantly improve and modernise the user experience of FlowFuse.

Menus now use a clean white background, with updated colors, spacing, and transitions across the user menu, team switcher, and notification buttons. Mobile menus have also been cleaned up for better usability.

This is the first step in a broader UI modernization effort based on community feedback.

![Screenshot of the re-designed top navigation](https://flowfuse.com/changelog/2025/06/images/ui-refresh-1.png){dataZoomable=""}*Screenshot of the re-designed top navigation*


# Browse for Node-RED Flows During Remote Instance Setup

Last month we introduced a way for the FlowFuse Device Agent to import Node-RED flows during the setup process. Today, we have built on that and added some new features:

- Automatically scan common file locations and offer any flows found for immediate selection
- Scan common directories and present any that contain multiple flows as a quick browse selection
- Offer a "Browse filesystem" option to let you navigate and select any flows on your device

### Lets see it in action

**Import automatically located `~/.node-red/flows.json` flows file**

![Screenshot of the Importing an Automatically located flows file during Device Agent Setup](https://flowfuse.com/changelog/2025/07/images/import-flows-quick-select.gif){dataZoomable=""}*Screenshot of the Importing an Automatically located flows file during Device Agent Setup*

**Using the "Browse filesystem" option to navigate the filesystem to chose a different flows file**

![Screenshot of Browsing the filesystem for flows file during Device Agent Setup](https://flowfuse.com/changelog/2025/07/images/import-flows-browsed.gif){dataZoomable=""}*Screenshot of Browsing the filesystem for flows file during Device Agent Setup*

We hope these new enhancements make the process of migrating existing Node-RED flows to FlowFuse even easier.


# FlowFuse Tables

As part of the FlowFuse v2.20.0 release we are adding an option for a Team level hosted relational database.

![Screenshot of the FlowFuse Tables onboarding wizard](https://flowfuse.com/changelog/2025/07/images/create-database.png){dataZoomable=""}*Screenshot of the FlowFuse Tables onboarding wizard*

Tools to create tables and to show sample data are included, but we will be iterating on these moving forward.

![Screenshot of Table Explorer](https://flowfuse.com/changelog/2025/07/images/table-data-sample.png){dataZoomable=""}*Screenshot of Table Explorer*

Paired with the Database is a new FlowFuse Tables node which will automatically pick up the credentials when deployed in FlowFuse Hosted Instance running on a v2.20.0+ Stack, or when running with the latest version of the FlowFuse Device Agent.

![Screenshot of Node-RED with FlowFuse Tables node](https://flowfuse.com/changelog/2025/07/images/tables-node.png){dataZoomable=""}*Screenshot of Node-RED with FlowFuse Tables Node*

The database is a Postgres instance and you will be able to connect 3rd party clients using the credentials provided.

This feature will be available to FlowFuse Cloud Enterprise Tier customers and to Enterprise Licensed Self Hosted customers on Kubernetes to start with, we hope to make it available to Docker Compose users in a future release.

It is currently marked as a [Beta Feature](https://flowfuse.com/handbook/engineering/releases/#beta-release) while we continue to iterate on adding new features and observe how it is used.


# Import blueprints directly into your existing instances

FlowFuse provides a growing [library of blueprints](https://flowfuse.com/blueprints/) that provide a great way to get started quickly with a pre-built solution across a range of scenarios.

With the 2.19 release of FlowFuse, instances that have been updated to the latest version can now import blueprints directly into their editor.

The Node-RED import dialog (`Ctrl-i` or the `import` menu option) now has a blueprints section. Under that you can browse the available blueprints by category and select one to import.

![Screenshot of the Node-RED import dialog](https://flowfuse.com/changelog/2025/07/images/import-blueprint.png){dataZoomable=""}*Screenshot of the Node-RED import dialog*

When you import a blueprint, you may get an error about 'unknown' nodes. This will be because the blueprint depends on Node-RED nodes you haven't currently got installed. You can check the [blueprint library](https://flowfuse.com/blueprints/) for details on what the blueprints require and then install them via the Palette Manager within Node-RED.

We recognise that isn't as smooth an experience as we'd like - but the good news is it's about to get much better. With the imminent Node-RED 4.1 release, the editor will be able to automatically install any missing modules for you. Keep an eye out for the 4.1 release announcement and update your instances to take full advantage.


# Simplified Applications Page with Summary Tiles

We’ve rolled out a redesigned **Applications Page** interface to give you sharper insight into instance status across hosted and remote deployments.

### Key Updates

- **Application Shortcuts Maintained**
  The existing shortcuts to **instances**, **devices**, **device groups**, **snapshots**, and **pipelines** have been retained in the new layout for easy access.
- **Summary Tiles for Each App**
  Instead of listing every instance individually, you now get compact summary tiles with counts of **Running**, **Error**, and **Not Running** instances for both hosted and remote groups. Visual layout is clean and instant to scan.
- **Grouped Instances by Status**
  Each application shows two separate tiles: one for hosted instances and one for remote. That way you see app health at a glance, without needing to drill into details.
- **Aggregate Status Tiles**
  Each status tile represents an aggregate count of instances in a given state (e.g. Running, Error). Clicking on a tile takes you to a filtered view of the underlying instances.

### Why This Matters

- Page load times have been significantly improved by reducing the number of rendered elements and simplifying data fetching.
- Cuts out clutter, no more scrolling through long lists.
- Quick status view helps you spot issues fast.
- Cleaner separation between hosted vs remote gives context instantly.

![Screenshot of the Simplified Applications page](https://flowfuse.com/changelog/2025/07/images/simplified-applications.png){dataZoomable=""}*Screenshot of the Simplified Applications page*


# Smart Suggestions

In conjunction with the release of Node-RED 4.1.0 and FlowFuse 2.20.0, we have added smart suggestions to the Editor.

When you drop a node onto the editor workspace, the upstream connected nodes in your flow are analysed and a next node suggestion is presented for quick insertion via the keyboard `TAB` key or the click of your mouse.
It presents up to 5 of the most common following nodes which can be cycled through using your keyboards `UP` and `DOWN` arrows, so even if the first suggestion isn't correct, it's very likely that the correct choice is only a key press away.

To achieve this, we processed thousands of real working flows and built a decision tree model for the greatest accuracy possible.

### Let's see it in action

![Demo of smart suggestions](https://flowfuse.com/changelog/2025/07/images/smart-suggestion.gif){dataZoomable=""}*Demo of smart suggestions*

We hope this new feature makes the process of writing flows for Node-RED flows in FlowFuse even easier.


# Team Plan Renamed to Pro Plan

:product-update-note

We've renamed our Team tier to Pro tier to better reflect what it's truly designed for: using Node-RED professionally to build applications, replace and augment software in your organization, and scale professional Node-RED deployments.

The Pro plan empowers developers and engineers to move beyond collaboration and into production-ready industrial applications that optimize operations and drive real business value.

All existing Team plan subscribers will automatically transition to Pro. Your applications, instances, and team configurations remain exactly the same.

What's new:

- A name that better represents professional Node-RED application development
- Clearer positioning for organizations ready to scale their Node-RED implementations

Ready to build professional Node-RED applications? \[Get started with Pro]\({% include "sign-up-url.njk" %}) or [contact us](https://flowfuse.com/contact-us) to learn more.


# Generate snapshot descriptions with AI

We’ve introduced a new feature: **AI-generated Snapshot Descriptions**. :br
When creating a snapshot, you can now generate a concise description of what it contains and why it was created.

This makes it easier to understand the purpose of a snapshot at a glance, especially when working in a team or looking back weeks later.

### How it works

When creating a snapshot, you’ll see a new “Generate with AI” option. :br
With one click, a suggested description is created for you, which you can accept as-is or edit before saving.

![Demo of generating snapshot descriptions](https://flowfuse.com/changelog/2025/08/images/snapshot-description-generation-hosted.gif){dataZoomable=""}:br*Demo of generating snapshot descriptions*

This feature is currently available for **hosted instances only**. Support for remote instances will follow shortly.


# AI Snapshot Descriptions Now Work with Remote Instances

We've extended **AI-generated snapshot descriptions** to **remote instances**.

Whether your remote instance is linked to an application or a hosted instance, you can now generate a smart, clear description of the snapshot with a single click.

### Two Flows, Same Outcome

Depending on how your remote instance is owned, the flow is slightly different:

![AI for application-owned remote instances](https://flowfuse.com/changelog/2025/08/images/device-llm-snapshot-description_application-owned.gif){dataZoomable=""}:br*AI for application-owned remote instances*

![AI for hosted-instance-owned remote](https://flowfuse.com/changelog/2025/08/images/device-llm-snapshot-description_instance-owned.gif){dataZoomable=""}:br*AI for hosted-instance-owned remote instances*

This rounds out our support for AI-generated snapshot descriptions.


# FlowFuse Remote Instance Performance Data

FlowFuse Device Agent version v3.6.0 combined with FlowFuse v2.21.0 allows you to monitor the CPU and Memory usage of Remote Instances

![Screenshot of Device Performance data](https://flowfuse.com/changelog/2025/08/images/device-performance.png){dataZoomable=""}*Screenshot of Device Performance data*

The view is available from the "Performance" tab on the Remote Instance page.

This feature is available to Enterprise customers on FlowFuse Cloud and to Enterprise licensed self hosting customers.


# Direct SSO Login

As part of FlowFuse release v2.21.0, self hosted Enterprise users will be able to enable direct SSO login from the FlowFuse login page.

![Screenshot of FlowFuse Login Page with SSO Direct Button](https://flowfuse.com/changelog/2025/08/images/direct-sso.png){dataZoomable=""}*Screenshot of FlowFuse Login Page with SSO Direct Button*

This can be enabled from the Admin Settings page. When enabled it will add a button for all SAML SSO configurations to the login page. These buttons bypass the email domain matching that would normally be used to select which SSO provider to use. This can be used when users use the same email domain but need to authenticate with different SSO providers.

![Screenshot of FlowFuse Admin Settings for Direct SSO](https://flowfuse.com/changelog/2025/08/images/direct-sso-config.png){dataZoomable=""}*Screenshot of FlowFuse Admin Settings for Direct SSO*


# FlowFuse Expert documents your flows

Recently, we introduced "Flows Explainer" to the FlowFuse Expert. It provides a concise description of the selected flows.
This turned out so well we thought "wouldn't it be good if the generated explanation could be persisted as built in documentation" so we added a single click option to add the documentation as a comment node to your flows.
We also provided a Copy to Clipboard button so you can grab it and add it to the Documentation section of a flow tab, node group or external documentation.

### Let's see it in action

![Demo of documenting flows with the Flows Explainer](https://flowfuse.com/changelog/2025/08/images/explainer-to-comment-node.gif){dataZoomable=""}*Demo of documenting flows with the Flows Explainer*

While this feature is just a simple *quality of life* addition, we are hopeful it is small touches like these that improve your daily workflow.


# FlowFuse MQTT

FlowFuse has offered a built in MQTT [Team Broker](https://flowfuse.com/docs/user/teambroker) since FlowFuse v2.10.0, but connecting to it still required manual configuration in your Node-RED instances through the core MQTT nodes.

Today, we are adding dedicated MQTT nodes that require no setup to use. Just add a FlowFuse MQTT Node to your Node-RED instance, deploy it & go.

Pretty much all of the capabilities of the Node-RED MQTT Nodes are present making it very straightforward and to get up and running in no time.

![Screenshot of Node-RED with FlowFuse MQTT nodes](https://flowfuse.com/changelog/2025/08/images/mqtt-nodes-1.png){dataZoomable=""}*Screenshot of Node-RED with FlowFuse MQTT Nodes*

![Screenshot of Node-RED with FlowFuse MQTT-in node edit panel](https://flowfuse.com/changelog/2025/08/images/mqtt-nodes-2.png){dataZoomable=""}*Screenshot of Node-RED with FlowFuse MQTT-in node edit panel*

To get the new FlowFuse MQTT Nodes in your Node-RED instance, you will need to be running the latest version of the FlowFuse Device Agent (V3.6.0 or greater) or a stack running with the FlowFuse launcher (V2.20.1 or greater) which will be released in the coming days.


# Configure HTTP CORS

Included in FlowFuse v2.21.0 is the ability to configure the HTTP CORS response for HTTP routes served by the Node-RED instances.

This includes routes from HTTP-in/HTTP-response nodes and the Node-RED Dashboard.

![Screenshot of Hosted Instance Security Settings](https://flowfuse.com/changelog/2025/08/images/http-cors.png){dataZoomable=""}*Screenshot of Hosted Instance Security Settings*

This feature will require the latest Stack version and uses will be prompted to upgrade if required.


# Export SubFlow as Node-RED module

Instances running the latest Node-RED version on FlowFuse v2.21.0 will now be able to export Node-RED SubFlows as Node-RED nodes.

This is done from the Node-RED editor using a custom sidebar.

![Screenshot of Node-RED with the SubFlow export sidebar](https://flowfuse.com/changelog/2025/08/images/subflow-export.png){dataZoomable=""}*Screenshot of Node-RED with the SubFlow export sidebar*

The nodes are added to the Team's Library of Custom Nodes and can be installed into any of the Team's Node-RED instances from the Catalogue generated by the Team Library.

![Screenshot of Node-RED Manage Palette showing new SubFlow modules](https://flowfuse.com/changelog/2025/08/images/subflow-catalogue.png){dataZoomable=""}*Screenshot of Node-RED Manage Palette showing new SubFlow modules*

This feature is available to FlowFuse Cloud Pro and Enterprise teams and to Enterprise Self hosting users.


# FlowFuse Tables with a little help from the Assistant

The new [Tables](https://flowfuse.com/blog/2025/07/flowfuse-release-2-20/#introducing-flowfuse-tables) we introduced in FlowFuse 2.20.0 feature may be still in Beta but to help you make the most of it we have added a codelens to the query editor to help you get your queries written faster.

Behind the scenes, when you ask for assistance, we gather schema info and include this in the process of making a prediction as to the best tables and fields to use for in the query.

### Let's see it in action

![Demo of table node with assistance](https://flowfuse.com/changelog/2025/08/images/query-assist.gif){dataZoomable=""}*Demo of table node with assistance*


# Allow SSO groups to be shared with the Node-RED Dashboard

A new flag has been added to the SAML SSO configuration to allow a user's group membership to be included in the profile information included when FlowFuse Authentication is used with the Node-RED Dashboard v2.

Shown here is the content of the `_client` object attached to messages generated by the Dashboard nodes.

```json
{
    "user": {
        "username": "ben-example_com",
        "email": "ben@example.com",
        "image": "https://forge.example.com/avatar/YmVu",
        "name": "Ben",
        "userId": "r3VG59G85J",
        "role": "owner",
        "SSOGroups": [
            "FlowFuse",
            "ff-development-owner",
            "test_ff-development-owner_test"
        ]
    },
    "socketId": "NA7eDLuWbR6wmCpSAAAF",
    "socketIp": "192.168.1.56"
}
```

The new key `SSOGroups` includes the list of Groups passed to the SSO configuration by the SAML backend and can be used by the Dashboard to control what information is shown to the user.

More details about how to create mutli-user Node-RED Dashboards can be found [here](https://dashboard.flowfuse.com/user/multi-tenancy){rel="&#x22;nofollow&#x22;"}

SSO is available to Enterprise teams on FlowFuse Cloud. Contact support if you would like this feature to be enable for your team.


# FlowFuse Expert can help you write code

More goodness has been added to the FlowFuse Expert by way of inline suggestions as you type.
Initially, we have added support for the Function Node, Tables Query Node and the Dashboard Template Node.
It is contextually aware so will offer suggestions applicable to what it sees and what is already written.

### Let's see it in action

![Demo of function node with inline completions](https://flowfuse.com/changelog/2025/09/images/inline-assist-function-node.gif){dataZoomable=""}
\_Demo of function node with inline completions

![Demo of tables query node with inline completions](https://flowfuse.com/changelog/2025/09/images/inline-assist-query-node.gif){dataZoomable=""}
\_Demo of tables query node with inline completions

![Demo of dashboard template node with inline completions](https://flowfuse.com/changelog/2025/09/images/inline-assist-template-node.gif){dataZoomable=""}
\_Demo of dashboard template node with inline completions

This will be made availabe to our Pro and Enterprise users in remote and hosted instances in the next update however
if you want to give it a go right away, you can update the FlowFuse Expert in the Node-RED Palette Manager today.


# No more @flowforge/flowforge-device-agent releases

When we changed company name from FlowForge to FlowFuse we continued to publish the Device Agent under the old package name `@flowforge/flowforge-device-agent` as well as the new package name `@flowfuse/device-agent`.

The current version 3.6.1 will be last release under the old package name.

The latest version can be found on npmjs.org [here](https://www.npmjs.com/package/@flowfuse/device-agent){rel="&#x22;nofollow&#x22;"}.

To upgrade please uninstall `@flowforge/flowforge-device-agent` using

```text
npm uninstall -g @flowforge/flowforge-device-agent
```

(You may need to prefix this command with `sudo` on Unix platforms)

and install `@flowfuse/device-agent`.

```text
npm install -g @flowfuse/device-agent
```

(again you may need to prefix this with `sudo` on Unix platforms)

The replacement package includes a migration binary called `flowforge-device-agent` which can still be used to start the new package.


# Streamlined Snapshot Management

We’ve redesigned how you interact with Hosted Instance **snapshots** by bringing all related actions into one place. :br
Instead of jumping between different menus, you can now manage everything directly from a single consolidated view.

This update keeps all existing functionality, but makes it easier and faster to find and use.

![Snapshot interaction redesign](https://flowfuse.com/changelog/2025/09/images/revised-instance-snapshots.gif){dataZoomable=""}:br*Streamlined snapshot management*


# Capture Async API data from FlowFuse Team Broker

The FlowFuse Team Broker now includes automatically curated smart suggestions for the published payloads in each topic.

You can run this by simply toggling on the toggle found in the Topic Hierarchy view. This will run for 24 hours.

![](https://flowfuse.com/changelog/2025/09/images/team-broker-schema.png){dataZoomable=""}*Team Broker Schema Capture*

Our agent will monitor for any payloads published on your broker in that time, and offer smart suggestions on data structure found. You can review these suggestions with the FlowFuse user interface, and confirm them where appropriate.

Once confirmed, the Async API documentation can be viewed by clicking on the "Open Schema" button. This means that your whole team can be aligned when building with your UNS.

This functionality was previously only available to 3rd party MQTT brokers using the MQTT Schema Agent, it is enabled on FlowFuse Cloud and will be available to Enterprise Licensed Self Hosted customers from v2.22.0.


# Application-level access control for Enterprise teams

One of the super-powers FlowFuse brings is its role-based access control that gets applied across the team. This allows teams to have users with different levels of access to the Node-RED instances - from full editor access, to read-only access, to only being able to access the dashboards the instances create.

We've pushed this one step further today for Enterprise teams, allowing them to set a user's role on a per-Application basis. This finer-grained control gives teams more flexibility in how they can secure their resources.

For example, a team could create an Application dedicated to their production systems, with a limited set of users able to make changes - whilst having a Development application that is accessible to a broader group of user.

The roles for an application can be modified under the 'User Access' section of its settings. It shows what roles each user has for the application and where any application-specific overrides have been set. Here you can see I've reduced Ben to a Dashboard role for this application - sorry Ben!

As with managing the top level roles in a team, only Team Owners are able to modify the roles within an application.

![Application RBAC Settings](https://flowfuse.com/changelog/2025/10/images/application-rbac.png){dataZoomable=""}:br*Application RBAC Settings*


# Easier Access to Bulk Device Group Management

Managing device groups for multiple Remote Instances is now easier to handle. Bulk management already existed but was
difficult to use efficiently at larger scale.

This update refines that process. You can select multiple Remote Instances from the team or application remote instances
pages and bulk assign them to device groups with fewer steps.

The improved workflow reduces friction when organizing devices by location, environment, or function.

![Bulk Device Group Management Interface](https://flowfuse.com/changelog/2025/10/images/bulk-assign-device-groups.gif){dataZoomable=""}:br*Bulk Device Group Management showing multi-select capabilities and group assignment options*


# Duplicate Instances Across Different Applications

As of today, you can now duplicate a hosted instance into a different application within your team.

It is a small (but important) improvement that just just makes things that little bit easier.


# Import flows during instance creation

Getting started with FlowFuse just became easier! When creating a new Node-RED instance, you can now import your existing flows directly during the setup process.

This new capability allows you to jumpstart your FlowFuse journey by bringing in flows you've already developed, whether they're from a local Node-RED installation, exported from another system, or shared by a colleague.

The import process is flexible and user-friendly:

- **File upload**: Simply select and upload a JSON file containing your flows
- **Direct paste**: Copy and paste flow JSON directly into a text area
- **Live preview**: See your flows rendered in real-time as you import them

The flows import step seamlessly integrates with the existing multi-step instance creation workflow. You can choose to start with a blueprint from our library or import your own flows - giving you multiple pathways to get productive quickly.

This enhancement is particularly valuable for teams looking to migrate existing Node-RED projects to FlowFuse or developers who want to quickly prototype with flows they've developed elsewhere.

## Important considerations

When importing flows, keep these key points in mind:

- **Flow validation**: Imported flows aren't checked for validity, so invalid nodes may prevent your instance from starting
- **Third-party nodes**: External nodes aren't installed automatically but can be added once the instance is running
- **Credentials and secrets**: These aren't imported with flows but can be reconfigured after deployment
- **Environment variables**: Any required variables must be manually added to your environment after setup

Always verify the reliability of imported flows and avoid copying flows from untrusted sources.

To try it out, simply create a new instance and look for the new "Flows" step in the creation wizard!

![Demo importing flows when creating a Hosted Instance](https://flowfuse.com/changelog/2025/10/images/import-flows-on-instance-creation.png){dataZoomable=""}:br*Demo importing flows when creating a Hosted Instance*


# FlowFuse MCP Server Nodes

We’re excited to introduce **FlowFuse MCP Server Nodes**, a new contrib package that brings MCP Tools, Resources, and Prompts straight into Node-RED. With just a few nodes, you can design custom MCP-powered automations, connect dynamic resources, and return responses seamlessly in your flows. Whether you’re prototyping or extending integrations, these nodes make it faster than ever to put MCP to work in your applications.

Over the coming weeks, we’ll share use cases and demos to inspire you, but in the meantime, we’ve included some sample flows you can access directly in Node-RED via the import menu (`CTRL`+`I`) and some additional links below.

### What is MCP?

The &#x2A;*Model Context Protocol (MCP)** is an emerging open standard for connecting AI models with tools and data sources in a structured way. It defines how prompts, resources, and responses should be exchanged, making it easier to build reliable and reusable AI-powered workflows.

### Why is MCP important?

As AI adoption grows, developers need consistent ways to integrate models into real-world systems. MCP helps standardize this process, reducing boilerplate and ensuring interoperability across tools and platforms. With Node-RED support, FlowFuse makes it easier than ever for developers to experiment with MCP, build production-ready flows, and unlock the potential of AI-driven automation.

### Screenshots

![New MCP Nodes](https://flowfuse.com/changelog/2025/10/images/mcp-nodes.png){dataZoomable=""}:br*New MCP Nodes*

FlowFuse customers can install the MCP Server nodes today via the Node-RED Palette Manager from the **FlowFuse Nodes** catalog

![alt text](https://flowfuse.com/changelog/2025/10/images/mcp-nodes-in-catalog.png)

### Additional links

- [Blog article](https://flowfuse.com/blog/2025/10/building-mcp-server-using-flowfuse/)
- [Youtube demonstration video](https://www.youtube.com/watch?v=troUvaF8V68){rel="&#x22;nofollow&#x22;"}


# FlowFuse AI Nodes

We’re excited to introduce **FlowFuse AI Nodes**, a new contrib package that brings the ONNX Runtime to Node-RED.

### What is ONNX?

ONNX (Open Neural Network Exchange) is an open format built to represent machine learning models. It provides an interoperable framework for AI developers to use models across different frameworks and tools.

Sounds great, right? So what does this mean for you?

You can now run pre-trained machine learning models directly within your Node-RED flows using the new FlowFuse AI Nodes.
There are hundreds of pre-trained models available in the [ONNX Model Zoo](https://onnx.ai/models/){rel="&#x22;nofollow&#x22;"} or from [Hugging Face](https://huggingface.co/models?library=transformers.js,onnx&sort=trending){rel="&#x22;nofollow&#x22;"}, covering a wide range of applications including image classification, object detection, natural language processing, Text to Speech, and more.

### What can you do with FlowFuse AI Nodes?

In this first release, the FlowFuse AI Nodes package includes the following nodes:

- **ONNX Inference Node**: A bare node to run any model (including your own trained ONNX models). Just upload the model file and feed in the input data to get predictions.
- **Image Classification Node**: Classify images using pre-trained models like MobileNet, ResNet, or even use your own.
- **Object Detection Node**: Detect objects in images using models like YOLOv5, SSD, or your own.
- **Image Depth Estimation Node**: Estimate depth information from images.

With FlowFuse AI Nodes, you can easily integrate ONNX models into your Node-RED flows, enabling powerful AI capabilities without the need for extensive coding or machine learning expertise.

### How to Get Started

FlowFuse customers can install the new AI nodes today via the Node-RED Palette Manager from the FlowFuse Nodes catalog

We have included example flows directly inside the package to help you get started quickly.
Just hit `CTRL-I` in the Node-RED editor to import the example flows from the FlowFuse AI Nodes package.

Additionally, we have created a blog post detailing how you can train a simple image classification model to accompany the advanced example flow included in the package. You can read all about it here: [Deploy Custom-Trained AI Models: Using ONNX with Node-RED and FlowFuse](https://flowfuse.com/blog/2025/10/custom-onnx-model/)

### Screenshots

Here are a selection of screenshots of the built-in demo flows in action

![Running your own custom trained ONNX Model](https://flowfuse.com/changelog/2025/10/images/ai-nodes-onnx-node-custom-model.png){dataZoomable=""}:br*Running your own custom trained ONNX Model*

![Using a Text-to-Speech-model](https://flowfuse.com/changelog/2025/10/images/ai-nodes-onnx-node-tts.png){dataZoomable=""}:br*Using a Text-to-Speech-model*

![Performing Image Depth Estimation](https://flowfuse.com/changelog/2025/10/images/ai-nodes-image-depth-node.png){dataZoomable=""}:br*Performing Image Depth Estimation*


# Device Group Management from Settings Page

Managing which device group your Remote Instance belong to just got a easier. Previously, if you wanted to move a device to a different group, you had to identify the group the Remote Instance belongs to, remove it, then find the group to assign it to, edit that group and add it. This was not optimal.

With this update, you can now see which group a Remote Instance belongs to directly from the overview page, and easily reassign it to a different group from the settings page without the hassle of searching through your entire group structure.

![Device Group Management Interface](https://flowfuse.com/changelog/2025/10/images/settings-page-device-group-management.png){dataZoomable=""}:br*Device Group Management Interface showing current group and reassignment options*


# FlowFuse Expert Update

The FlowFuse Expert just got a major improvement: you can now start a conversation on the flowfuse.com homepage and continue it inside of FlowFuse and the Node-RED editor!

Now, when you use the Expert, you can bring your application-building instructions with you as you navigate.

This work involved major and important changes to the Expert UI, and brings us even closer to being able to build Node-RED flows using natural language inputs.

Give it a try!

![Option to continue chat in FlowFuse](https://flowfuse.com/changelog/2025/11/images/continue.png)*Demo of option to continue chat in FlowFuse*

![In-App Expert UI](https://flowfuse.com/changelog/2025/11/images/in-app.png)*Here is the in-app UI of the FlowFuse Expert*


# Node.js v20 Minimum Version Requirement

**FlowFuse v2.24.0 requires Node.js v20 or higher.** If you are running an older version, you will need to upgrade Node.js before updating FlowFuse.

Node.js v18 reached end of life in April 2025 and no longer receives security updates. This change ensures FlowFuse continues to run on a supported and secure runtime.

To check your current version, run `node --version`.


# SSO control over Session life

Customers on FlowFuse Cloud can now request custom Session Life times and Idle times. This allows the default times to be adjusted to match any in house policies that may be in place.

![SSO Session Expiry and Idle settings](https://flowfuse.com/changelog/2025/11/images/sso-expiry-idle.png)*SSO Session Expiry and Idle settings*

For existing FlowFuse Cloud customers please contact support if you would like to make changes to you existing configuration.

This will be available to Self Hosted customers in v2.24.0


# FlowFuse Expert: Now with MCP-Powered Insights

Recently, we introduced [MCP Server nodes](https://flowfuse.com/changelog/2025/10/mcp-nodes/) which gave you the ability to infuse your Node-RED flows and data with AI. Today, we have given the FlowFuse Expert new powers by adding support for Model Context Protocol (MCP). This allows you to interact directly with your instances, tools, and data.

### Bridging the Gap Between AI and Your Data

By switching to the new Insights mode, the Expert gains the ability to use the MCP tools and resources you’ve built using FlowFuse MCP Server Nodes. This means you can now ask the Expert to analyze real-time data from your flows, query external databases, or trigger specific actions across your infrastructure.

### How to get started:

- **Deploy MCP Nodes**: Add MCP Tools or Resources to your Node-RED flows using our MCP Server nodes.
- **Switch to Insights**: Open the FlowFuse Expert interface and use the Mode Selector to switch from "Chat" to "Insights."
- **Select your Server**: Choose the MCP Server you want to include in your session.
- **Gain Insights**: Ask questions about your live process data, system status, or connected databases.

Give it a try and see what your data has to tell you!

![FlowFuse Expert Insights](https://flowfuse.com/changelog/2025/12/images/ff-expert-mcp-demo.gif){dataZoomable=""}*Demonstrating FlowFuse Expert Insights*

*Note: This feature is currently in Beta. We are actively expanding these capabilities and would love to hear how you are using MCP to extend your systems.*


# Scheduled Maintenance Mode

:product-update-note

Included in the FlowFuse 2.25.0 release is the ability to schedule times and days of the
week for Hosted Node-RED instances to upgrade to the latest available version.

This ensures that fixes and security updates are applied promptly.

![Maintenance Section of Instance Settings](https://flowfuse.com/changelog/2025/12/images/scheduled-maintenance.png)*Maintenance Section of Instance Settings*

You can select multiple days of the week and an hour of the day the update will take
place. The restart will be targeted in the first 30 minutes of the selected hour.

As well as scheduling upgrades, you can also enable scheduled restarts even if not update
is available which may be useful to help with ensuring things run smoothly.

Self Hosted users can configure default restart/upgrade times at a TeamType level,
FlowFuse Cloud Starter Tier users will have this enabled by default and it will run,
at weekends.

![TeamType Scheduled Maintenance Settings](https://flowfuse.com/changelog/2025/12/images/scheduled-maintenance-admin.png)*TeamType Scheduled Maintenance Settings*


# Device Agent Docker Containers updated

We have started to see some Node-RED nodes dropping support for NodeJS v18. This is causing problems for users of our Device Agent docker container as that is still based on NodeJS v18.

To help move things forward, with the v3.7.2 release of the Device Agent, we are now publishing separate container images for both v18 and v20 under different tags.

The `latest` tag will continue to point to the NodeJS v18 version for now for backwards compatibility. The next major release of the device agent will update the `latest` tag to a newer NodeJS version - and may require a migration step if you are using the module cache feature. We'll share more details when that release arrives.

With this update, the following tags are now available:

## NodeJS 18

- flowfuse/device-agent\:latest
- flowfuse/device-agent\:latest-18
- flowfuse/device-agent\:v3.7.2
- flowfuse/device-agent\:v3.7.2-18

## NodeJS 20

- flowfuse/device-agent\:latest-20
- flowfuse/device-agent\:v3.7.2-20


# FlowFuse Expert: Enhanced Palette Integration

The FlowFuse Expert recently gained the ability to suggest and install **node packages** directly within your workflow (see our previous post on [FlowFuse Expert: Integration with Node-RED](https://flowfuse.com/changelog/2026/01/ff-expert-nr-actions/)).

Today, we've streamlined this experience. The Expert now detects if a suggested node is already present in your instance. Instead of a showing the "Install" button, you’ll now see a &#x2A;*"Manage"** button that takes you directly to the Palette Manager.

![FlowFuse Expert integration with the Palette Manager](https://flowfuse.com/changelog/2026/01/images/ff-expert-manage-palette.png){dataZoomable=""}*FlowFuse Expert integration with the Palette Manager*

This improvement reduces friction when updating or configuring your existing nodes. These workflow integrations are just the beginning of our plans for the FlowFuse Expert. We're excited to see how much time they save you!


# FlowFuse Expert: Integration with Node-RED

The FlowFuse Expert just got a lot more hands-on with your Node-RED editor:

- **Streamlined Node Installation:** When the Expert suggests a node module, it can now automatically open the Palette Manager and filter for the correct package, leaving you just one click away from installation.
- **Direct Flow Imports:** When the Expert provides demo flows, you no longer need to copy-paste JSON. The Expert can now inject those flows directly into your editor, ready for deployment.

![FlowFuse Expert Install Node](https://flowfuse.com/changelog/2026/01/images/ff-expert-install-node.gif){dataZoomable=""}*FlowFuse Expert integration with the Palette Manager*

These workflow integrations are just the start of our plans for the FlowFuse Expert. We’re excited to see how much time these save you!


# FlowFuse Expert: Palette Queries

We are continuing to evolve the FlowFuse Expert by giving it deeper integration into your Node-RED environment. Starting today, the Expert has **Palette Awareness**.

You can now ask the Expert about your installed nodes, versions, and available updates without leaving the chat interface or needing to manually input said context. For example:

- Do I have any nodes installed that can send Emails?
- Are my palette nodes up to date?
- Are any nodes on my palette disabled?
- Can you suggest a node package that would replace this complex function code?
- or any question related to your palette.

This is one of several steps we are taking to bring additional context directly into your FlowFuse Expert to augment its capabilities and improve your workflow.

![FlowFuse Expert integration with the Palette](https://flowfuse.com/changelog/2026/01/images/ff-expert-palette-context.gif){dataZoomable=""}*FlowFuse Expert integration with the Palette*


# FlowFuse Expert: Ask about your flows

Need help with a specific flow?

The FlowFuse Expert now has the ability to include your flow selection as context, allowing you to ask specific questions about your logic and configuration.

![FlowFuse Expert with flows in context](https://flowfuse.com/changelog/2026/01/images/ff-expert-flows-in-context.gif){dataZoomable=""}*FlowFuse Expert with flows in context*

We are continuously adding new features to improve your development workflow, with more updates for the FlowFuse Expert on the horizon. We hope this makes your building experience even smoother.


# FlowFuse Expert: MCP-Powered Insights with RBACs

Following on the the introduction of [FlowFuse Expert MCP-Powered Insights](https://flowfuse.com/changelog/2025/12/ff-expert-mcp-insights/) we have added annotations to the FlowFuse MCP nodes and linked them up with the FlowFuse roles.
This permits a level of control over who can access what. This is just a first step, we will be working in the area over the next few iterations.

### MCP Tools Node

To facilitate a level of role based access control in the Expert, we have leveraged the new Granular RBACs and MCP annotations to introduce 2 means of filtering and control:

1. By [application](https://flowfuse.com/docs/user/concepts/#application) - as introduced in FlowFuse 1.5
2. By pre-defined role level mapping to the annotation hints. For instance, users with a 'Viewer' role will only be exposed to tools marked with the Read Only hint, while Destructive tools are reserved for 'Owners'. The screenshot below indicates more clearly what this mapping is.

To facilitate this, we have the next version of our [MCP Server Nodes](https://flowfuse.com/node-red/flowfuse/mcp/) will introduce the 4 MCP standard annotations:

- **Read Only Hint**: Lets the MCP Client know that the tool is read-only and does not modify any data or state. This hint can be used by LLMs to understand that invoking this tool will not have side effects, making it safe for exploratory queries or information retrieval.
- **Destructive Hint**: Lets the MCP Client know that the tool performs destructive actions that may modify or delete data. This hint can be used by LLMs to exercise caution when invoking this tool, as it may have irreversible effects.
- **Idempotent Hint**: Lets the MCP Client know that the tool is idempotent, meaning that multiple invocations with the same parameters will have the same effect as a single invocation. This hint can be used by LLMs to understand that it is safe to retry or repeat calls to this tool without causing unintended side effects.
- **Open World Hint**: Lets the MCP Client know that the tool operates in an open-world context, meaning it may interact with external systems or data sources beyond the immediate environment. This hint can be used by LLMs to understand that invoking this tool may involve uncertainties or dependencies on external factors.

These annotations are not exclusive to FlowFuse or FlowFuse Roles, they also are useful for your own Agents and LLMs.

*Note: Hints do not enforce behavior. The actual behavior of the tool depends on how it is used in your flows*

![MCP Server Tool Node with new annotations](https://flowfuse.com/changelog/2026/01/images/mcp-annotations.png){dataZoomable=""}*MCP Server Tool Node with new annotations*

*Note: This feature is currently in Beta. We are actively expanding these capabilities and would love to hear how you are using MCP to extend your systems.*


# FlowFuse Expert: MCP-Powered Insights

FlowFuse Expert Insights just got a little bit better.

### What is FlowFuse Expert Insights?

In case you are new to this feature, checkout out some of our previous blog posts:

- [MCP-Powered Insights](https://flowfuse.com/changelog/2025/12/ff-expert-mcp-insights/)
- [MCP-Powered Insights with RBACs](https://flowfuse.com/changelog/2026/01/mcp-rbacs/)
- [Integration with Node-RED](https://flowfuse.com/changelog/2026/01/ff-expert-nr-actions/)

### What's new?

With this update, the MCP servers you protected behind FlowFuse User Authentication can now be accessed and queried in the FlowFuse Expert too.

*Note: The FlowFuse Expert Insights feature is currently in Beta. We are actively expanding its capabilities. We would love to hear how you are using MCP to extend your systems.*


# Set Node.js Options for Remote Instances

FlowFuse Device Agent v3.8.1 adds support for setting Node.js command line arguments for Remote Instances.

This allows things like:

- Setting the Node.js heap size for memory-intensive flows
- Enabling `--use-openssl-ca` (Linux) or `--use-system-ca` (Windows and macOS) to use private CA certificates

Node.js options can be configured in two ways:

### 1. Via the device agent command line

Use the `--node-options` argument. This argument may be specified multiple times:

```bash
flowfuse-device-agent -c /opt/flowfuse-device-agent/device.yml \
    --node-options='--max-old-space-size=256' \
    --node-options='--use-openssl-ca'
```

### 2. Via the `device.yml` file

Add a `nodeOptions` section:

```yaml
deviceId: xxxxxxx
forgeURL: https://app.flowfuse.com
token: xxxxxxxx
credentialSecret: xxxxx
nodeOptions:
- '--max-old-space-size=256'
- '--use-openssl-ca'
```

For more details, see [Configuring Node.js Options](https://flowfuse.com/docs/device-agent/running/#configuring-nodejs-options).


# FlowFuse Expert: Helping you make sense of your debug log

As a flow developer, you know how frustrating it can be to have a bug or issue in your flows. You add a ton of debug nodes and add warning alerts to your functions to try and help you track it down. The logs can be a great source of information but you still need to figure out why it is happening! Why am I getting this error? Where did this log come from?

Now, you can ask the Expert!

We have added the ability to include individual log entries and a quick-add selection on the Resource Selector. Adding these logs alongside the related flows can further focus the AI on the issue and help you solve it.

**Key Highlights:**

- Laser Focus: Select individual log entries to provide specific context.
- Quick Add: Use the Resource Selector button to instantly pull in logs.

![FlowFuse Expert Debug Log Context in Action](https://flowfuse.com/changelog/2026/02/images/expert-debug-context.gif){dataZoomable=""}*FlowFuse Expert Debug Log Context in Action*

![FlowFuse Expert Focused Debug Log Context](https://flowfuse.com/changelog/2026/02/images/expert-debug-log-specific.gif){dataZoomable=""}*FlowFuse Expert Focused Debug Log Context*

We are sure you will love this feature - and there is more to come too!

For more details, see [Debug Context](https://flowfuse.com/docs/user/expert/chat/#debug-context).


# FlowFuse Expert: Never Miss an Update

The Expert now shows a banner in the chat area when a newer version is available. One click and you are up to date.

FlowFuse Expert is updated regularly with new capabilities. This makes sure you always know when there is something new to try, without having to check manually.

![FlowFuse Expert update banner](https://flowfuse.com/changelog/2026/02/images/ff-expert-update-banner.gif)*FlowFuse Expert lets you know when an update is available*

For more details, see [Keeping Expert up to date](https://flowfuse.com/docs/user/expert/chat/#keeping-expert-up-to-date).


# HA Hosted Instance Rolling Restart

As part of FlowFuse v2.27.0 release the behavior of Hosted Node-RED instances with HA enabled has been updated to reduce the down time experienced.

Any action that triggers a restart of the Node-RED instance (manually triggered or as part of a Pipeline deploy) will now restart them in sequence rather than in parallel. This means that there should be no down time for this instance.

This feature is available to Enterprise Licensed Self Hosted users and Enterprise tier users of FlowFuse Cloud.


# Immersive Mode for Remote Instances

You can now access **Immersive Mode** when working with **Remote Instances**.

Immersive Mode gives you **at-a-glance instance stats** alongside the editor, while also enabling the **FlowFuse Expert** to help speed up development and debugging, especially when you’re working on the edge with remote devices.

Prefer the classic experience? The existing **plain** connection flow is still available: clicking the **Open Editor** dropdown selector includes an alternative option to be able to open the editor in the non-immersive mode.

![Immersive Mode on a Remote Instance](https://flowfuse.com/changelog/2026/02/images/remote-instance-immersive.gif){dataZoomable=""}*Immersive Mode accessed from a remote instance*


# Restoring snapshots to developer-mode Remote Instances

Device Agent version 3.8.0 has been released which brings a significant workflow improvement when editing your flows.

When the ability to remotely edit flows was introduced - known as 'developer mode' - we blocked the ability to push snapshots to a remote instance whilst in this mode. This protection makes sense when you're working on a remote instance, but still need to push updates out to the rest of your fleet through a pipeline deployment - you don't want the deployment from overwriting the work you're in the middle of.

However, there are cases where you want to rollback changes you've been making to a remote instance. Previously that would involve taking the instance out of developer mode, restoring the snapshot, then putting it back into developer mode to continue working. This is a lot of unnecessary steps and not an obvious workflow.

With the new v3.8.0 release of the Device Agent, it is now possible to manually restore snapshots without leaving developer mode:

- Open the Version History tab for the Remote Instance and switch the Snapshots view
- Click on the snapshot you want to use
- Click on the restore button in the snapshot sidebar

The existing protection that blocks pipeline-driven deploys of snapshots is still in place.

![Restoring a snapshot to a Developer-Mode Remote Instance](https://flowfuse.com/changelog/2026/02/images/snapshot-restore.png){dataZoomable=""}*Restoring a snapshot to a Developer-Mode Remote Instance*


# Azure DevOps Pipeline support

[DevOps Pipeline](https://flowfuse.com/docs/user/devops-pipelines) Git Stages now support Azure DevOps repositories alongside GitHub.

If your team already uses Azure DevOps for CI and code review, you can now push and pull Snapshots directly as part of that workflow, no need to manage your Node-RED flows outside your existing tooling.

Add Personal Access Tokens under Team Settings → Integrations

![Dialog to create a new Azure DevOps Token](https://flowfuse.com/changelog/2026/03/images/azure-token.png)*The Azure DevOps token dialog under Team Settings → Integrations*

Pro and Enterprise customers on FlowFuse Cloud and Enterprise licensed Self Hosted users can use Azure DevOps repositories in their Pipelines from v2.29.


# Developer Mode Now Accessible from the Immersive Editor

The Developer Mode tab is now available directly in the immersive editor drawer when working with remote instances. You can toggle auto snapshot and create snapshots without leaving the editor.

![Developer Mode tab in the immersive editor drawer](https://flowfuse.com/changelog/2026/03/images/developer-mode-in-editor.png)&#x2A;The Developer Mode tab now appears directly in the immersive editor drawer, with options to create a snapshot and manage device flows.*

Previously, accessing Developer Mode meant opening a second browser window and navigating to the standalone device view, breaking your flow inside the editor and adding unnecessary friction, especially when working through a staged dev, test, and promote rollout.

This feature is available to Enterprise tier users of FlowFuse Cloud and Enterprise Licensed Self Hosted users from v2.29.


# Embedded Editor Now Shows Active Tab

Now the browser tab title updates as you navigate the embedded editor. If you're working on a tab called "Sensor Flow", your browser will show `Node-RED: Sensor Flow - FlowFuse`. This works for both hosted and remote device instances, and also updates when you navigate into a subflow.

If you work with multiple editors open at once, you can now tell exactly what's open in each tab without clicking through.

![Browser tab showing "Node-RED: Flow 1 - FlowFuse" after the update](https://flowfuse.com/changelog/2026/03/images/browser-title-after.png)&#x2A;The browser tab title showing "Node-RED: Flow 1 - FlowFuse" after navigating to the Flow 1 canvas tab.*

Previously, the title stayed generic, something like `Instance - Editor - FlowFuse`, regardless of which canvas tab was active. If you had multiple embedded editors open in different browser tabs, there was no way to tell them apart at a glance.

![Browser tab showing the old generic title "Hosted Instance - Expert - FlowFuse"](https://flowfuse.com/changelog/2026/03/images/browser-title-before.png)&#x2A;The old generic title, showing "Hosted Instance - Expert - FlowFuse" regardless of which canvas tab was open.*

This feature requires **Node-RED Assistant v0.12.0** or later. If you are on an older version of the assistant, the title will not update.

This change is live on FlowFuse Cloud. Self-Hosted users will receive it in the next release (v2.29).


# Updated: Upcoming Scheduled Server Maintenance on March 28th, 2026

:product-update-note

As part of our ongoing efforts to maintain our infrastructure, we need to update some of our servers that host Node-RED instances.

This will require restarting any hosted Node-RED instances running on those servers, leading to a short downtime whilst they restart. Remote instances on the edge are unaffected.

**We will complete this migration during a 2 hour maintenance window starting at 8am UTC on Saturday 28th March 2026.**

Note: the original version of this post had the incorrect date. The mainteance is scheduled for Saturday 28th March.

### Will my instances be affected?

If your instance was created after 11th March 2026, or has been updated to the 2.28 release, it will already be running on the new servers.

Otherwise, you can take action to migrate your instance before the scheduled maintenance window at your own convenience.

If you manually suspend and restart your instance, or upgrade to 2.28 at any time before the maintenance window, your instance will not need to be restarted and no further action will be needed.

You can find the "Suspend" option from the "Actions" drop down menu on the Instance Overview page. Once the Instance reports being in the Suspended state, you can select "Start" from the same drop down menu.

We will be emailing notifications to all team owners who have instances that require a restart.

### Enabling Scheduled Maintenance Mode

Keeping instances up to date is an important task to ensure they are running with the latest features and security fixes. FlowFuse provides the ability to select a time for updates to be automatically applied to your instances. You pick which day of the week and time the platform can schedule updates in. This removes the burden for keeping things up to date.

On FlowFuse Cloud, Starter teams already have this feature enabled for their instances to apply updates at the weekend.

Pro and Enterprise teams can opt-in on the Instance Settings - Maintenance page.

More information is available in the [scheduled maintenance changelog entry](https://flowfuse.com/changelog/2025/12/scheduled-maintenance/).


# View Snapshot Details in the Immersive Editor

You can now open snapshot details from inside the immersive editor. Previously, clicking a snapshot from the Version History timeline or Snapshots list had no effect in the editor, the detail view was only available from the instance page in FlowFuse.

![Snapshot toggle inside the immersive editor](https://flowfuse.com/changelog/2026/03/images/snapshot-toggle.png)&#x2A;Access snapshots from the Version History timeline or Snapshots list inside the editor.*

Snapshot details now open in a modal inside the immersive editor, so you can review and manage snapshots without leaving your editing session. The modal contains the same information as the snapshot detail view on the instance page.

![Snapshot detail modal open inside the immersive editor](https://flowfuse.com/changelog/2026/03/images/snapshot-modal-view.png)&#x2A;Snapshot details open in a modal inside the immersive editor.*

This feature is available to all FlowFuse Cloud users and all Self Hosted users from v2.29.


# FlowFuse expert action links

When interacting with the FlowFuse expert, you might be asked to search flows, select a node, or edit a node.
Previously, this was presented as a set of text instructions.
As of today, whenever possible, the Expert will provide clickable action links that will perform the operation for you.

![Selecting and editing nodes](https://flowfuse.com/changelog/2026/04/images/expert-action-links-select-edit.gif){dataZoomable=""}&#x2A;Selecting and editing nodes.*

![Searching your flows](https://flowfuse.com/changelog/2026/04/images/expert-action-links-search.gif){dataZoomable=""}*Searching your flows*

This feature requires **Node-RED Assistant v0.12.0** or later.

This change is live on FlowFuse Cloud. Self-Hosted users will receive it in the next release (v2.29).


# Hosted Instances know their own URL

Your hosted instance now knows its own URL. The `FF_INSTANCE_URL` [environment variable](https://flowfuse.com/docs/user/envvar/#standard-environment-variables) is automatically available to your flows, so you can reference the instance's address without hardcoding it.

![List of Hosted Instance Environment Variables](https://flowfuse.com/changelog/2026/04/images/ff-instance-url-env-var.png)*FF\_INSTANCE\_URL in list of Instance Environment Variables*

For Hosted Instances with a [Custom Hostname](https://flowfuse.com/docs/user/custom-hostnames/#custom-hostnames) that will be returned rather than the default Instance hostname.

Existing instances will need to be restarted to pick up the new Environment Variable.

This will be available to Self Hosted users from v2.29.0


# Customisable Immersive Editor Drawer

The drawer in the immersive editor used to float over your canvas, blocking parts of your flow whenever it was open. Now it sits inside the editor layout, so FlowFuse tools stay visible alongside your work in Node-RED. You can also set it up the way you like, and it stays that way every time you come back:

![Pinning, moving, and full-screening the immersive editor drawer](https://flowfuse.com/changelog/2026/04/images/immersive-ui-drawer.gif){dataZoomable=""}&#x2A;Pin, switch sides, or go full-screen from the drawer header, your settings persist between sessions.*

- **Pin the drawer** to dock it alongside the canvas, and the Node-RED editor resizes to fit.
- **Switch sides** to move the drawer to the left or right of the screen.
- **Go full-screen** to hide the FlowFuse topbar and give the canvas maximum space.
- **Resize the drawer** to whatever width works best for you.

The drawer opens by default the first time you visit the editor. After that, your browser remembers your choices between sessions.

This feature is available to all FlowFuse Cloud users and Self Hosted users from v2.30.


# Richer snapshot comparison view

Previously, comparing snapshots only showed the two flow canvases overlaid at different opacities. You could see that something had changed, but not what or where.

Now when you compare two snapshots, a sidebar lists every changed, added, and deleted node. You can step through them one at a time, the canvas highlights and scrolls to the relevant node automatically. For each change you can see:

- **Property diffs**: each changed property is shown inline with the old and new value side by side.
- **Code diffs**: for function and template nodes, code changes appear as a line-level diff with red for removed lines and green for added, the same format you'd expect from a git diff.

Use the Prev / Next buttons or the ← → arrow keys to navigate through changes.

::lite-youtube
---
params: rel=0
style: "width: 100%; aspect-ratio: 16/9;"
title: Snapshot Comparison, FlowFuse v2.29
videoid: cNdGB-gksfQ
---
::

For the first time, teams can review a snapshot diff before deployment and actually trust what they're seeing, not just look at it.

This feature is available to all FlowFuse Cloud and Self Hosted users from v2.29.


# AI Feature Opt-Out for Teams

You can now turn off AI features for your team from the team settings page. When disabled, FlowFuse removes the Expert Assistant, inline code completions, and snapshot description generation for your team. Running instances will need a restart for the change to fully take effect.

![AI Features toggle in team settings](https://flowfuse.com/changelog/2026/05/images/ai-opt-out-toggle.png){dataZoomable=""}:br&#x2A;Opt out of AI features from the Danger section in team settings.*

The toggle is on by default for all teams. Flipping it off shows a confirmation dialog so you don't accidentally disable it. If you change your mind later, just flip it back on.

Self Hosted Enterprise customers also get platform-level and team-type-level AI controls, so admins can control AI availability across the entire installation or per plan before it ever reaches team owners.

This feature is available to all FlowFuse Cloud users and Enterprise Self Hosted users from v2.31.


# FlowFuse Expert Builds Your Application

You can now describe what you want to build, and the FlowFuse Expert will assemble it for you directly on your Node-RED workspace. It adds tabs, drops in nodes, wires them together, and configures their properties, to help get you up and running.

Previously, the Expert could answer questions, suggest changes, and act on links you clicked. Turning those suggestions into a working OEE dashboard, MES handover screen, or Modbus-to-UNS bridge still meant placing every node and wire by hand. Now the Expert does that work for you, and you keep iterating in chat to shape the result around your real-world setup.

![FlowFuse Expert assembling flows on the Node-RED workspace from a chat prompt](https://flowfuse.com/changelog/2026/05/images/expert-application-building.gif){dataZoomable=""}&#x2A;FlowFuse Expert assembling an application on the Node-RED workspace from a chat prompt.*

Agentic Node-RED development is rolling out as a soft launch so we can fine-tune the experience before opening it up more widely. It is available on request to FlowFuse Cloud Team and Enterprise teams from v2.30. Self Hosted enablement follows shortly.

[Contact us](https://flowfuse.com/contact-us/?subject=FlowFuse%20Expert%20Application%20Building) to enable agentic Node-RED development for your FlowFuse Cloud team.


# Single SSO provider for all users

When running self hosted FlowFuse or embedding FlowFuse in a solution it may be
required to send all user authentication requests to a single SAML SSO provider,
rather than using the users email domain to pick the correct provider.

With the release of FlowFuse 2.30.0 it is now possible to pick a configured provider and all unauthenticated users will be automatically redirected to this provider.

![Admin settings for Automatic SSO Redirect](https://flowfuse.com/changelog/2026/05/images/single-sso-provider.png)*Admin settings for Automatic SSO Redirect*

To prevent administrator lockout in the event of a SSO failure, admins can by pass this redirect and enter their normal username and password by accessing any page on the admin route, e.g. `https://forge.example.com/admin`

Documentation is found [here](https://flowfuse.com/docs/admin/sso/saml#forcing-all-users-to-use-sso)

This feature is only available to Self Hosted Enterprise licensed FlowFuse Instances.


# Dark Mode

FlowFuse now has a dark mode. 🦇 You can switch the whole app between Light, Dark, and System from your User Settings.

A bright white UI is fatiguing in low-light control rooms or on a night shift. Dark mode lets FlowFuse fit those environments.

By default, FlowFuse follows your operating system and flips live when it changes. Pick Light or Dark to lock it in, FlowFuse remembers your choice per browser.

![FlowFuse in dark mode, showing the Theme setting under User Settings](https://flowfuse.com/changelog/2026/06/images/dark-mode.gif){dataZoomable=""}&#x2A;The whole app re-themes live as you toggle, no reload needed.*

To change your theme:

1. Open **User Settings**
2. Under **Theme**, choose **Light**, **Dark**, or **System**
3. Save

A note on scope: dark mode covers the FlowFuse application itself. The embedded Node-RED editor and Dashboard iframes keep their own themes, Node-RED and your Dashboard configuration manage those separately.

This feature is available to all FlowFuse Cloud users and all Self-Hosted users from v2.32.


# Device Agent v4 released

Device Agent v4 is a major release. It brings a modern Node.js runtime, structured logging for production observability, a new authentication method, and a more secure container deployment model. There are breaking changes - check the [upgrade notes](https://flowfuse.com/#upgrading-to-v4) before updating your remote instances.

## Node.js 22 is now the default runtime

The Device Agent installer and official Docker image now default to Node.js 22. Node.js 20 reached end-of-life in April 2026, and continuing to ship it as the default would leave devices running on an unsupported runtime without security patches. It is also the minimum version required by Node-RED v5.

::caution
**Breaking change:** The Device Agent Docker image tagged `latest` now uses a Node.js 22 base image. If you do not pin your container image to a specific version tag, review your deployment configuration before upgrading.
{% endcaution %}

We also continue to build, and tag, containers for a range of Node.js versions - 18, 20, 22 and 24.

If you use the Device Agent installer, it will now default to Node.js 22. Existing installations using the installer will need to download the latest version and re-run the installer.

## Containers now run as an unprivileged user

The Device Agent Docker container no longer runs as the root user. Following best practices, processes inside the container now execute as an unprivileged user.
::

**Breaking change:** If your container deployment mounts volumes or relies on file permissions set for the root user, you'll need to update those permissions to match the new unprivileged user.

More details are available in the [Device Agent readme](https://github.com/FlowFuse/device-agent/tree/edf987872b7c93170b5ced56061b211619e7e106#docker){rel="&#x22;nofollow&#x22;"}.
{% endcaution %}

This is a security hardening change with no functional impact on normal Device Agent operation.

## Structured JSON logging

The Device Agent now supports a JSON logging format, selectable via the `--log-format json` CLI flag.

Previously, all agent output was plain-text - readable in a terminal but difficult to ingest reliably into log aggregation tools like Grafana Loki, Elastic, or AWS CloudWatch. Parsing unstructured log lines with regex is fragile and breaks whenever the message format changes.

With JSON logging enabled, every log entry is a machine-readable object with consistent fields. Pipe agent output directly into your existing observability stack without any custom parsing rules.

```text
device-agent --log-format json
```

## Bearer token authentication

The Device Agent now supports bearer tokens as an authentication method for HTTP endpoints, alongside the existing credential model.

This allows you to create HTTP endpoints in your Node-RED flows that can be accessed securely by other applications without needing to manually authenticate first. This is a capability we've had in Hosted Instances for a while - this release makes it available to Remote Instances as well.

You can configure the tokens via the FlowFuse dashboard for your remote instance under the `Settings->Security` section. Enable the `FlowFuse User Authentication` option, then you can create and manage the tokens.

This requires the FlowFuse v2.32 release, coming later this week, when running in a self-hosted environment, but already available on FlowFuse Cloud.

## Editor theme fix

A bug caused the FlowFuse editor theme to fail to load in certain configurations - particularly when switching between Node-RED 5 and legacy versions. This is now resolved. The correct theme loads regardless of which Node-RED version the device is running.

---

## Upgrading to v4

Before upgrading, check the following:

**Docker users:** The `latest` container image now uses a Node.js 22 base and runs as an unprivileged user. Review volume mount permissions and update any configurations that assume a root user or an earlier Node.js version. Details available in the [Device Agent readme](https://github.com/FlowFuse/device-agent/tree/edf987872b7c93170b5ced56061b211619e7e106#docker){rel="&#x22;nofollow&#x22;"}.

**Installer users:** Download the latest version of the installer and re-run it if you want to stay aligned with the new default.

---

Device Agent v4 is available now. Update via the [Device Agent installer](https://github.com/FlowFuse/device-agent){rel="&#x22;nofollow&#x22;"} or pull the latest Docker image.


# Connect Pipelines to Any Git Server

DevOps Pipeline Git Repository stages now connect to **any Git server that speaks HTTPS**, GitLab, Bitbucket, Gitea, or a self-hosted instance, not just GitHub and Azure DevOps.

Previously, Git integration only worked with those two providers. If your team backs up flows to a self-hosted GitLab or an on-prem Bitbucket, you were stuck. Now you can point a pipeline at any HTTPS Git repository to back up and deploy your flows.

For servers that use a private certificate authority, you can paste in a CA certificate so FlowFuse trusts the connection, no infrastructure changes required.

To get started:

1. Go to **Team Settings → Integrations → Add Token**.
2. Choose **Other**, then enter the repository **username** and a personal access token (or app password).
3. If your server uses a private CA, paste its certificate into the **CA Certificate** field.
4. Add a **Git Repository** stage to a pipeline, select your token, and enter the repository URL.

![The Add Git Token dialog showing the GitHub, Azure DevOps, and Other provider options, with the Other option selected and the username and CA certificate fields visible](https://flowfuse.com/changelog/2026/06/images/generic-git-provider.png)&#x2A;Creating a generic Git token for a self-hosted server.*

This feature is available to Team and Enterprise tier users of FlowFuse Cloud and Enterprise Licensed Self Hosted users from v2.32.


# Updated: Upcoming Scheduled Server Maintenance on July 11th, 2026

:product-update-note

As part of our ongoing efforts to maintain our infrastructure, we need to update some of our servers that host Node-RED instances.

This will require restarting any hosted Node-RED instances running on those servers, leading to a short downtime whilst they restart. Remote instances on the edge are unaffected.

**We will complete this migration during a 3 hour maintenance window starting at 8am UTC on Saturday 11th July 2026.**

### Will my instances be affected?

If your instance was created after 15th June 2026, or has been updated since that date, it will already be running on the new servers.

Otherwise, you can take action to migrate your instance before the scheduled maintenance window at your own convenience.

If you manually suspend and restart your instance, or apply any pending upgrade any time before the maintenance window, your instance will not need to be restarted and no further action will be needed.

You can find the "Suspend" option from the "Actions" drop down menu on the Instance Overview page. Once the Instance reports being in the Suspended state, you can select "Start" from the same drop down menu.

We will be emailing notifications to all team owners who have instances that require a restart.

### Enabling Scheduled Maintenance Mode

Keeping instances up to date is an important task to ensure they are running with the latest features and security fixes. FlowFuse provides the ability to select a time for updates to be automatically applied to your instances. You pick which day of the week and time the platform can schedule updates in. This removes the burden for keeping things up to date.

On FlowFuse Cloud, Starter teams already have this feature enabled for their instances to apply updates at the weekend.

Pro and Enterprise teams can opt-in on the Instance Settings - Maintenance page.

More information is available in the [scheduled maintenance changelog entry](https://flowfuse.com/changelog/2025/12/scheduled-maintenance/).


# Application Roles from SSO Groups

Application level Role overrides can now be managed by SSO Group membership.

As well as Team wide Role membership additional groups can be used to apply Role overrides to specific Applications.

This works for both SAML and LDAP based SSO, the documentation outlining the required group naming can be found [here](https://flowfuse.com/docs/admin/sso).

For example for a Team with the slug `development` and an application called `test` a user in the following groups would have `member` level access to the Team and `owner` level access to the `test` Application.

- `ff-development-member`
- `ff-development[test]-owner`

This is available to FlowFuse Cloud Teams now and will be available to Self Hosted customers from version 2.33.0 onwards.


# Getting started with FlowFuse straight from the terminal

FlowFuse Device Agent allows you to remotely manage Node-RED instances running on your hardware, for example, devices on your factory floor.

Getting your own hardware into FlowFuse meant working backwards. You signed up, found the remote instance section, learned what the Device Agent was, created the instance in the platform, copied its connection details, and only then ran the installer with that code in hand.

Now you can start where the hardware already is. Run the installer from your terminal and it walks you through registering — including setting up an account if you need one — ending with your machine registered as a remote instance and ready to build on. If something's in the way — like port 1880 already being in use — the installer tells you up front instead of failing partway through.

Check the [Device Agent Quick Start guide](https://flowfuse.com/docs/device-agent/quickstart/) to get connected.

![The installer running in a terminal, walking through sign-up and connection to FlowFuse](https://flowfuse.com/changelog/2026/07/images/device-agent-install.gif){dataZoomable="" style="border: 2px solid #E5E7EB;"}&#x2A;Sign-up and registration happen in one uninterrupted flow — no jumping back to the platform.*

![The interactive registration takes you straight through to the Node-RED editor once connected](https://flowfuse.com/changelog/2026/07/images/device-agent-registration.png){dataZoomable="" style="border: 2px solid #E5E7EB;"}*The interactive registration takes you straight through to the Node-RED editor once connected*


# FlowFuse Expert Enhancements

## Insights

With the release of device-agent 4.0.0 and FlowFuse 2.32.0, FlowFuse Expert Insights Agent can now work with Remote Instances and Self Hosted Instances.

::caution
**Important:**

In order to achieve Insights on Remote Instances and Self Hosted Instances, we had to modify how data is routed through the platform. Your old Hosted Instances on FlowFuse Cloud will require an update to the latest Launcher Version (2.23.0 or greater) to continue working.
::

![Resource from Hosted and Remote Instances can now be selected](https://flowfuse.com/changelog/2026/07/images/insights-1.png){dataZoomable=""}*Resource from Hosted and Remote Instances can now be selected*

![Insights querying a Remote Instance](https://flowfuse.com/changelog/2026/07/images/insights-2.png){dataZoomable=""}*Insights querying a Remote Instance*

![Insights in an action](https://flowfuse.com/changelog/2026/07/images/insights.gif){dataZoomable=""}*Insights in an action - querying a Remote Instance*

## Platform Automations

The Expert can now take action on your FlowFuse platform directly. Instead of telling you which buttons to click, it can create instances, register devices, take snapshots, and manage applications on your behalf. You can ask the Expert to:

- Create hosted instances with the right type, stack, and template, optionally starting from a flow blueprint
- Register remote instances (devices) and assign them to applications
- Take and list snapshots of both hosted and remote instances
- Create applications, list what's running inside them, and check their audit logs
- Look up live status and logs for any hosted instance, or query a remote instance's state over MQTT

Behind the scenes, FlowFuse exposes over 30 automation tools covering instances, devices, applications, snapshots, teams, and configuration. When you ask the Expert to do something, it picks the right tools, calls them with your permissions, and reports back.

## Better Formatted Replies

Expert replies now render markdown more fully in the chat panel. Tables, ordered lists, blockquotes, and checklists all display with proper formatting instead of falling back to plain text, making longer, more structured answers much easier to scan.

Tables come with a copy button that copies the contents as tab-separated values, ready to paste straight into a spreadsheet.

![An Expert reply showing a formatted table, ordered list, and checklist](https://flowfuse.com/changelog/2026/07/images/markdown-rendering.png){dataZoomable=""}*A formatted reply with the tab-separated copy button in the table's top-right corner*

## Support Agent

We have added three ways to stay in control of what the Expert does while it works alongside you in the editor.

### Plan Mode

The Expert can now propose a plan before it changes anything, so you can review the approach before it touches your flows.

Turn on **Plan Mode** with the toggle in the chat composer. Instead of acting straight away, the Expert lays out what it intends to do as a plan you can read through. From there you can:

- **Approve**: the Expert proceeds with the plan.
- **Edit**: open the plan in the composer, adjust the wording yourself, and send it back.
- **Request changes**: describe what you would like to be different, and the Expert proposes an updated plan.
- **Reject**: discard the plan and start again.

This is ideal for larger or unfamiliar changes, where you want to agree on the approach before any work happens.

![The Expert proposing a plan, with Approve, Edit, Request changes, and Reject actions](https://flowfuse.com/changelog/2026/07/images/plan.png){dataZoomable=""}*The Expert proposes a plan and waits for your approval before making any changes*

### Clarifying Questions

The Expert now asks clarifying questions when a request could go more than one way, rather than guessing and building the wrong thing.

When it needs more detail, the Expert presents up to four questions in a single turn, each as a set of options you pick from, either single choice or multiple choice. You answer them all together, and it uses your answers to get the result right the first time. For example:

- Which flow should this run in?
- Should the incoming payload be stored, forwarded, or both?
- Which of these nodes should trigger the alert?

You can revisit and change your answers before continuing, and you decide the pace: use the follow-up questions setting in the composer menu to have the Expert ask everything **all at once** or **one at a time**.

![The Expert asking grouped clarifying questions with single and multiple choice options](https://flowfuse.com/changelog/2026/07/images/questions.png){dataZoomable=""}*The Expert asks clarifying questions and collects your answers before acting*

### Human in the Loop

You are now in charge of exactly which actions the Expert is allowed to take on your flows, so no change happens that you did not permit.

When the Expert wants to run an action that needs your sign-off, it pauses and shows an approval card in the chat. The card names the action, whether it reads, writes, or deletes, and the exact details of what it will do, with four choices:

- **Allow** or **Deny**: approve or refuse this one action.
- **Always allow** or **Always deny**: apply your choice to every matching action.

The Expert waits for your decision however long you need, and you can cancel a pending action at any time with the stop button.

![An inline approval card showing the action, its type, and Allow, Always allow, Deny, and Always deny choices](https://flowfuse.com/changelog/2026/07/images/approval-card.png){dataZoomable=""}*The Expert pauses and asks for approval before running an action that needs your sign-off*

An **Always allow** or **Always deny** you set from a card applies to the current chat only, and resets when you refresh or start over. If you want to keep it, click **Make permanent** to save that choice for future chats.

![Clicking Make permanent on a granted action to save it for future chats](https://flowfuse.com/changelog/2026/07/images/make-permanent.gif){dataZoomable=""}*Make a per-chat permission permanent so it carries over to future chats*

You can also set your permissions ahead of time. Open **Tool permissions** in the Expert settings and choose a default for **Read**, **Write**, and **Delete** actions: **always allow**, **ask**, or **always deny**. Out of the box the Expert can read freely but asks before it writes or deletes anything. Flow building and platform actions each have their own defaults, and you can expand **Individual tools** to override the default for a specific action, which then stays put until you reset it. These settings are saved for you and persist across chats within the team you are working in; switching to another team starts from the defaults again.

![The Tool permissions panel in Expert settings, with default Read, Write, and Delete permissions for flow building and platform tools](https://flowfuse.com/changelog/2026/07/images/tools-permissions.png){dataZoomable=""}*Set default permissions per action type, and override individual tools where you need to*

---

*All of these new features are available to FlowFuse Cloud users and Self-Hosted users from v2.32.*


# FlowFuse Expert Can Now Work With Your Tables

FlowFuse Expert can now look up your FlowFuse Tables databases directly. Ask it to list the databases on your team, show you the tables in a database, or describe a table's schema, and it calls the right tools and reports back, without you needing to open the Tables view yourself. It can also preview a table's data: up to 10 rows, exactly as stored.

This is a fixed, read-only preview, not a query engine: there's no filtering, sorting, or paging through it, and no writes. For anything beyond that quick look, the Expert can help you build it as a flow with the `tables-query` node instead.

![The Expert listing the tables in a FlowFuse Tables database, grouped by schema](https://flowfuse.com/changelog/2026/07/images/chat.png){dataZoomable=""}*The Expert listing a database's tables, grouped by schema*

Alongside this, FlowFuse Tables now correctly supports tables that live in a schema other than `public`. Previously, viewing data for a table outside the default schema could fail. Tables and their schema now show up correctly throughout the Tables UI: next to each table name in the list, and as `schema_name.table_name` (with a copy button) in the table detail view.

![The Tables explorer showing each table's schema next to its name, and the qualified schema.table name with a copy button in the header](https://flowfuse.com/changelog/2026/07/images/tables-view.png){dataZoomable=""}*The schema label beside each table name, and the qualified `schema.table` name with a copy button in the header*

This feature is available to FlowFuse Hub and FlowFuse Edge customers on Cloud and Self Hosted from v2.33


# Team Scoped Personal Access Tokens

Personal Access Tokens now support fine-grained scoping. You can restrict a token to specific teams, limit it to read-only operations, or control whether it
carries admin privileges. This is especially useful when handing tokens to AI agents or MCP clients, where you want to limit what the token can reach.

## Team scoping

You can now scope a token to one or more teams. A scoped token can only access resources within those teams. If you don't select any teams, the token works
across all teams you belong to, same as before.

When you're added to a new team, scoped tokens don't automatically pick it up. You need to explicitly add the new team to any token that should have access.

## Read-only mode

A new toggle lets you mark a token as read-only. When enabled, the token can only perform read operations across all resources it has access to. Any write
operation will be rejected.

## Admin opt-in

Tokens created by admin users no longer carry admin privileges by default. When you create a new token, it behaves as a regular user token, using your team
roles instead of full admin access. If you need the token to have admin capabilities, you have to explicitly check the admin opt-in option.

Existing admin-owned tokens have been migrated with admin opt-in enabled, so they continue to work as before. Only newly created tokens default to
non-admin.

## How scoping works

These options allow you to narrow the scope of a token's permissions; you cannot create a token with more access than your user has.

You can create and manage your tokens under **User Settings > Security > Personal Access Tokens**.

This feature is available to FlowFuse Cloud users as of now and Self-Hosted users from v2.33.

![Creating a new scoped Personal Access Token](https://flowfuse.com/changelog/2026/07/images/scoped-pats.png){dataZoomable=""}*Creating a new scoped Personal Access Token*


# A Dedicated Home for Your Dashboards

Your dashboards now have a home. A new **Dashboards** entry in the team navigation lists every dashboard across your hosted instances in one place. Open one and it loads right inside FlowFuse, not in a separate browser tab. Each application also has its own **Dashboards** tab, showing just the dashboards from that application's instances.

Until now, dashboards were tucked behind an "Open Dashboard" button on individual instance pages. Finding the one you wanted meant hunting through instances, and each one opened in a new tab. Now you get one place that shows them all, at the team or application level.

![The Dashboards view listing all dashboards across the team](https://flowfuse.com/changelog/2026/07/images/team-dashboards.png){dataZoomable=""}*Every dashboard in the team, each showing whether its instance is currently running*

## Switch between dashboards in place

A drawer lets you switch to any other dashboard in a single click, without returning to the list. Jump from your "Line 3 OEE" dashboard to "Energy Monitoring" and back without losing your place. Instance status updates live in the drawer, so you can see at a glance which dashboards are ready.

![An embedded dashboard with the drawer open to switch between dashboards](https://flowfuse.com/changelog/2026/07/images/dashboard-drawer.png){dataZoomable=""}*The drawer stays open alongside the dashboard, so switching doesn't cover what you're viewing*

*This feature is available to all users of FlowFuse Cloud and all Self Hosted users from v2.33.*


# Beginner Guide To A Professional Nodered

Node-RED is the easiest low-code programming environment for developing anything from manufacturing automation to data integration and device management. The applications are endless, enabling developers and non-developers to connect a wide variety of endpoints, such as industrial PLCs, APIs, databases, enterprise applications, and online services.

This ebook will introduce you to Node-RED's history, provide an in-depth look at its key features, and explain how to get started. It's an ideal starting point for those interested in leveraging this powerful integration platform to drive digital transformation. With FlowFuse, you can further enhance your Node-RED deployments, making them more scalable, secure, and enterprise-ready.


# Ultimate Guide To Building Applications With Flowfuse Dashboard For Node Red

The [FlowFuse Dashboard for Node-RED](https://flowfuse.com/platform/dashboard/), a complete rebuild of the original, aims to make dashboard creation easy, yet powerful. Based on the philosophy of "easy things should be easy, and hard things should be possible," it combines the best of its predecessor with new features that foster team collaboration and enable users to build full-stack applications within the Node-RED ecosystem.

Whether you're a seasoned developer or just getting started with your industrial IoT, our low-code platform helps create stunning and useful UIs quickly. This ebook will guide you through building powerful dashboards that elevate your applications and unlocks the true potential of your data.


# Accelerating Industrial Innovation With Low Code Platforms

We explore the challenges faced by engineers and introduce low-code platforms as a powerful solution. By empowering domain experts, low-code platforms like Node-RED enable rapid application development, prototyping, and iteration, fostering a culture of continuous improvement and driving significant cost reduction. Add to this FlowFuse enterprise-grade features and you have powerful production-ready solutions.


# Accelerating Innovation In Manufacturing With Flowfuse

Learn how manufacturers are using Node-RED and FlowFuse to unlock real-time insights, empower citizen developers, and break free from rigid architectures. This whitepaper explores how Unified Namespace, MQTT, and low-code development accelerate innovation—while FlowFuse adds the governance, security, and scalability needed for enterprise-grade deployment.


# Open Source Software For Manufacturing

This whitepaper explores how open source supports agility, future-proofing, and faster adoption in industrial environments. You'll learn how manufacturers benefit from community-driven innovation, stronger security through transparency, and a more flexible vendor strategy—while understanding how to manage the unique risks of OSS in critical operations.


# Uns Decoupling Data Producers And Consumers

This whitepaper introduces the Unified Namespace (UNS) as a transformative solution for industrial data management. Learn how decoupling systems fosters agility, simplifies architectures, and future-proofs your operations.

FlowFuse streamlines UNS adoption with native MQTT support, robust security, and enterprise-ready features. It simplifies broker management, abstracts protocol complexities, and provides a centralised interface for building and scaling industrial data solutions. Whether starting small or scaling up, discover best practices and actionable insights for adopting UNS and driving continuous improvement.