← Back to Technical Insights

Diagnostics & Troubleshooting / KIMMA INSIGHTS

BMS can monitor but cannot control: where should you look first?

Live data does not prove a working control path. Separate authority, mode, communications, controller logic, outputs, field devices and the original scope.

Diagram of the command path from supervisory platform through controller and output circuit to field actuator

HOW THE PROBLEM MAY BE DESCRIBED

You may describe the issue like this.

  • Why does an on-screen start command produce no response?
  • Why does equipment remain still when the BMS shows Auto?
  • Where should you begin when hospital HVAC can be monitored but not controlled?
  • Why does a valve remain still when the controller shows an output?
  • Why does a changed setpoint revert after a short time?
  • Why are some devices controllable while others on the same graphic are monitor-only?
  • Why do integrations return after controller replacement while the original sequence does not?
  • How can authority, logic and field faults be separated after a remote command?

Typical symptoms

  • Measurements and alarms update while start, stop, setpoint or modulation commands have no result
  • A command appears written but feedback does not change, or the device immediately returns
  • Some points are controllable while others in the same system remain read-only
  • Controller output changes without corresponding relay, valve, damper or drive action

Where these symptoms may come from

Platform and authority

An account may be view-only and an integrated point may be mapped read-only. A clickable graphic does not prove write authority at the protocol, gateway or controller. Schedules or supervisory routines may also write a different value afterwards.

Mode, interlock and local sequence

Local, service, fire-interlock or equipment-native modes can correctly reject a BMS command. Local logic may be waiting for pressure, flow, valve position, fault reset or minimum-off time. No action can therefore be a valid protection response.

Output and field-device layer

After the controller variable changes, the path still includes physical output, relay, intermediate circuit, actuator and equipment panel. Signal mismatch, open circuits, stuck actuators or equipment faults can all break that path.

Diagnostic sequence

  1. Record the before/after state, time, operator and target without repeated clicks
  2. Confirm account and point write authority and whether the platform accepts or rejects the write
  3. Confirm remote/automatic permission and review explicit interlocks, faults and minimum run/off conditions
  4. Trace command, mode, program result and physical output through the controller
  5. Under appropriate safety controls, have qualified personnel check the output circuit, actuator and equipment panel
  6. Prove completion with run feedback and field outcome, not the command value alone

Safe checks you can prepare first

These checks collect evidence without bypassing interlocks, forcing outputs or changing critical protection.

  • Capture command, feedback, mode, alarms and timestamps
  • Record whether one point, device, controller or the whole system is affected
  • Observe whether the equipment panel permits Auto/Remote without forcing a mode
  • Collect point properties, controller model and relevant sequence documents
  • Note whether a command reverts immediately, later or not at all
  • Prepare nameplate photos or a short video without opening or rewiring equipment

Separate a missing command from a correctly rejected command

The same no-action symptom can have very different causes. A write may never reach the controller because of permissions, a read-only gateway or mapping. Alternatively, the controller may receive it and correctly refuse because remote permission, an interlock or protection timer is not satisfied.

Keep evidence across command, controller variable, sequence state, physical output and run feedback. If only one layer is visible, state that limit rather than assuming that an on-screen change proves field action.

Do not substitute forced outputs for diagnosis

A forced output may briefly prove that hardware can move, but it can also bypass interlocks, sequence and equipment protection. It is particularly inappropriate as a casual test in healthcare, data rooms, central plants or process settings.

Any controlled site test needs an agreed scope, rollback, observer and stop condition. This article provides diagnostic order, not authority to force, bypass or work on live equipment.

The conclusion must return to operating outcome

After control is restored, observe command, feedback, field equipment and controlled condition together. Fan start needs reliable run feedback; valve modulation should agree with position or temperature trend; setpoint changes should affect control within a reasonable time. A working button alone does not close the loop.

How the same issue differs by setting

Healthcare

Continuity, pressure relationships and critical environments can require stricter interlocks. Confirm clinical use and fallback operation before tests.

Commercial buildings and hotels

Schedules, tenant hours, room energy modes and local authority are common; check whether another operating strategy overwrites the command.

Data centres and industrial settings

Equipment protection, redundancy and process permissives normally outrank supervisory commands and must not be bypassed.

Information to prepare before contacting us

  • Screenshots and alarm records from the time of the issue
  • Platform name, version and normal access route
  • Controller, gateway and relevant field-device models
  • BA point schedules and network or bus information
  • When the issue occurs, how long it lasts and what repeats it
  • Low-risk checks already completed and the observed result

SITE SUPPORT

Seeing something similar on site?

Similar symptoms can come from the platform, network, controller logic or field equipment. Send screenshots, models, point schedules or a short description so we can help narrow the scope.