Configuring Siemens IoT2040 Gateway for Climatix Modbus TCP

Overview

The Siemens SIMATIC IoT2040 is a rugged ARM-based industrial gateway designed to bridge field-level automation devices with cloud and SCADA applications. When paired with the Climatix family of HVAC controllers, it becomes a flexible protocol-translation node capable of exposing Modbus TCP, BACnet/IP, KNX, and JSON datapoints to higher-level systems such as Desigo CC, cloud APIs, or custom MQTT brokers.

This reference covers the supported communication paths between an IoT2040 (or IoT2020) and a Climatix controller, the commissioning sequence required to bring up a Modbus TCP link, the role of Node-RED as a lightweight integration runtime, and the practical limitations when remote write-back (control commands) is required. Field engineers will find protocol register mapping, parameter examples, and a troubleshooting matrix at the end of the document.

Supported Climatix Communication Paths

The Climatix controller range (POL, POL4xx, POL6xx, and DCM modules) exposes a layered protocol stack. Selection of the right transport depends on what the controller variant was ordered with, because communication modules are physically distinct plug-in boards in most Climatix SKUs.

For an IoT2040 integration the two highest-yield paths are Modbus TCP (lowest barrier, native on every Climatix Ethernet variant) and BACnet/IP (when the BMS back-end expects BACnet objects). KNX and JSON are feasible but require additional module purchases.

Hardware Prerequisites

Before commissioning, confirm the following on-site inventory:

• SIMATIC IoT2040 (6ES7647-0BA00-0YA2) or IoT2020 (6ES7647-0AA00-0YA2) with a working Yocto Linux image. The SIMATIC IOT2020 / IOT2040 Operating Instructions describe the supported firmware revisions and SD card image variants.
• Climatix controller with Ethernet port (POL6x6 or DCM with Ethernet option) and a confirmed firmware build. Determine the firmware version via the Climatix HMI service menu or via the embedded web server.
• Ethernet cabling between the Climatix LAN port and the IoT2040 ETH1 (the secondary port, ETH0, is typically used for uplink to the corporate network).
• Power supply: 24 V DC, ≥ 2 A for the IoT2040; Climatix typically 24 V AC/DC depending on variant.
• Configuration tools: SCP/SSH client (PuTTY, OpenSSH), web browser, and Node-RED editor access on the IoT2040.

Modbus TCP Integration Path

Modbus TCP is the recommended first integration because it requires no additional module on the Climatix side and is fully supported by both Node-RED and CODESYS applications on the IoT2040.

Step 1 - Configure the Climatix as a Modbus TCP Server

1. Open the Climatix service tool (SSP or the embedded web interface).
2. Navigate to Communication → Modbus.
3. Enable Modbus TCP Server; set the TCP port (default 502).
4. Define the unit ID (typically 1 unless the controller is part of a multi-drop bridge).
5. Map the data points you intend to expose. The Climatix exposes datapoints through internal Modbus registers; the typical mapping is:

Step 2 - Network Configuration on the IoT2040

Assign a static IP on ETH1 to avoid DHCP churn on a field network:

# /etc/network/interfaces.d/eth1
auto eth1
iface eth1 inet static
    address 192.168.10.20
    netmask 255.255.255.0

Restart networking and verify reachability:

systemctl restart networking
ping 192.168.10.50    # Climatix IP

Step 3 - Modbus Probe with mbpoll

Use mbpoll from the IoT2040 shell to validate the link before commissioning Node-RED:

mbpoll -m tcp -p 502 -a 1 -t 4 -r 1 -c 5 192.168.10.50

This reads five input registers starting at address 1 from unit ID 1. A successful response confirms the Modbus TCP path end-to-end.

Step 4 - Node-RED Flow

Install the node-red-contrib-modbus palette on the IoT2040. The typical flow consists of:

1. Modbus Read node — configured as Modbus TCP client, server 192.168.10.50:502, unit ID 1, function code 4 (input registers), polling every 5 seconds.
2. Function node — scales the raw 16-bit integer into engineering units (e.g. temperature = register / 10).
3. MQTT Out or HTTP Request node — forwards the normalized value to the destination cloud or SCADA.
4. Modbus Write node — bound to an inbound MQTT or HTTP topic for write-back commands.

BACnet/IP Integration Path

When the upstream system is a building management platform expecting BACnet objects (Desigo CC, Honeywell EBI, Schneider EBO), it is often simpler to expose Climatix objects directly as BACnet objects instead of translating Modbus to BACnet on the IoT2040.

Configuration Steps

1. Install the BACnet/IP communication module on the Climatix. Verify that the module's device instance number is unique on the BACnet network.
2. Map the Climatix datapoints to BACnet objects in the SSP engineering tool: analog values become AV, binary states become BV, commands become AO/BO with commandable flag set.
3. Configure the IoT2040 as a BACnet/IP foreign device (if it must initiate communication) or simply as a BBMD forwarder to the corporate BMS subnet.
4. From the IoT2040, run a BACnet discovery such as bacnet-discover (Yabe tool) to confirm the Climatix is announcing its objects on UDP/47808.

If you prefer the IoT2040 to act as the BACnet/IP server and pull data from Climatix via Modbus, the Node-RED node-red-contrib-bacnet palette can publish Modbus values as BACnet objects on the IoT2040 side. This is useful when the Climatix only has a Modbus module but the BMS only accepts BACnet.

Node-RED as the Integration Backbone

Node-RED is the de-facto middleware on the IoT2040 because it ships pre-installed on the Example Image and exposes TCP, UDP, Modbus, BACnet, MQTT, HTTP, and KNX nodes through community palettes. A representative architecture looks as follows:

The same Node-RED flow can publish to multiple destinations concurrently. Typical deployment uses an internal MQTT broker (mosquitto) running on the IoT2040, with downstream subscribers in the cloud or the on-prem Desigo instance.

Using CODESYS Control for IoT2000 SL

For engineers who prefer IEC 61131-3 programming (Structured Text, Ladder, FBD) over Node-RED flows, CODESYS Control for IoT2000 SL runs the CODESYS runtime directly on the IoT2040. The runtime exposes the gateway's Ethernet interfaces as a CODESYS network and provides Modbus TCP master/slave libraries in the standard CODESYS library set.

From the CODESYS Development System V3, the engineer can:

• Scan the network for the IoT2040 target.
• Use the Modbus_Master library function block to read/write Climatix registers.
• Map variables to a CODESYS WebVisu or to a cloud OPC UA endpoint.

Desigo Software and Message Tags

Desigo CC does not natively talk Modbus to field controllers — it expects either BACnet/IP, KNX/IP, OPC, or vendor-specific integrations. To use Desigo as the supervisory layer, you have three pragmatic choices:

1. BACnet/IP path. Expose Climatix objects as BACnet directly and let Desigo discover them over its standard BACnet/IP field driver. This is the cleanest approach.
2. OPC UA bridge. Use CODESYS OPC UA server on the IoT2040 (or a third-party OPC UA wrapper for Node-RED such as node-opcua) to publish Climatix datapoints as OPC UA tags; Desigo CC's OPC UA client driver subscribes to them.
3. Custom XIF driver. Siemens ships Desigo with XIF drivers for certain Climatix variants. Verify against your Desigo version's driver catalog before commissioning.

The reference to "setting message tags" in Desigo applies to the BACnet/IP or OPC UA route: once the gateway publishes the datapoints, they appear as Desigo points under the configured subsystem, and standard Desigo alarming, trending, and command wiring becomes available.

Remote Control / Write-Back Considerations

The original requirement was to send control commands from the IoT2040 to the Climatix. This is technically supported but must be implemented with care:

• Authentication. Modbus TCP on a Climatix does not authenticate the client. If the IoT2040 is on an isolated management VLAN, write access is acceptable. If not, place a VPN or firewall between the cloud and the gateway.
• Command priority. The Climatix enforces command source priority (local HMI > field bus > remote). A remote write will be rejected if a higher-priority source has locked the point.
• Rate limiting. Cap command messages in Node-RED to prevent runaway writes (e.g. toggle storms from the cloud).
• State feedback. Always read back the just-written register on the next poll to verify acceptance; the Climatix will echo the accepted value.

Climatix Cloud and REST API

Siemens also operates the Climatix cloud (climatixic.com), which provides REST APIs that the IoT2040 can call directly. The device API exposes per-controller telemetry; the cloud API exposes aggregated data. The IoT2040 can either:

• Act as a transparent forwarder, pushing Modbus data straight to the cloud via HTTPS POST.
• Run a local Node-RED flow that polls Modbus and POSTs to the cloud REST endpoint with OAuth2 bearer tokens.

Use the cloud route when you want Siemens-managed dashboards and remote firmware updates; use the on-prem Node-RED route when the customer requires air-gapped operation.

Commissioning Procedure

1. Verify IoT2040 firmware and Node-RED access (http://<iot-ip>:1880).
2. Verify Climatix firmware and Modbus TCP server enabled (port 502 reachable).
3. Validate Modbus link from IoT2040 shell with mbpoll.
4. Import the Modbus register map exported from the Climatix engineering tool.
5. Configure the Node-RED Modbus read flow; verify each tag in the debug sidebar.
6. Configure the MQTT or HTTP forwarding destination.
7. If write-back is required, configure the Modbus write node, throttle it to one command per 2 seconds, and enable write-back authorization in the Climatix access list.
8. Subscribe Desigo CC or the cloud endpoint and confirm values appear within one polling cycle.
9. Document register addresses, units, scaling, and security boundaries in the project handover.

Verification Checklist

Troubleshooting Matrix

Field-Proven Tips

• Always export the Modbus register CSV from the Climatix engineering tool and commit it to the project repository. Register tables drift over the life of an HVAC plant and undocumented maps become unmaintainable.
• Put the IoT2040 on a dedicated OT VLAN with a firewall rule allowing only Modbus TCP (502) and SSH (22) from a jump host.
• For multi-site fleets, run a local MQTT broker on each IoT2040 and use MQTT bridge to forward to a central broker, rather than opening cloud egress from each site.
• Use Node-RED's project feature to version the flows; pair with git on the IoT2040 userdata partition.
• If the project requires deterministic control loops, keep them on the Climatix and use the IoT2040 only for supervision — the gateway's Linux scheduling is not real-time.

FAQ