What we write, at what priority, and what happens when the link drops.
Supervisory control is the claim a controls engineer checks first, so this page is written for that reading rather than for a buyer. Indagate performs supervisory control on live plant today. Here is exactly what that means and where it stops.
What a write actually is
An operator or an agent issues a command against a modelled point. It travels to the gateway on that site over an authenticated MQTT channel, and the gateway performs a BACnet WriteProperty on the point’s presentValue. The gateway publishes the outcome back and the interface waits for that confirmation before showing the write as landed — so a command that never reached the controller does not appear to have succeeded.
Six object types accept writes: analog, binary and multi-state, in both their output and value forms. Anything else is read-only, and a point the survey did not mark writable has no write path at all.
Priority is chosen, shown and checked
BACnet has no standalone “change priority” operation — there is only write at a priority — so the priority is part of every command. Indagate reads the point’s live priority array before you write, shows which slots are already occupied, and warns you when a higher-precedence slot is taken and your write would therefore have no visible effect. The default is 16, the lowest precedence, so the ordinary case cannot quietly outrank something that matters.
Priorities 1 and 2 — manual and automatic life safety — are refused at the gateway. Not discouraged in the interface: refused below it, where no operator and no agent can reach past the refusal.
Bounds, and who is allowed
Each object type carries value bounds that a write must fall inside — deliberately wide, and checked before the write reaches the wire. A write also lands on the record with the actor, the value, the priority and the time — an agent’s write in exactly the shape a person’s takes, which is what makes the two comparable six months later.
Scheduled evaluation, not just scheduled setpoints
Schedules in Indagate run against the asset model, and they run more than setpoints. A monitor is a rule evaluated on its own interval that resolves to a status — ok, warning, alert, no-data or error — and there are three kinds: a metric compared against warning and alert thresholds, a prompt run through the assistant with the site’s current metrics and weather injected into it, and an external source such as weather pulled in and optionally thresholded like a metric.
The third kind is the one a head-end cannot do at all. “Every morning at six, look at yesterday’s plant performance against the forecast and tell me what to expect” is a scheduled prompt, and its answer arrives before the shift rather than after someone thinks to ask.
A no-data result is a state in its own right, not silence. A monitor that stopped receiving data says so instead of sitting green, which is the failure mode every trend-based alarm scheme eventually has.
When the link is down
Commands reach the plant over the gateway’s cloud link. If that link is down, no command arrives — and your controllers carry on executing the sequences they were commissioned with, because those sequences live in the controllers and always did. What pauses is supervision: new writes, new overrides, agent actions. The record shows the gap rather than hiding it.
A value already written stays at its priority until something writes over it or releases it. Indagate does not silently revert your plant because a network went away.
What this is not
Indagate is not a safety-rated controller and does not become one by writing setpoints. Safety relays, interlocks, E-stops and machine guarding are authoritative and operate whether Indagate is running, unreachable or switched off. Sequence logic stays in the field controllers. Commissioning a write path on live plant is an engineering activity with your team, not a toggle in a settings page.
Specifics
- Protocol
- BACnet/IP and MS/TP, WriteProperty on presentValue; Modbus and OPC UA writes per site scope
- Writable objects
- analogOutput, analogValue, binaryOutput, binaryValue, multiStateOutput, multiStateValue
- Priority
- 1–16, default 16; priorities 1 and 2 refused at the gateway
- Confirmation
- The gateway’s response is correlated to the command before a write is shown as landed
- Scheduled evaluation
- Monitors on per-rule intervals: metric thresholds, assistant prompts, external sources
- Bounds
- Per object type, checked before the write
- Link loss
- No commands arrive; controllers keep executing their own sequences
Common questions
Do you write at priority 8, like most BMS front ends?
The default is 16, the lowest precedence. An operator can choose any priority from 3 to 16 for a given write, and the interface shows which slots are already occupied so the choice is made against the live priority array rather than from memory.
Can an agent write at any priority it likes?
An agent writes only what its grant names, and the same gateway-level refusal of priorities 1 and 2 applies to it. There is no path around it for an agent that a person does not also lack.
Does Indagate support Modbus or OPC UA?
BACnet is the deepest path — that is where the priority-array handling and write confirmation described above apply in full. Modbus and OPC UA are mapped into the same namespace, and what is writable on your particular equipment is confirmed during the survey rather than assumed.
What runs on a schedule?
Monitors: a metric checked against thresholds, a prompt run through the assistant with current site data and weather injected, or an external source pulled in and thresholded. Each has its own evaluation interval, its own status, and its own notification behaviour when that status changes.
Bring your point list.
The first conversation is a survey: what you run today, and what it would look like modelled.