External systems — MQTT, Modbus, Cloud
Part 3 — Reference.
24.1 Four ways out
iNELS3 can talk to things that are not iNELS. There are four routes, and they suit different jobs:
iNELS 3 export / third-party protocol
both
visualisation systems, custom integrations
MQTT
both
home-automation platforms, IoT
Modbus
both
industrial equipment, meters, HVAC plant — RTU needs a CU3-10M; IP works on all CUs
Cloud
both
phone apps, remote access
MQTT and Modbus-IP are among the biggest additions since the Rev19 manual, which covers neither.
24.2 Exposing devices
Whatever the route, external systems only see what you have deliberately exposed.
Add to iNELS 3 export:
system bits, system integers, devices
Makes the object visible externally
Read only:
the same
External systems may read but not write
Alias:
the same
An alternative name for the external system to use
In the Device manager, the Export tools mark devices in bulk:
Select all for export
Select all for export and use description
Unselect all for export
For function block templates there is Add all to iNELS 3 export / Delete all to iNELS 3 export.
Expose the minimum. Every exposed object is something an external system can read — and, unless Read only is ticked, write. A visualisation that only shows temperatures does not need write access to your heating outputs.
Use aliases and keep them stable. External systems reference objects by name. Renaming an exposed object breaks whatever was reading it.
24.3 The third-party protocol
A plain-text protocol over TCP. Configure it in [☰] → CU configuration → Third part setting:
Port
TCP port
Mode
Protocol mode
Separator
Field separator character
Numeral system
How numbers are represented
Event enable
Send events as they happen, rather than only answering queries
Turn Event enable on if the other system should react to changes. Leave it off if it polls — polling a busy installation is much heavier than pushing events.
Rev19 §20.2 lists the ASCII symbols that survive iNELS 3 export. Consult it if your object names contain accented characters.
24.4 MQTT
Configured in [☰] → CU configuration → MQTT setting:
Mode:
MQTT mode
User name: / Password:
Broker credentials
Version:
MQTT protocol version
What can be published
Per Advance/Documentation/BUS unit to MQTT.txt:
MQTT CU Status
central unit state
MQTT Gateway Status
gateway state
MQTT System bits
your system bits
MQTT System integers
your system integers
Units
around 50 supported unit types
Supported units include the ADC3, DA3 and DAC3 families, the GSB3 and MSB3 button ranges (including the -V2 and /S variants), GRT3-50, IDRT3-1, IM3 inputs, IOU3-108M, JA3 blind actuators, the SA3 relay family, WSB3 units including the -Hum humidity versions, GBP3-60, GCH3-31, GCR3-11, GDB3-10, GSP3-100, DMD3-1 and RC3-610M/DALI.
The file in Advance/Documentation/ is authoritative and ships with your version — check it rather than this list, which will age.
Firmware requirement
MQTT needs CU firmware 02.97.02 or later on CU3-07M, CU3-08M and CU3-09M. Update first — Chapter 25.
24.5 Modbus
Three roles:
Modbus-IP-Master
the client, over TCP
reading meters and plant — any central unit
Modbus-IP-Slave
the server, over TCP
letting a SCADA or PLC read the installation — any central unit
Internal-Modbus-Master
master on the serial bus
RTU/ASCII equipment — CU3-10M only
Internal-Modbus-Slave
slave on the serial bus
being polled over RS-485 — CU3-10M only
Modbus devices are added in the Device manager like any other unit, and their values then work in wires and conditions as normal.
Notable behaviour from the change log:
Analog copy functions work to and from Modbus IP devices
Modbus values support multiplication for scaling
Modbus Address can be entered in decimal as well as hexadecimal
One device can be set as the default in a Modbus unit
Modbus units can be published in MQTT JSON format
Chapter 32 covers Modbus in full — RTU wiring, master and slave setup, register mapping, third-party integration, and a complete worked example.
24.6 Cloud
[☰] → CU configuration → Cloud setting — Mode:, User name: and Password:.
The cloud connection is what phone apps and remote access use. See Chapter 22.
24.7 Choosing a route
24.8 Before you integrate
Check CU firmware first
MQTT and Modbus-IP both need recent firmware
Expose the minimum, and use Read only
Every exposed object is an attack surface
Fix your aliases early
External systems break when names change
Test with the external system before handover
Integration failures are hard to diagnose remotely
Document what you exposed
Nobody will guess later
Next: Chapter 25 — Firmware update.