An IT team once described a setup like this: fewer than 500 accounts spread across four sites, with warehouse, receiving, shipping and packaging staff sharing terminals, logging into a handful of older portals built by the company's own business customers, where single sign-on was never an option. What these sites have in common is that people move with the goods instead of sitting at a fixed station, while the machines sit in the picking area, on the packaging line, at the loading dock. Checking whether a packaging machine is running right now, or whether the sealing temperature has drifted, cannot depend on walking over to look, nor on someone staying logged in to a portal page.
Placed on an IoT gateway, the chain splits into three sections: the field reads the values, the link carries them out, and someone sees them in one place. Each section is handled by different hardware, and mixing them up leads to buying the wrong device — the gateway handles collection and reporting, the industrial 4G router handles the uplink, and the fanless industrial computer handles the logic that will not fit locally.
① Values that can be read directly. PLCs, power meters, temperature controllers and VFDs mostly speak Modbus, and the values are already sitting in their registers. These require only slave addresses and register mapping on the gateway, with no extra hardware.
② Values that exist only as a status bit. Run, stop, fault, emergency stop, door open — many controllers expose a single bit. Reading works the same way as the first group; reporting does not, since a status bit is better sent on change than polled on a cycle.
③ Values with no electrical signal at all. Level, temperature, pressure and vibration without a transmitter output require adding a sensor. The cost here sits in the sensor and its installation, not in the network.
Listing the three groups once makes it clear which points can be connected straight away and which need mechanical work.
Equipment that has been running for over a decade and equipment bought last year usually have to appear on the same dashboard. Older units are mostly RS232/RS485 serial, newer ones Ethernet. Serial port count is often the first dividing line: three serial devices per station and two stations means six ports, and a gateway that falls short forces extra serial servers and converters into the cabinet, along with more wiring, more power points and more failure points.
An IoT gateway such as USR-M300 takes this on directly: one RS232/485 port plus one RS485 port, with serial, Ethernet and I/O acquired in parallel, up to 2,000 collection points; built-in Modbus RTU/TCP conversion, so registers on legacy serial devices can be mapped straight into MQTT or TCP messages. Two DI, two DO and two AI channels — the AI inputs are current type — accept emergency stop signals, door contacts and 4-20mA transmitters nearby, and more I/O modules can be added when points run short. Wide-voltage power input, an operating range of -25 to 75°C, wall or DIN-rail mounting: it fits inside a cabinet or beside the machine.
Reaching the picking area or the loading dock with a cable from the cabinet often costs more in distance and labour than the device itself. An industrial 4G router covers this leg. USR-G806w uses Qualcomm solutions for both the main control and the cellular module, and provides one WAN port plus two LAN ports (or three LAN ports) with automatic switching between wired and cellular; OpenVPN, IPSec, PPTP, L2TP and GRE are supported, and the unit can act as a client to three different OpenVPN servers or as a server itself, so maintenance terminals in the office never need direct exposure to the public internet. With hardware and software watchdogs, plus alarms for device offline, weak signal and traffic overrun pushed by email or SMS, a dropped link becomes known immediately rather than after an operator reports it.
Reporting usually takes one of two paths. One goes to a cloud platform — M300 connects to PUSR Cloud, Alibaba Cloud and AWS, and interoperates with ThingsBoard and Azure over standard MQTT and TCP. The other goes to the company's own system, with the gateway pushing MQTT messages to a self-hosted server and the dashboard written in-house. Caching data locally during an outage and backfilling it after recovery is what keeps the remote trend line continuous.
When the scope moves from seeing status to computing locally — generating a daily report for dozens of machines on site, running a Node-RED flow for interlocks, connecting devices on a CAN bus, or leaving room for video analysis later — squeezing all of the logic into the gateway becomes tight. Fanless industrial computer USR-EG628 is aimed at exactly this: an RK3562J industrial-grade chip, quad-core 64-bit Cortex-A53 up to 2.0GHz, Ubuntu with Node-RED preinstalled and support for Docker applications; two RS485 ports, one RS232 port, one CAN port, two Ethernet ports and two USB ports, with 4G/5G, Ethernet and WiFi options for network backup. It is a small host on the device side, carrying the logic the gateway cannot, not a replacement for it.
Three tables come first: the values to watch (name, source, rate of change), the physical interfaces of the equipment (how many serial, Ethernet and I/O ports each), and the network conditions on site (whether a cable exists, whether 4G signal is stable). Those tables largely settle how many serial ports the gateway needs, whether the uplink should be wired or cellular, and whether I/O modules are required. The first batch should cover one production line or one area, with reporting intervals and alarm thresholds tuned before other areas are added.
The accuracy of remote monitoring depends on whether the collection points match the judgments made on the shop floor, not on how many trend lines appear on a report. The role of the IoT gateway here is limited — reading the values reliably and passing them on. Starting with one machine and one link, getting collection, uplink and viewing to work in turn, is easier to sustain than rolling everything out at once.
