Testing and Commissioning an IoT Installation

Commissioning is a sequence, not a guess

The difference between a smooth commissioning and a wasted afternoon is rarely the tools. It is the order in which they are used. An installation that will not come up has a fault at exactly one layer, and the fastest way to find it is to test each layer in turn, from the bottom up, and stop at the first thing that fails.

Worked this way, the process is repeatable. A junior engineer following the sequence reaches the same conclusion as a senior one, because the method does the thinking. The other habit that separates good field work from guesswork is presentation: give the plain answer first, and keep the raw engineering data underneath it for anyone who needs to dig. This piece follows on from the guide to the IoT engineer's laptop and field kit, and assumes you have that kit to hand.

The diagnostic ladder

Almost every "it will not connect" problem sits at one of six layers. Test them in order, and stop at the first failure. If the physical link is down, nothing above it matters and checking DNS is wasted effort.

Discovering what is actually on the network

On an unfamiliar site you often do not know what is on the LAN. A discovery scan answers that in seconds. Tools such as arp-scan, Nmap or Advanced IP Scanner sweep the subnet and return the live hosts. The MAC address prefix identifies the manufacturer, and the open ports hint at what each device is.

That is enough to orient yourself: which address is the router, which is the PLC, which is the camera, and which unknown device is answering on Modbus TCP port 502. It also flags anything that should not be there, which matters for security as much as commissioning. Keeping a live inventory of every endpoint is a discipline in its own right, covered in the guide to IoT endpoint security.

Talking to industrial kit: Modbus and serial

Much of the industrial world still speaks Modbus over a serial line. A known-good USB to RS485 adapter appears in Windows as a COM port, and from there a utility such as Modbus Poll can talk to a meter, a PLC or a controller directly.

For Modbus RTU, set the serial parameters to match the device, commonly 9600 baud, 8 data bits, no parity and 1 stop bit, then scan slave addresses across the valid range of 1 to 247 until a device answers, and read its registers. For Modbus TCP the transport is Ethernet on port 502, and you address the unit ID rather than a serial slave.

Where the same data has to reach a control centre over cellular, the connectivity architecture matters as much as the protocol, which is covered in the guide to remote access to SCADA systems.

Cellular: reading the signal properly

When the backhaul is cellular, three numbers tell the story, and reading them correctly saves a return visit.

RSRP is raw strength and drives which cell the modem attaches to. RSRQ folds in interference from neighbouring cells. SINR is the best single predictor of usable throughput, because it measures wanted signal against noise. A strong RSRP with a poor SINR is common at a cell edge or in a congested area, and it explains the classic complaint of "full bars but no data".

The practical rule when aiming an external antenna is to optimise for the highest SINR, not the strongest RSRP. On current firmware you can read these live: RutOS 7.5 and later, and Peplink 8.4 and later, show SINR and SS-RSRP under Status → Cellular → Details. RedCap devices follow the same rules but tolerate slightly lower thresholds thanks to their narrower bandwidth. Treat the bands above as a guide; exact figures vary by source, radio technology and network.

The SIM test sequence

When a cellular device will not pass traffic, run a fixed sequence rather than guessing:

1. Detect the SIM and read the ICCID
2. Check network registration
3. Identify the operator and PLMN
4. Confirm the radio technology, band and signal metrics
5. Establish the PDP context and read the assigned IP
6. Resolve DNS and run a ping test
7. Confirm the application path, for example an MQTT connection

If registration succeeds but the PDP context fails, the fault is usually the APN or its credentials, not the signal. Whether the SIM hands the device a private or public address, and what that means for reaching it remotely, is covered in the guide to private versus public IP for cellular IoT.

Proving the data path

A device that shows a signal is not a finished job. Commissioning is complete only when data reaches the platform. The honest test is to follow the whole chain from sensor to dashboard.

An MQTT client such as MQTT Explorer, or the command-line Mosquitto tools, connects to the broker with its host, port, TLS setting and credentials, subscribes to the topic and watches the messages arrive. If you need to prove the chain independently of the customer's gateway, stand up a temporary broker on the laptop with Docker and publish to it directly. That turns the laptop into a stand-in for parts of the system, so you can isolate whether a fault is in the device, the transport or the platform.

Write it down: the commissioning report

The last step is the one most often skipped. Capture the evidence as you go: interfaces and IP addresses, routes, DNS and DHCP details, the ARP table, the Wi-Fi environment, latency and packet loss, open ports, cellular metrics, attached serial interfaces and connected USB hardware. Much of this can be gathered automatically into a single site report.

The value is twofold. It gives the customer a record of a working installation at handover, and it gives the next engineer a baseline to compare against when something changes. When a site that worked stops working, that first report is the fastest route back to the fault.

From the workflow to the device in your hand

Look back over that sequence and notice how little of it needed a heavyweight Windows laptop. A browser, a terminal, a handful of open tools, a network port and a serial adapter cover almost all of it. Which raises a fair question: if the tooling is this light, do you still need the laptop at all? That is the subject of the final piece in this series, on whether a phone or a rugged tablet can replace the laptop for IoT field work.

Frequently asked questions