When is IoT useful, and when is it unnecessary? From sensors to decisions

Start with the decision that better observations will change

IoT connects observations of physical conditions with processes that can use them. Connectivity does not necessarily mean a public Internet endpoint or cloud service: a local network, gateway and on-premises server may be sufficient. The starting question is which decision currently suffers from missing or late information. Define the decision, responsible person and deadline before selecting devices. Additional records do not automatically become operational value merely because they can be displayed remotely.

A remote pump's pressure history might change maintenance planning or inspection priority between visits. If nobody reviews the record, owns an alert or can intervene, connectivity has limited value. The project needs an observation-decision-action-evidence chain. Write down the measurement, decision, action and confirmation of outcome. Without the final steps, a technically functioning monitoring interface may still fail to improve the work it was supposed to support.

Conditions that make connected monitoring useful

Recurring information gaps across distributed assets can justify connected monitoring, particularly when meaningful change occurs faster than visits. Comparing sites also requires consistent units, time and asset identities. Connecting devices is only one component. Trustworthy acquisition, retention during outages and delivery with the correct context must be planned together. Otherwise connectivity can spread an incorrect comparison faster rather than improve visibility or shorten the time to a justified decision.

The requirement may be a reliable history rather than immediate alerts. Energy use, environmental conditions and intermittent symptoms often need longer context. Correct period aggregates and explicit gaps may matter more than a second-by-second dashboard. Sampling frequency follows the physical phenomenon. Sampling and transmission frequency are separate decisions: a device may sample frequently while sending summaries, provided the required evidence and exceptions remain available for later investigation.

When a new IoT system may not be justified

Manual collection may be preferable when a few annual readings suffice, access is easy and delay does not affect the decision. If trustworthy data already exist in PLC or SCADA infrastructure, assess access to that source first. Duplicating sensors and platforms can add calibration, maintenance and security work. A new system needs a specific unmet requirement. Its technology label is not an investment case when a simpler method can reliably support the same decision.

Sometimes the problem is interpretation rather than acquisition. Incorrect units, ambiguous asset mapping and undefined alert ownership are not solved by adding connections. Low-latency physical control also cannot automatically be moved into a general-purpose cloud application. Local control and protection requirements need separate assessment. NIST's OT guidance provides a reference for considering performance, reliability and physical safety together; citing it does not establish the suitability of a particular design.

Section references: NIST SP 800-82 Rev. 3 · OT Security ↗

Set expectations across the entire operating chain

Sensors, collection software, gateways, transport, central storage and user workflows have separate responsibilities. Units, time, quality and ownership must survive every boundary. If a legacy device cannot strongly authenticate itself, the gateway's actual trust boundary remains explicit. A value reaching the server is not automatically a correct physical measurement. A badly mounted or uncalibrated sensor can transmit consistently over a well-protected connection while still supplying misleading observations.

A realistic expectation is better visibility and traceable decision support under defined conditions. It is not automatic maintenance, zero failures, unlimited battery life or uninterrupted real-time operation over every connection. A valid alert does not prove that intervention is feasible or economical. Acceptance criteria specify stale-data limits, visible gaps and review ownership, connecting the proposed benefit to measurable system behavior instead of an unrestricted promise of automation.

Worked example: reduced visits are only part of the cost picture

In a wholly hypothetical case, assume 12 monthly visits, 1.5 hours per visit and a cost of TRY 600 per hour. Reducing visits to four avoids TRY 7,200 in monthly labor cost. With TRY 3,500 of monthly connectivity, maintenance and operation, the simple net benefit is TRY 3,700. An initial cost of TRY 85,000 gives roughly 23 months of simple payback. These are illustrative inputs, not market prices, a quotation or measured customer results.

If only two visits are avoided, the same assumptions produce a negative TRY 1,700 monthly result and no positive simple payback. The code returns null rather than zero months. A real assessment separately considers discounting, financing, taxes, downtime and uncertain benefits; this example does not model them. Sensitivity analysis turns the assumed visit reduction into a pilot question. A technically functioning system does not necessarily create economic value under every operating scenario.

const assert = require('node:assert/strict');
// Hypothetical simple-payback screen, not a financial forecast.
function compare({ visitsBefore, visitsAfter, hoursPerVisit, hourlyCost,
  monthlyOperatingCost, installationCost }) {
  const values = [visitsBefore, visitsAfter, hoursPerVisit, hourlyCost,
    monthlyOperatingCost, installationCost];
  assert(values.every(value => Number.isFinite(value) && value >= 0));
  const avoidedVisitCost = (visitsBefore - visitsAfter)
    * hoursPerVisit * hourlyCost;
  const netMonthlyBenefit = avoidedVisitCost - monthlyOperatingCost;
  return { avoidedVisitCost, netMonthlyBenefit,
    simplePaybackMonths: netMonthlyBenefit > 0
      ? installationCost / netMonthlyBenefit : null };
}
const assumptions = { visitsBefore: 12, visitsAfter: 4,
  hoursPerVisit: 1.5, hourlyCost: 600,
  monthlyOperatingCost: 3500, installationCost: 85000 };
const expected = compare(assumptions);
assert.equal(expected.avoidedVisitCost, 7200);
assert.equal(expected.netMonthlyBenefit, 3700);
assert(Math.abs(expected.simplePaybackMonths - 85000 / 3700) < 1e-12);
const limitedBenefit = compare({ ...assumptions, visitsAfter: 10 });
assert.equal(limitedBenefit.netMonthlyBenefit, -1700);
assert.equal(limitedBenefit.simplePaybackMonths, null);
assert.throws(() => compare({ ...assumptions, hoursPerVisit: -1 }));
console.log({ expected, limitedBenefit });

Who owns the device throughout its lifecycle?

Calibration, batteries, updates, connectivity and incident investigation continue after installation. Certificate expiry and relocation are operating events too. Asset, device and human identities remain distinct so moving a sensor does not silently rewrite historical meaning. Inventory should include location, owner, running version and support boundary. Increasing the number of unmanaged devices does not improve visibility; lifecycle responsibility and a maintenance budget belong in the design from the beginning.

Data ownership involves more than the database location. Define reading, export, retention and handover when services change. Exports must preserve source identity, units and quality flags so historical records remain interpretable outside one provider's interface. Retirement also coordinates keys, permissions and inventory status. Physically removing a device may leave remote credentials active unless the lifecycle process explicitly revokes or disables them.

Which uncertainty should the pilot resolve first?

A pilot tests more than whether a sensor can send a reading. Compare decision delay, unnecessary visits, missed events and review workload against the existing method. Include disconnection, stale data, incorrect device mapping and revoked access. Report gaps, conditions, sample counts and duration instead of substituting favorable screenshots for evidence. A short idealized trial cannot establish lifetime field performance; findings remain bounded by the conditions actually examined.

Set acceptance criteria before collection and do not silently exclude missing periods. Measuring delay only for records that arrived can hide those that never arrived. Count expected observations, accepted observations and usable decisions separately. Physical protection requirements need their own assessment. An IoT pilot is not a safety certification or automatic control authorization. Monitoring and action authority are distinct, and a valid pilot may conclude that a smaller solution is sufficient.

• Which decision changes, for whom and within what deadline?
• Were existing SCADA, local logging and manual alternatives compared?
• Are transport, identity, maintenance and retirement owned?
• Can the benefit assumptions be checked in the actual pilot?

Scope the system around the need with Gokbilge Tech

As an independent software and hardware house, Gokbilge Tech can assess sensor integration, local board engineering, firmware and central applications together. Global component sourcing remains explicit, with local contribution defined in requirements, circuitry, software, tests and systems knowledge. Not every project needs a new board or platform. If reliable delivery and workflow integration of existing data are sufficient, the scope can be smaller and directly address the identified engineering problem.

An initial discussion can use the asset inventory, existing measurements, connectivity and the decision expected to change. Transport and identity boundaries then become explicit; the next two articles examine them in detail. Scope begins with necessary data, reusable infrastructure and pilot evidence rather than unmeasured savings or uptime promises. Organization-specific field information remains outside public examples, with data sharing and project boundaries defined separately.