Industrial IoT Gets Useful When Operators Can Ask WhatsApp: Which Lights Are Actually On?

Most IoT demos stop before operations start

A relay clicking a lamp on a desk is not an industrial system. A port with sixteen 1000W floodlights needs something less cute: feeder mapping, status feedback, command authorization, power readings, alarm rules, and audit logs.

Operators do not want to talk to Modbus registers. They want to ask which lights are on, which feeder is abnormal, and whether last night’s consumption looked right.

OpenClaw is the orchestration layer, not the PLC

The electrical safety layer stays in hardware: breakers, contactors, overload protection, interlocks, and emergency procedures. OpenClaw should sit above the field layer and coordinate visibility, access, logging, alerts, and human-friendly commands.

That boundary keeps the project professional. Chat should never replace electrical protection.

Start with feeder-level control

Per-lamp control is attractive, but feeder-level control is often the sane MVP. Four feeders with four lamps each are easier to validate, safer to operate, and still valuable.

Once feeder-level status, current readings, and command logs are stable, the system can evolve into per-mast or per-lamp visibility where the hardware supports it.

Every command needs confirmation and logging

“Command sent” is not good enough. The system should log who requested the command, check their role and permitted zone, send the command to the edge API, wait for feedback, store the result, and reply with confirmed status.

If feedback fails, the response should say that. Operators need truth, not optimism.

async function switchFeeder({ userId, feederId, action }) {
  await permissions.require(userId, 'control', feederId)

  const command = await db.commands.create({ userId, feederId, action })
  const result = await edgeApi.switchFeeder(feederId, action)

  await db.commands.update(command.id, { result })
  return result.feedback === action ? 'confirmed' : 'sent_unconfirmed'
}

Mismatch detection is where the value shows up

If Feeder C receives an ON command and current stays below threshold for 90 seconds, the system should not say everything is fine. It should report that the command was accepted but the load did not behave as expected.

That alert points the technician toward breaker trip, contactor issue, lamp failure, cable fault, or supply interruption.

const expectedCurrent = feeder.baselineCurrentAmp
if (command.action === 'ON' && measuredCurrent < expectedCurrent * 0.25) {
  createAlarm({
    type: 'no_current_after_on',
    feederId: feeder.id,
    severity: 'high',
    message: 'ON command accepted but current did not rise to expected range.'
  })
}

Role access is engineering, not administration

Read-only status is low risk. Turning off all lights is high impact. The system needs roles: viewer, operator, supervisor, admin. It also needs zone permissions and confirmation for broad commands.

A WhatsApp interface makes control easy. That is exactly why authorization must be strict.

Power reporting turns lighting into an asset

Once current and energy data are stored, the system can answer: current load, energy used today, feeder consumption by zone, abnormal draw, nightly usage comparison, and offline telemetry.

A weekly lighting report can show runtime, kWh, alarms, failed commands, and recommended inspection. That is how a lighting control project becomes operational intelligence instead of remote switching.

The sane MVP

Build monitor-only first if the site is sensitive. Then add feeder ON/OFF, feedback confirmation, command logs, role access, and three alarms: offline, no current after ON, and overcurrent.

Do not start with a giant SCADA replacement. Start with a reliable operator layer that people trust.