“Offline” on a front end is not a measurement. It is a conclusion. The supervisor asked a question, didn’t get an answer it liked inside the time it was willing to wait, and picked the most dramatic word available. Sometimes it’s right. Often the controller is powered, running its program and controlling its equipment perfectly well. It just isn’t being heard.
That difference matters because of what the word sends you to do. “Device offline” sends a tech to the controller with a meter and a replacement board. If the real problem is a timeout, an expired subscription or an overloaded supervisor, you can swap every controller on the trunk and the status won’t change.
What the front end actually knows
Every status on the screen is built from a conversation. The supervisor sends a request, waits a configured time, maybe retries, and then marks the point or device based on what came back. Between the supervisor and the controller there’s a stack: the supervisor software, its driver settings, the IP network, a router, a field trunk, the controller’s comm port, and finally the controller’s own application. A failure at any one of those layers puts the same word on the graphic.
This is the layer stack from the troubleshooting method, applied to communication. The rule doesn’t change: figure out which layer you’re in before you start testing inside one. Most wasted time is spent testing over and over in the wrong layer.
Before you touch anything, answer three free questions:
- One device, or everything behind one router, trunk or port? Many devices on one path points upstream. Many devices across different paths points at the supervisor.
- The whole device, or one point? A device that answers for nine points and not the tenth isn’t offline.
- Constant, or does it come and go? Something that drops and comes back with clean power and no reboot is almost never a dead controller.
Those three answers rule out most of the list below before you leave the office.
Six ways a device looks offline and isn’t
The answer arrives late
The request gets delivered. The controller replies. The reply takes longer than the supervisor’s timeout, so the supervisor retries, gives up, and marks the device offline. The late reply shows up and gets thrown away because nobody is waiting for it anymore. This is the classic after a head-end upgrade quietly resets timeouts to their defaults, or on a busy MS/TP trunk where a device behind a router can take well over a second to answer. It shows up on Modbus gateways too: one slow unit behind a gateway flips between ok and fault all day while its neighbours stay solid.
Look for: replies in the capture that arrive after the retry. Pair each request with its reply (BACnet invoke ID, Modbus transaction ID) and time them. A reply after the timeout means the timeout is too short, not that the device is down
The subscription or registration expired
Plenty of points don’t get polled. They update by change-of-value subscription: the supervisor subscribes for a set lifetime and has to renew before it runs out. If the renewal never happens (a restart, a task that stopped running) the notifications stop and the value freezes at its last reading. The same pattern shows up one layer down when a device on another subnet talks through a foreign device registration that isn’t being renewed: it works for a while after every restart, then disappears. See BBMDs and foreign device registration.
Look for: one point frozen while other points on the same controller update. In a capture, check the subscription lifetime and the time remaining in each notification. When it counts down to zero and no new subscription goes out, the updates stop
The supervisor is the one struggling
An overloaded supervisor falls behind, and when it falls behind its requests time out. Too many polled points, trend polling across a slow trunk, or a noisy analog point with a tight COV increment flooding the network with notifications. The symptom is devices on several different networks flickering offline together, with no pattern in the field wiring that could explain it.
Look for: many devices on unrelated paths at once. That’s upstream. Check the supervisor’s resource use and poll-cycle statistics before you check any trunk
It’s bound to the wrong identity
The front end has a device instance, network number, address or port that no longer matches the real device. A controller got replaced and came up with a different instance. Two devices on the site share an instance. Another device grabbed the controller’s IP address. A Modbus device is listening on a port other than the one the driver is using. The controller is fine and answering to its real identity. The supervisor is asking somebody else. Device instance, MAC and network number covers how those three identities fit together.
Look for: discovery finding the device with a different instance or address than the database expects, or a connection refused / port unreachable coming back from the device’s address
One point is in fault, not the device
A single point in fault can make a whole graphic look dead. An object deleted or renumbered by a program download, a property the device doesn’t support, a Modbus register that returns an exception. The device is answering. It’s answering with an error, and the error tells you exactly what’s wrong if you read it.
Look for: other points on the same device reading fine, and the error class and reason (or exception code) in the response
It really is dropping, but the device is healthy
Address conflicts, duplicate MS/TP MACs, missing bias, a loose landing. These are real communication failures, but the controller itself is fine, and replacing it fixes nothing. The tell is that it comes and goes with clean power and never reboots. Intermittent problems covers how to catch these, and MS/TP wiring, termination and biasing covers the trunk side.
Look for: duplicate ARP replies (the same IP answering from two MAC addresses), or framing and CRC errors on the trunk
How to prove which one you have
You don’t need to guess between these. Each one leaves a different fingerprint, and one or two tests separate them.
| Question | If yes | Next test |
|---|---|---|
| Can you connect to the controller locally and read live values? | It’s alive. The problem is the conversation, not the controller | Capture between supervisor and device |
| Is everything behind one router or trunk affected? | Upstream of the devices: router, trunk, or the timeout for that network | Compare against another network on the same supervisor |
| Does the capture show replies to the supervisor’s requests? | Device is answering. Timing, binding or error | Pair requests and replies, time them |
| Do the replies land after the retry? | Timeout too short for that path | Raise timeout, then ask why the path is slow |
| Is one point frozen while its neighbours update? | Subscription or point-level fault | Check COV lifetime, renewal, and the error in the reply |
| Does discovery find it under a different identity? | Binding mismatch | Fix the database or the device, not the wiring |
| Does it drop and return with no reboot? | Conflict or physical-layer fault | Switch MAC table, duplicate-address check, trunk capture |
The single most useful test is the first one. Go to the controller, or onto its network, and ask it directly. If you can connect locally and read live values, the controller is not offline, and whatever is wrong lives between it and the supervisor. That one test cuts the stack in half, which is exactly what the half-split is for.
If you can’t reach it locally either, now you’re in the physical and addressing layers: power, the comm port, the trunk, the address. Prove it with a meter before you prove it with a new controller. On MS/TP that means DC voltage across the pair, each conductor to ground, and resistance with the trunk powered down.
The timeout trap
Timeouts get their own section because they’re the most common “offline, but answering” I run into after an upgrade or a migration. The supervisor sits on a fast IP network. Behind a router, a token-passing MS/TP trunk carries thirty or forty controllers, and a reply has to wait its turn on the wire. A request that crosses a router onto a busy trunk can easily take a second or more to come back. Set the timeout at one second and every device on that trunk flickers, while devices on a quieter trunk look perfect.
Raising the timeout makes the flicker stop. It doesn’t make the trunk any faster. If a trunk is slow, ask why: a router allowed to send only one frame per token pass, too many devices on one segment, or too much polling for what the trunk can carry. Max Master and Max Info Frames covers the two settings that decide most of that. Often the right answer is both: a timeout that matches the path, and a path that isn’t overloaded.
Change retries with care, too. More retries on a slow path add more traffic to the path that’s already slow.
Worse than a false offline: a false online
A device wrongly marked offline at least gets somebody’s attention. A frozen value that still looks live gets nobody’s. An expired subscription, a failed poll that holds the last known value, or an override holding an old number can all produce a perfectly plausible reading that stopped being true hours ago.
On a trend, that’s a flatline, and a flatline on a point that should wander is one of the most informative shapes you’ll ever see. On a graphic, it may look like nothing at all unless the graphic was built to show staleness. Your graphic should tell you when it doesn’t know is about exactly that, and Everything looks normal, but the equipment isn’t working is what happens when it doesn’t.
Work it in order
- Define it. Which devices, which points, since when, constant or intermittent. Ask what changed: an upgrade, a controller swap, an IT change, a new device on the network.
- Scope it. One point, one device, one trunk, one router, or everything. The scope tells you the layer.
- Ask the device directly. Connect locally. Alive locally means the fault is in the conversation.
- Capture the conversation. Requests, replies, timing, errors. Pair them by ID and look at the gaps.
- Compare identities. Instance, MAC, network number, IP and port, against the database and against every other device. The BACnet Config Checker flags duplicates and mismatches in a device list in seconds.
- Fix the cause, verify over time, document it. Trend the device’s status or comm-failure count for a day, not ten minutes. Write down any timeout or retry you changed, the old value, and why.
If ping works and BACnet still doesn’t, that’s its own family of problems: Ping works, BACnet doesn’t walks through it.
The front end is a witness, not a judge. It reports what it heard, and “offline” only means it didn’t hear enough. Your job is to find out whether the device went quiet or the supervisor stopped listening, and those two are fixed in completely different places.
Stuck on a live call? The BAS Troubleshooter walks you through this method step by step, offline, on your phone.
Go deeper
The method behind this, chapter by chapter
Every sensor, drive and control loop in the building — how it works, how to prove it with a meter, and how it fails. BAS Field Fundamentals is the method this article uses, with 20 field cases and a browser diagnostic simulator to practice on.
Get BAS Field FundamentalsFound a wrong number or a broken link? Tell me and I’ll fix it.