In this guide 6 sections
The common mistakes are reaching into the control system, assuming plant internet stays up, sending every alarm to everyone, and leaving data ownership and support scope unwritten. GullySystem’s IoT Monitoring Dashboard reads alongside PLCs and buffers readings at the gateway. Sensors and gateways are chosen with your vendor, not made by GullySystem.
Reaching into the control system instead of alongside it
A monitoring change that stops a machine costs a customer’s trust quickly. Reading data should not need edits to a running PLC program. Read over Modbus, OPC UA or a meter’s own output, beside the control logic.
Agree in writing which tags are read, and that nothing is written back without approval. Where a local action is needed, such as a hooter or an interlock, keep a manual override at the panel. Log every automatic action.
Assuming the plant internet stays up
Plant connectivity drops, often at a bad moment. If rules run only in the cloud, an alert never fires during the outage. Readings from those hours are lost.
Run the critical rules on the gateway at the site. Buffer readings locally and upload them in order when the link returns. Alert when a gateway or sensor stops reporting, so silence is not read as calm.
- Rules that must work offline run at the edge
- Readings buffered on the gateway
- Backfill uploaded in time order
- A silent-device alert for every gateway
Sending every alarm to everyone
An alert that reaches twenty phones is read by nobody. Name one person on each shift for each alarm. Set how long a condition must last before it counts.
Escalate only when the first person does not acknowledge. Keep a record of who acknowledged what, and when. Each month, remove alarms that nobody acted on.
Leaving ownership and support scope unwritten
Who owns the gateways, the SIM cards, the cloud account and the readings? If nobody wrote it down, a later dispute is hard to settle. Put it in the contract before the first device is fitted.
Write down how long readings are kept and how the customer exports them. State what support covers: a drifting sensor, a lapsed SIM, a failed gateway. Price monitoring support as its own line, or it turns into goodwill visits.
- Devices and SIMs bought in a named party’s name
- Cloud accounts held by the customer or by you
- Retention period and export format
- Support scope, response and renewal date
Promising accuracy before the sensor is fitted
What a sensor reads depends on where it sits and when it was last calibrated. A figure promised in the offer is one you will be held to. Promise a method instead.
Run the new readings beside the plant’s own gauge for a few shifts. Show both sets to the customer. Then set a calibration reminder for every sensor that matters.
Monitoring handover checklist
A one-page list to complete with the customer before go-live: tags read, rules at the edge, alarm owners per shift, device ownership, retention and support scope. Both sides sign it, and it stays in the project file.
Open a blank worksheet to printQuestions owners ask
Does the IoT Monitoring Dashboard include sensors and gateways?
No. Hardware is not made by GullySystem. Devices are selected with you or your vendor for site conditions, and fitted on site by an electrician.
Can it read PLCs and meters already in the plant?
Usually, yes. Modbus, OPC UA, BACnet, RS-485, 4-20 mA and pulse inputs cover most plant rooms. It reads alongside the control system, not into it.
Will it manage our offers, FAT punch lists and retention?
Not on its own. The dashboard covers readings, alerts, downtime and run hours. Offers, BOMs, FAT checklists and retention tracking are separate project software work.
Does monitoring stop when the internet drops?
No. Rules run on the gateway, readings are buffered locally, and stored readings upload in order when the link returns.