The hard part of a multi-device project is not simply networking; it is normalizing different protocols, tags and data formats. Tespro’s current TG-424 page lists MQTT, TCP, UDP, HTTP/HTTPS, Modbus RTU, DL/T 645, IEC 62056-21, DLMS/COSEM, Siemens S7, Mitsubishi MC, Omron FINS, EtherNet/IP, EtherCAT, PROFINET, CAN and OPC UA.
Key Points
- Define southbound device protocols separately from northbound platform protocols.
- Protocol support does not mean every vendor device works without configuration.
- Real projects need register maps, object tables or protocol documentation for mapping.
Start with a device and protocol inventory
Meters, PLCs, inverters, environmental sensors and controllers often come from different vendors. Record interface, address, protocol version, tags, units and collection interval before designing the gateway configuration.
Normalize the data model at the edge
The gateway can map different registers or objects into normalized tags and publish them through MQTT, OPC UA or HTTP. The EMS/SCADA then does not need to directly handle every device’s low-level differences.
Many protocols do not make integration automatic
Proprietary extensions, byte order, scaling, write permissions, exception codes and time synchronization still require engineering. TG-424 provides a broad protocol foundation, but real device documentation and field testing remain necessary.
Move from a device list to a real data dictionary
Beyond brand, model and protocol, define tag name, data type, byte order, unit, scaling, read/write permission, polling interval and quality. Only then do MQTT topics, OPC UA nodes or database fields have stable meaning. TG-424’s protocol coverage provides the foundation; the data dictionary makes the integration maintainable.
Version protocol mappings so data does not drift after field changes
Device firmware updates, register-map changes or new points can alter the data model. Keep a version for each device template and record the gateway configuration, test samples and deployment date. When a site later shows abnormal data, the team can distinguish a device-protocol change from a network or gateway issue.
Applications and Technical Boundaries
Where TG-424 fits multi-protocol aggregation: A site has meters, PLCs, sensors and several industrial protocols and also needs local processing, storage or AI capability.
A protocol list is not a compatibility guarantee: Vendor extensions, authentication, private objects and firmware differences can make two devices with the “same protocol” behave differently. Validate with the exact devices, point maps and packet samples.
TG-424 fits the data-aggregation layer of multi-protocol sites
The current TG-424 protocol set makes it relevant for sites where meters, PLCs, sensors and upstream platforms all speak differently. The real value is not the number of protocols listed; it is the ability to turn those device-specific data structures into a stable upstream interface that applications can use consistently.
Frequently Asked Questions
Q: Does TG-424 support DLMS/COSEM?
A: Yes. DLMS/COSEM is explicitly listed on the current product page.
Q: Are S7, MC and FINS listed?
A: Yes. Tespro currently lists Siemens S7, Mitsubishi MC and Omron FINS.
Q: Does a protocol list guarantee compatibility with every device?
A: No. Protocol versions, vendor extensions, point maps and authentication can differ and should be validated on the actual device.
Q: Can TG-424 run several protocols at the same time?
A: The website lists broad protocol support, but actual concurrent load, point count and performance depend on configuration and project workload. Confirm with a system-level test.
