Resolving SIMATIC IOT2040 Node-RED Connection Lost with LOGO! 8

Resolving SIMATIC IOT2040 Node-RED Connection Lost with LOGO! 8

This technical reference covers the recurring failure mode where a SIMATIC IOT2040 gateway (catalog number 6ES7647-0AA00-0YA2 / 6ES7647-0BA00-0YA2 family) running the Siemens Node-RED image logs the frontend message "Lost connection to the server" the moment a flow is deployed that polls a LOGO! 8 BM or LOGO! 8 RCE controller. The browser-side indicator and the underlying Node-RED runtime are both symptoms of a Node.js runtime versus npm-package compatibility issue, not a network failure, LOGO! firmware bug, or Node-RED installation defect. The fix is a controlled palette downgrade that aligns the S7 client node with the Node.js 8 LTS engine shipped on the IOT2040.

1. Problem Summary

The deployment topology in scope is small but specific:

• Gateway: SIMATIC IOT2040 (Intel Quark x1000, 1 GB DDR3, Yocto/Poky Linux, Siemens "Example Image" for IOT2000).
• Edge controller: LOGO! 8 (BM with Ethernet, catalog base 6ED1052-1MD08-0BA0, or LOGO! 8 RCE 6ED1052-2MD08-0BA0) with Ethernet connected to the same LAN.
• Router/DHCP: AVM FRITZ!Box on 192.168.178.0/24, providing DHCP to both devices.
• Visualization host: Node-RED served from the IOT2040 port 1880, opened from a PC browser.

The observed symptom chain is reproducible and deterministic:

1. The IOT2040 boots normally. SSH (port 22) responds to PuTTY, and the FRITZ!Box shows the device online.
2. LOGO!Soft Comfort can connect to the LOGO! 8 on TCP port 102, confirming the LOGO!'s Ethernet link and the S7 transport.
3. Node-RED is launched (manually or via the systemd unit). The browser loads http://192.168.178.201:1880 and the editor renders.
4. An S7 flow that contains the node-red-contrib-s7 palette node and a configured endpoint pointing at the LOGO! 8 (192.168.178.210, rack 0 / slot 1 for BM, rack 0 / slot 2 for RCE) is deployed.
5. The browser tab immediately displays the red banner: "Lost connection to the server".
6. The Node-RED backend process has, in fact, terminated or stalled. A full restart of the IOT2040 is required to bring Node-RED back into a usable state. Restarting only node-red via systemctl may show it "active (running)" but exhibit the same loop.

If you are reading this article, the network layer is functional (Ping, LOGO!Soft, and SSH prove it), and Node-RED itself is correctly installed. The fault is in the palette node you have chosen to bridge to the LOGO!'s S7 interface.

2. Affected Components and Software Versions

3. Root Cause Analysis

The Node-RED editor displays "Lost connection to the server" when its WebSocket channel (default /red/comms) cannot be maintained with the backend. In the field case described, the Node-RED runtime is crashing on startup or within seconds of deploying an S7 flow. The crash is not a "lost link" report from the browser; it is a backend termination event.

Versions of node-red-contrib-s7 are coupled to the Node.js engine that the host provides:

• version 2.x (community-maintained line): declares "engines": { "node": ">=6" } in its manifest. Runs cleanly on Node.js 8.16.x bundled with IOT2000 images and on Node.js 10+. Last stable in the 2.x line documented widely is 2.1.1.
• version 3.x (rewrite line): tightened dependencies and pulled in a vendored nodes7 fork whose package.json declares "engines": { "node": ">=10" }. Loading this code under Node.js 8 causes a SyntaxError at module load or an unsupported Buffer / async-hook error. The result is the same end effect: Node-RED exits, the WebSocket closes, and the browser flags the lost server.

A second, less-discussed failure mode is the npm-install path itself. On an IOT2040, a fresh install of any node package with native bindings (gyp build) may fail silently if the image does not include gcc and the kernel headers. The visual symptom matches the runtime crash, so confirm both before reinstalling.

4. Diagnostic Procedure

Before changing any package, isolate the failure to the palette node. The following procedure is reproducible and leaves the system intact:

4.1 Confirm the Node.js engine version

1. SSH into the IOT2040 with PuTTY as user root (factory default) or the configured user.
2. Run:

   node --version
   npm --version

3. Expected on the IOT2000 image: v8.16.x or v8.17.x. If the output shows Node 10+, you are not on an IOT2040 image; this article does not apply.

4.2 Capture the running palette versions

1. Open the Node-RED editor at http://<iot-ip>:1880.
2. From the hamburger menu, choose Manage palette.
3. On the Nodes tab, locate node-red-contrib-s7.
4. Record the installed version. If it is 3.0.0 or newer, you have identified the version that crashes against Node 8.

4.3 Reproduce the crash deterministically

1. Stop Node-RED:

   systemctl stop node-red

2. Start it in the foreground to capture stderr:

   node-red --verbose

3. Deploy a minimal S7 flow that creates an S7 endpoint to 192.168.178.210:102 with rack 0, slot 1.
4. Observe the log. A v3.x node will print either a SyntaxError in module load or Error: Node.js v8.x is not supported. The process exits with non-zero status, and the browser then reports the lost connection.

4.4 Confirm the network path to the LOGO! is intact

If all four checks pass, the network and the LOGO! 8 S7 server are healthy, and any "Lost connection" message is not caused by the LAN.

5. Resolution: Downgrade the Palette Node

The goal is to remove the v3.x install of node-red-contrib-s7 and install v2.1.1, which is the last version of the 2.x line compatible with Node.js 6/8 and stable on the IOT2040 image.

5.1 Remove the incompatible package

There are two accepted entry points; both produce the same end state.

Option A - From the Node-RED UI (recommended):

1. Open Manage palette → Nodes.
2. Locate node-red-contrib-s7.
3. Click Remove.
4. Confirm the uninstall; let Node-RED restart its nodes registry.

Option B - From the shell:

cd ~/.node-red
npm uninstall node-red-contrib-s7

5.2 Install the compatible version

From the Node-RED UI:

1. Manage palette → Install.
2. In the search box, type node-red-contrib-s7.
3. Locate the package, click the version dropdown next to the install button, and select 2.1.1.
4. Click Install. Wait for the green confirmation. A panel will list the installed version: "2.1.1".

From the shell, if the package is not in the UI feed (offline image):

cd ~/.node-red
npm install [email protected] --save

If the IOT2040 has no internet (FRITZ!Box blocks or proxy in place), pre-fetch the tarball on a PC with internet, copy it via SCP/WinSCP to /home/iot/.node-red/, and run npm install ./node-red-contrib-s7-2.1.1.tgz --save.

5.3 Avoid the palette install path typo

5.4 Restart Node-RED

systemctl restart node-red
# or, after manual changes, from inside ~/.node-red:
node-red --verbose

Watch the boot log. A successful v2.1.1 install prints lines similar to:

22 Mar 10:14:01 - [info] Node-RED version: v1.x.x
22 Mar 10:14:01 - [info] Server now running at http://127.0.0.1:1880/
22 Mar 10:14:02 - [info] [s7 endpoint:<id>] connected: 192.168.178.210:102

If no crashes are logged and the s7 endpoint reports "connected", the WebSocket remains stable and the browser no longer reports "Lost connection to the server".

6. Verification

After the downgrade, perform these checks in order. Failure at any step indicates an additional issue and should be addressed before returning the system to production.

1. Editor stability: leave the Node-RED tab open for at least 30 minutes with the S7 flow deployed. No "Lost connection" banner should appear.
2. Polling cycles: create an inject node driving the s7 in-node every 5 s. In the debug sidebar, the msg.payload must contain valid Buffer or parsed-variable data, not undefined.
3. Process image: map at least one LOGO! input (I1) and one LOGO! output (Q1) by DB area. Toggle the input on the LOGO!; the debug payload should reflect the change within one poll.
4. Memory footprint: run free -m on the IOT2040. Memory use must stay below 75 percent of total RAM (i.e., under ~750 MB of 1 GB). Higher values indicate leaking connections and a different root cause.
5. Service auto-restart: confirm systemctl status node-red shows Active: active (running). After a deployment, the process must not restart silently.

7. Network and IP Configuration Reference

Although the issue is software-version compatibility, the configuration must still be correct. The reference below covers the canonical setup used in the field case.

If the FRITZ!Box is performing DHCP and the LOGO! shows no IP, it is almost always because the LOGO! 8 has DHCP disabled (the default for some firmware versions). Assign a static IP on the LOGO! via LOGO!Soft Comfort, then redeploy.

8. LOGO! 8 S7 Communication Settings

When configuring the s7 endpoint inside the v2.1.1 palette node, the parameters are critical. Misconfiguring these does not produce the "Lost connection" symptom directly, but it does produce additional errors after the compatibility fix is applied.

9. node-red-contrib-s7 v2.1.1 Quick Configuration

A stable reference flow uses inject, s7 in, function, and debug. The minimum configuration for an s7 in node is shown below.

{
  "host": "192.168.178.210",
  "port": 102,
  "rack": 0,
  "slot": 1,
  "timeout": 2000,
  "name": "LOGO_acq",
  "varlist": [
    { "name": "I1",     "addr": "DB1,X0.0", "type": "bool" },
    { "name": "I2",     "addr": "DB1,X0.1", "type": "bool" },
    { "name": "Q1_out", "addr": "DB1,X1.0", "type": "bool" },
    { "name": "AI1",    "addr": "DB1,WORD2", "type": "int" }
  ]
}

Connect the output of the s7 in node to a function node with the following JavaScript payload (read-only path):

msg.payload = {
  ts:  new Date().toISOString(),
  i1:  !!msg.payload.I1,
  i2:  !!msg.payload.I2,
  q1:  !!msg.payload.Q1_out,
  ai1: msg.payload.AI1
};
return msg;

Point a debug node at the function output and deploy. The debug panel must show structured JSON every cycle and the Node-RED editor must remain reachable in the browser.

10. Frequently Encountered Errors

11. Preventive Maintenance and Hardening

Once the immediate failure is resolved, the following practices prevent recurrence and protect the IOT2040 in long-running installations.

• Pin the palette versions: keep a copy of ~/.node-red/package.json under version control. Pin "node-red-contrib-s7": "2.1.1" so a future npm update does not pull in a v3.x line that is incompatible with Node 8.
• Disable auto-update: in the FRITZ!Box and the IOT2040 (no unattended-upgrade), choose a maintenance window for image upgrades.
• Use systemd hardening: wrap the Node-RED service so it restarts on crash with back-off, and send logs to a remote syslog so "Lost connection" patterns can be correlated with deploy events.
• Watch memory: the IOT2040 has 1 GB RAM and the Quark CPU is not a high-throughput host. Do not run more than two s7 endpoints and one analytics node concurrently.
• Take an SD card image backup: after the successful downgrade, image the SD card with tools such as Win32DiskImager or dd. This snapshot recovers the working state in minutes when a future palette install fails.
• Document the LOGO! variable map: save the DB1 layout as a CSV inside ~/.node-red/. Changes to the LOGO! program require updating this file; misalignment produces data-typing errors rather than "Lost connection" but is harder to debug without documentation.
• Plan a migration path: for new installations, the SIMATIC IOT2050 with its updated Node.js (16 LTS at firmware V2.x) eliminates the version pin constraint. Reserve the IOT2040 for legacy use.

12. Field Notes and Edge Cases

Three recurring edge cases complicate the diagnosis in field installations:

A. The "Lost connection" line is from an old browser tab. If the user does not refresh the editor after a Node-RED restart, the cached WebSocket stays open on the old socket ID and the banner remains even after Node-RED is responsive again. Hard refresh (Ctrl+F5) clears it. This is not the package version issue; it is purely client-side state.

B. The v2.1.1 install silently replaced by a v3.x. Some Node-RED palettes refuse to install an "older" version through the UI. The path Manage palette → Install → Version dropdown is still available; failing that, run npm install [email protected] --save on the command line. The CLI forces the version the registry serves for that tag.

C. The LOGO! 8 RCE has a different slot number than the BM. A common mistake is copying the rack/slot from a LOGO! BM configuration (rack 0, slot 1) into an RCE endpoint. The RCE base is rack 0, slot 2. The s7 node will keep attempting to connect without crashing Node-RED, but it will never see the variables. Confirm with LOGO!Soft Comfort under Tools → Ethernet Connections → Online; the displayed "PLC name" plus the slot field on the LOGO! hardware itself confirm the unit type.